Tag Info

Hot answers tagged

364

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 ...


180

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?", ...


140

Sounds like it would do more harm than good. Ignoring for a moment whether it is fair for a manager to do that, let's look at the logistics... Problem 1: Are all bugs created equal? Developer 1 introduces a bug: Erases all customer data and curses at them. Developer 2 introduces two bugs: Form labels are not left aligned, and the calendaring feature is off ...


103

Everybody Loves a Good Code Bash / WTF Session I am now worried that they will find bugs and blame me for the problems. Of course they will find bugs. You said it yourself: it's buggy (you already found bugs) and complex (it's very likely to have more). And yes they'll blame you for it. Because it's a large codebase and they will, over time, get ...


98

In layman's words: All programs can have bugs. Compilers are programs. Ergo, compilers can have bugs.


92

Well, it's pretty simple: not all exceptions are bugs (and similarly, not all bugs manifest themselves as exceptions). As example of an exception that's not a bug, if you're reading a file from a USB drive and someone yanks the drive out of the socket. That's going to raise an exception (in most languages that support exceptions, that is). But it's not a ...


89

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

IPV4 only networking code. The time hasn't come for most people yet, but the idea of IPV4 only networking will become obsolete.


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 ...


76

They get tested thoroughly via usage by thousands or even millions of developers over time. Also, the problem to be solved is well defined (by a very detailed technical specification). And the nature of the task lends itself easily to unit / system tests. I.e. it is basically translating textual input in a very specific format to output in another kind of ...


76

Many localization issues fit this pattern: a generation ago, programmers assumed all characters can be represented with an 8 bit data type a generation ago, programmers assumed every kind of text should be read left-to-right, top-down a generation ago, programmers assumed the field separator in a CSV file is always the comma character , (No, it really ...


71

It was actually in a 3rd party image viewer sub-component of our application. We found that there were 2-3 of the users of our application would frequently have the image viewer component throw an exception and die horribly. However, we had dozens of other users who never saw the issue despite using the application for the same task for most of the work ...


64

In my experience the pattern is this: System works, often for years An error is reported The developer investigates the error and finds a bit of code which seems to be completely flawed and declares that it "could never have worked" The bug gets fixed and the legend of the code that could never have worked (but did for years) grows Let's be logical here. ...


62

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 ...


60

To a software team, a bug is a software problem that needs to be fixed. Not all software problems need to be fixed. Updating software is expensive. Blizzard is telling you that your problem is an edge case. In other words, the edge case problem you discovered is not necessarily something they tested for or otherwise care to account for. Fixing the ...


58

Avoid fancy coding. The more complicated the code, the more likely there's bugs. Usually on modern systems, clearly written code will be fast and small enough. Use available libraries. The easiest way to not have bugs writing a utility routine is to not write it. Learn a few formal techniques for the more complicated stuff. If there's complicated ...


58

Reproducing a bug that rarely happens. Especially when coping with multithreading.


56

I once had to work on a Classic ASP application where the lead developer had proudly claimed to have rewritten the underlying data-access components in .NET. Technically, he wasn't lying, and the code was littered with statements like: set query = "EXEC spDeleteCompany " & intCompanyId arrResult = ...


56

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 ...


54

Is it a bad sign? I think it's a warning that's worth looking into, but I also think it's bound to happen. When people submit any kind of feedback to me, I try to filter it into three buckets: Bugs Feature Requests Mis-communication Bugs Bugs are when something obviously doesn't work the way you would expect, nor the way the user would expect. Like, ...


52

The more powerful the type system of the language, the more bugs will be caught at the compile time itself. The following figure compares some of the well known programming languages in terms of the power, simplicity, and safety of their type systems. [ Source ] *Factoring in the ability to use unsafe constructs. C# gets stuffed into the unsafe row ...


50

Use the best tool for the job. Your version control system should be the best tool for recording when bugfixes and CRs are made: it automatically records the date and who made the change; it never forgets to add a message (if you've configured it to require commit messages); it never annotates the wrong line of code or accidentally deletes a comment. And ...


50

You're looking at it the wrong way. The test does not assert that code was removed. The test does assert a certain functionality. The test does not care about the amount of code required to make it pass, nor does it realize that you have removed some code. The value of having such a test is the very same as any other test that you create due to a bug: you ...


47

Programmers are notorious for optimizing what managers start rewarding. If you reward LOC, then you get lots of whitespace to pad out the lines of code metric. If you try to punish by bug count, you will start getting into wars where the developers claim that X is not their bug (the bug is in the compiler or API or just somewhere else) - and the bug filed ...


47

Yes You tend to find them more in languages that are actively being developed than in those that are relatively mature (and thus don't see a lot of change on a frequent basis). This is probably why most languages are released at various 'stages' of stability. A nightly build is far less likely to be stable than a release candidate, which itself is less ...


47

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 ...


46

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 ...


45

The scariest code I've ever dealt with would probably be the code for a .NET 2.0 application: Well, there was the main form, which contains 27,591 lines, 4,754 of which is the auto-generated Windows Form designer code. In other words, over 20,000 lines of actual code written by the original developer, in one file, in one project, for a single form. And ...


44

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 ...



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