Many software organizations struggle with quality, and even more seem to believe only in the power of testing. The logic is as follows: we have to test, because we have errors, and errors are unavoidable. There's only one hole in the logic. Most errors are avoidable. What's more, they are not just avoidable, they are feasibly avoidable, as well. It would make sense to get rid of most errors before testing, and it would even be economic to attempt. The actions in the organizations betray what the prevailing thinking today is. Regardless of what people say they think, they act like quality is made in testing. The testers get a broken software product to test, and they return it to be repaired. If you think about it, it makes no sense to first produce a broken product and then try to add quality and fix it. You can't add quality as the last ingredient. Quality needs to be sprinkled into the product in each and every phase of the way.

The organizations that invest mostly in testing staff and automated testing tools are committing themselves to the Fixing Fallacy. Fixing Fallacy is the wrongful hope that fixing actually improves the product. Each (correct) individual fix might improve the product in its part, but because we are talking about a complex system, the effect of the fixes isn't the same as the sum of them. Often the repercussions are negative. The idea that the software developers are not responsible for their mistakes, until somebody else finds them has a terrible effect on the dynamic between the developer and tester teams. Although the tester team's job description is mighty clear, it isn't an easy one. For all intents and purposes they will appear to be complaining to the developer team. The software developers see the testers as criticizing their achievements, and even delaying releases and progress unnecessarily. "We could be developing so much faster, if it wasn't for those testers!" you can almost hear the developers muttering to themselves. The developers are of course as wrong as the bus driver who one time in Tampere, Finland said out loud from behind the steering wheel, "this would be such a nice stretch to drive, if I didn't have to stop all the time." Of course the testers are trying to help the developers. Of course the developers are doing their best to not make broken software. Of course the bus driver was happy to pick up paying customers. But of course.

Unfortunately the human nature is what it is. The worst characteristics are often released under stress. Project work in software development can be very stressful. The developers might be just a little tempted to leave some code unchecked if there is a considerable chance that the test team will catch any oversights. Once the test team catches a few annoying careless errors, which the developer team duly repairs, a balance is born. The developer team starts to trust the test team and the test team has legitimate work to do, everything seems to be fine and dandy. The developers will confidently (and carelessly) keep producing code within the time limits mostly worrying about functionality, leaving the quality to the test team. Once the work gets busier, and it usually will, the developers start making more and more mistakes. The test team becomes overwhelmed and errors start reaching the customer. The management will be dumbfounded how such a nicely balanced cooperation suddenly starts to fail so disastrously.

The root cause behind problems with testing is that you cannot fix all errors, no matter how much you test. The developers will inadvertently make their software fail in ingenious ways that avoid detection. It is like an arms race between the developers and the testers. Einstein once said "there are only two things unlimited: the universe and human stupidity. Although about the universe I'm not sure." The principle applies in software too. There is no testing without holes, and errors in software are liquid that will find those holes and pass through them. The testers can bring in the big guns, the automated test environments and create test cases with impressive coverage figures, but they will still be out of luck in the end. The developers create such complicated code that the age of the universe in seconds isn't a large enough number to account for all permutations.

The testers usually lack direct access to the source code. The testers might not possess programming skills, and without the necessary skills to understand the source code, access to it wouldn't make any difference in the test results. Assuming the testers were skilled in programming, lack of time can still effectively forbid them from using source code to aid their testing. The testers are supposed to test that the customer won't see strange problems, and they need to do it quickly. To perform testing quickly you need to raise the abstraction level of testing. You can't test everything to the last detail in a large and complex system. It is just a lucky coincidence that the customer also happens to be an outsider to the software and doesn't usually have access to the source code. Harshly said, you have unqualified (from the point of view of software development, or better put, code construction) or uninformed outsiders trying to make a complex system foolproof by experimenting with it. I wouldn't bet on them succeeding any time soon. Yet many companies believe testing is the only way to quality.

They haven't considered, or simply ignored as too minor, the concerns about the responsibility gap between developers and testers, the insurmountable amount of permutations even an average-sized software system nowadays has, or the simple fact that rework costs. Software with errors is broken and needs to be reworked before releasing. Observing any (real) manufacturing plant would teach the software managers how terribly expensive it is to rework products on the production line. They would see that (real) manufacturing plants are doing all they can to minimize exceptions needing special care and handling. Yet in software, errors are no exceptions. They are an accepted evil.

Too much testing is a symptom dealt with in Chapter 2. "Symptoms". In Chapter 3. "Root Causes" we look at why the symptom shows up. Fallacies are not easy to cure, but they are easy to fall prey to. If you start with no testing at all, introducing testing is sure to bring more reliability to your delivery process. It is easy to think that getting more testing done is always going to be advantageous. There is, however, a point when adding more testing no longer adds any value. Many organizations have already reached this point of no return, but still they keep on adding testing.

The situation is even graver than just wasteful, because testing is no cure, it is just a way to find out that there is a symptom. Finding the cause is another matter and preventing the patient from getting sick in the first place can never happen through testing alone. Tick-the-Code is a vaccine that does prevent code from becoming complex and infested with bugs.