461

This sounds absolutely nutty. It is expending a great deal of effort for very questionable benefit, and the practice seems based on some faulty premises: That QA won't work hard unless they know they are being tested every day (which cannot be good for morale) That there are not enough unintentionally introduced bugs in the software for QA to find That QA's ...


350

25000 errors basically means "don't touch that". Change it back. Create a new class that has the desired interface and slowly move the consumers of the class to the new one. Depending on the language, you can mark the old class as deprecated, which may cause all sorts of compiler warnings, but won't actually break your build. Unfortunately these things ...


210

Well, based on what I've learned: It's not a school nor job interview; The testers are not children; It's not a game; It wastes company's money. The QA are not there only to find bugs but also to worry about how intuitive the system is, what is the learning curve for the user, usability, and accessibility in general. For example: "Is the system ugly?&...


99

Bad idea. From the tester's point of view: "So they will test hard, because they know there are bugs present and not finding them might be considered as their incompetence." Basically the devs are booby-trapping the code. Few people like doing work which is ultimately pointless (because the bugs are known in advance) but which still affect how they are ...


87

By using a debugger. For the most part, this is also what an IDE does behind the scenes -- it just wraps the experience in a GUI. On Unix, one of the most commonly used debuggers is GNU gdb, which has largely supplanted the earlier Unix debuggers such as dbx. To get an idea of what debugging looks like / feels like from the command line, you can look at ...


79

Many answers have questioned your boss' methods/tactics/metrics/etc. But that is beside the point. Maybe you ARE slow. Every room of developpers has to have ONE that's slower than the rest, right? (That's just straight set-theory.) So let's assume that's you. The answer is, WHY are you slow? (Clearly that is the question you have to answer before you can ...


79

Divide and conquer with refactorings Often, breaking up the change that you need to do into smaller steps can help because you can then perform most of the smaller steps in a way that doesn't break the software at all. Refactoring tools help a lot with such tasks. Divide First, identify the smallest possible changes (in terms of logical changes, not in ...


76

For ad-hoc checks, just use a standard hexdump and learn to eyeball it. If you want to tool up for a proper investigation, I usually write a separate decoder in something like Python - ideally this will be driven directly from a message spec document or IDL, and be as automated as possible (so there's no chance of manually introducing the same bug in both ...


72

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it? You should give it your best effort. I know that sometimes there are conditions and environments that are so complex they can't be reproduced exactly, but you should certainly try if you can. If you never reproduced the bug and saw it for yourself, how can ...


58

I agree totally with the answers above as to why this is bad for motivation and just generally awful people management. However, there are probably sound technical reasons for not doing this as well: Just before the product goes to QA, the dev team adds some intentional bugs at random places in the code. They properly back up the original, working ...


55

Your boss may be correct: you may be "underperforming" (more on that in a minute). But it may not be just your level of competence that's to blame. I don't think it would be a reach to suggest forces outside your control are causing you stress, which is having a negative effect on your performance. Let's have a look at a few of the reasons your boss may now ...


52

You want to look at a logging framework, and maybe at a logging facade framework. There are multiple logging frameworks out there, often with overlapping functionalities, so much so that over time many evolved to rely on a common API, or have come to be used through a facade framework to abstract their use and allow them to be swapped in place if needed. ...


51

Edit I want to be clear that this answer is only talking about the concept of testing your QA process, and I'm not defending the specific methodology portrayed in the question. End Edit There is a valid reason to check if your testing/checking is actually working. Let me give you an example from manufacturing, but the principle is the same. It's typical ...


48

A Duck From http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html: A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.


47

Is there some kind of cultivatable behaviour [...] that can help me at least reduce such kind of mistake Absolutely, it is called four-eyes-principle. If you had you shown your crontab entry to a second person (a person knowing cron, of course), chances are high the mistake would have been avoided. In programming, when it comes to this, people mostly ...


46

Introducing explaining variables is a well-known refactoring which can sometimes help to make complicated expressions better readable. However, in the shown case, the additional variable does not "explain" anything which is not clear from the surrounding method name the statement gets even longer, so (slightly) less readable Moreover, newer versions of ...


38

Given the facts that: a) There is no impact on the final code as the compiler optimises the variable away. b) Having it separate enhances debugging capability. I've personally come to the conclusion that's it's a good practice to separate them 99% of the time. There are no material disadvantages to doing it this way. The argument that it bloats code is a ...


37

Some work environments are unworkable. I've seen environments in which no one could survive (save for those who were in at the beginning) because so much was undocumented and questions were so vehemently discouraged. You really need to be honest with yourself regarding the expectations and the resources provided to help you to meet them. The problem may not ...


37

I really have a hard time seeing where I went wrong The major mistake was that you reinvented the wheel. Instead of using default mecanisms for logging, you invented your own, which displayed the information within the page. A logging framework would rather store logs in log files, letting you to consult those logs later by SSHing to the server. As for the ...


36

I can see a DOS programmer fiddling away and crashing the entire OS when he made a mistake. Yeah, that's pretty much what happened. On most systems that had memory maps, location 0 was marked invalid, so that null pointers could be easily detected, because that was the most common case. But there were lots of other cases, and they caused havoc. At the ...


36

Clarify your task with your boss to help him to understand the problem and your needs as a professional software developer. If you are part of a team, look for the lead developer and ask him for advice. Good luck.


35

I used a debugger for several years while I was writing graphics drivers. I had a second computer that ran the debugger against the first one (because the screen in the primary computer wouldn't work when the graphics driver was broken). It was critical to be able to stop the code and step to the point where I hung the hardware so I'd know what was ...


35

How do they intend to verify that the bug in question was fixed? Do they want to ship untested code to the user and let them figure it out? Any test setup that was never shown to reproduce the error can't be relied upon to show absence of the error. You certainly don't need to reproduce the entire client environment, but you do need enough to reproduce ...


35

No, not at all ! Abstractions and good practices can of course reduce the risks of errors. For example: language abstractions let the compiler generate code, that you would have to write yourself otherwise. For example, the C++ object model ensures that object constructed are destroyed as they supposed to be, without extra care on your shoulders; these ...


35

I think you are misrepresenting the message of the "Modern C++ in Embedded Systems" video. The point is that there are people in the embedded world that write code and then test it by running the code in the debugger to verify that it does what they think it does. He argues that a better alternative is to use abstractions so that the compiler can verify that ...


32

I would say that it is essential to understand every single detail about why some bugs were occurring and why certain changes eliminated those bugs, and it is also common among developers to sometimes get the program working without really knowing the details about why the fix worked! The art of changing things until a bug disappears, without understanding ...


30

First, note: this answer may only apply to certain regions where it is illegal to dismiss an employee without severance. That said... This could be a case of Constructive dismissal and which is illegal. The tactic is to demoralize and lower the self-esteem of an employee until they quit the job. It's a way for the company to save money by not having to pay ...


30

Honestly, I'd call this behavior blatantly unethical and impractical. The PM is in need of some serious retraining, if not termination. It demonstrates a fundamental lack of understanding of the concept of quality assurance. Testers should not think like developers: they should think like end users. The entire reason for having QA teams is that developers ...


30

Generally you have two axes for bugs: gravity and frequency. So obviously something grave and frequent is of the highest priority. However, something that's serious but happens rarely should be weighed roughly at the same as something that's not serious but happens often. So supposing you rate gravity from 1 to 3 and frequency from 1 to 3, the types of ...


28

Ideally, you want to be able to reproduce each bug so that, at the very least, you can test that it's been fixed. But... That may not always be feasible or even physically possible. Especially with 'enterprise' type software where each installation is unique. There's also the cost/benefit evaluation. A couple of hours of looking over code and making a few ...


Only top voted, non community-wiki answers of a minimum length are eligible