- Testing Axioms
- Software Testing Is a Risk-Based Exercise
- Testing Can't Show That Bugs Don't Exist
- The More Bugs You Find, the More Bugs There Are
- The Pesticide Paradox
- Not All the Bugs You Find Will Be Fixed
- When a Bug's a Bug Is Difficult to Say
- Product Specifications Are Never Final
- Software Testers Aren't the Most Popular Members of a Project Team
- Software Testing Is a Disciplined Technical Profession
- About This Article
The Pesticide Paradox
In 1990, Boris Beizer, in his book Software Testing Techniques, Second Edition, coined the term pesticide paradox to describe the phenomenon that the more you test software, the more immune it becomes to your tests. The same thing happens to insects with pesticides (see Figure 3). If you keep applying the same pesticide, the insects eventually build up resistance and the pesticide no longer works.
){kind=link}
Software undergoing the same repetitive tests eventually builds up resistance to them.
In the spiral model of software development, the test process repeats each time around the loop. With each iteration, the software testers receive the software for testing and run their tests. Eventually, after several passes, all the bugs that those tests would find are exposed. Continuing to run them won't reveal anything new.
To overcome the pesticide paradox, software testers must continually write new and different tests to exercise different parts of the program and find more bugs.
|
Code-and-Fix Model The code-and-fix model shown in Figure A is usually the one that project teams fall into by default if they don't consciously attempt to use something else. It's a step up, procedurally, from the big-bang model, in that it at least requires some idea of what the product requirements are. The code-and-fix model repeats until someone gives up. A wise man once said, "There's never time to do it right, but there's always time to do it over." That pretty much sums up this model. A team using this approach usually starts with a rough idea of what they want, does some simple design, and then proceeds into a long repeating cycle of coding, testing, and fixing bugs. At some point they decide that enough is enough and release the product. As there's very little overhead for planning and documenting, a project team can show results immediately. For this reason, the code-and-fix model works very well for small projects intended to be created quickly and then thrown out shortly after they're done, such as prototypes and demos. Even so, code-and-fix has been used on many large and well-known software products. If your word processor or spreadsheet software has lots of little bugs or just doesn't seem quite finished, it was likely created with the code-and-fix model. Like the big-bang model, testing isn't specifically called out in the code-and-fix model but does play a significant role between the coding and the fixing. As a tester on a code-and-fix project, you need to be aware that you, along with the programmers, will be in a constant state of cycling. As often as every day you'll be given new or updated releases of the software and will set off to test it. You'll run your tests, report the bugs, and then get a new software release. You may not have finished testing the previous release when the new one arrives, and the new one may have new or changed features. Eventually, you'll get a chance to test most of the features, find fewer and fewer bugs, and then someone (or the schedule) will decide that it's time to release the product. You will most likely encounter the code-and-fix model during your work as a software tester. It's a good introduction to software development and will help you appreciate the more formal methods. |
){kind=link}