Hot answers tagged

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


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


188

You might not enter random values into fields of a web application, but there certainly people out there that do just that. Some people enter random by accident and others do it intentionally trying to break the application. In both cases, you don't want the application to crash or exhibit other unwanted behavior. For the first type of user, you don't want ...


104

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


101

Never Assume Anything You cannot assume that any user will not do something "dumb" with your software by accident or on-purpose. Users can accidentally press the wrong button, the cat can walk over the keyboard, the system can malfunction, their computer can be hijacked by malicious software, etc. Furthermore, the user themselves may be ...


100

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


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


94

Software corruption is the contrary of software integrity. It's the same thing as data corruption, except that the data is the software code. It can affect: the software binary stored in memory: binary codes of software instructions are altered for example because of physical interference (“please switch off electronic devices during take-off and landing”),...


93

As Mikey mentioned, writing bugless code is not the goal. If that is what you are aiming for, then I have some very bad news for you. The key point is that you are vastly underestimating the complexity of software. First things first--You're ignoring the bigger picture of how your program runs. It does not run in isolation on a perfect system. Even the ...


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


73

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


69

It isn't that the goto is bad by itself. (After all, every jump instruction in a computer is a goto.) The problem is that there is a human style of programming that pre-dates structured programming, what could be called "flow-chart" programming. In flow-chart programming (which people of my generation learned, and was used for the Apollo moon program) you ...


64

Why is goto dangerous? goto doesn't cause instability by itself. Despite about 100,000 gotos, the Linux kernel is still a model of stability. goto by itself should not cause security vulnerabilities. In some languages however, mixing it with try/catch exception management blocks could lead to vulnerabilities as explained in this CERT recommendation. ...


60

There are several factors to take in account. To illustrate those points, I'll use an example of a field where a user should enter a percentage in a context of a quota defined for a specific task in terms of how much disk space the task could use. 0% means the task wouldn't be able to write anything to disk; 100% means the task could fill all the disk space. ...


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


51

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


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


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

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

TL;DR Assumption ("contract") of spurious wakeups is a sensible architectural decision made to allow for realistically robust implementations of thread sheduler. "Performance considerations" are irrelevant here, these are just misunderstanding that became widespread because of having stated in a published authoritative reference. (authoritative references ...


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


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


34

The famous Dijkstra article was written at a time when some programming languages were actually capable of creating subroutines having multiple entry and exit points. In other words, you could literally jump into the middle of a function, and jump out at any place within the function, without actually calling that function or returning from it in the ...


30

Mathematically it MIGHT be possible to write 'bugless' software of such complexity, depending on how you define 'bug'. Proving it MIGHT also be mathematically possible, by designing a test system that would exercise every line of code in every possible way - every possible use case. But I am not sure - if you are dealing with a system that does complex ...


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


28

According to this article, the on-board software for the Space Shuttle came very close -- the last three versions of the 420,000 line program had just one error each. The software was maintained by a group of 260 men and women. A large number of these people were verifiers, whose sole purpose was to find errors. The upgrade of the software to permit the ...


28

Fixing bugs before writing new code is actually one of the twelve points of Joel test. Joel also explains why this is a must-have: In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix. You have a choice: Either you implement a highly requested feature and delay fixing a bug, which will inevitably increase ...


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