- 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
Not All the Bugs You Find Will Be Fixed
One sad reality of software testing is that even after all your hard work, not every bug you find will be fixed. Now, don't be disappointed—this doesn't mean that you've failed in achieving your goal as a software tester, nor does it mean that you or your team will release a poor quality product. It does mean, however, that you'll need to rely on a couple of traits of a software tester—exercising good judgment and knowing when perfection isn't reasonably attainable. You and your team will need to make trade-offs, risk-based decisions for each and every bug, deciding which ones will be fixed and which ones won't.
There are several reasons why you might choose not to fix a bug:
-
There's not enough time. In every project there are always too many software features, too few people to code and test them, and not enough room left in the schedule to finish. If you're working on a tax preparation program, April 15 isn't going to move—you must have your software ready in time.
-
It's really not a bug. Maybe you've heard the phrase, "It's not a bug, it's a feature!" It's not uncommon for misunderstandings, test errors, or spec changes to result in would-be bugs being dismissed as features.
-
It's too risky to fix. Unfortunately, this is all too often true. Software is fragile, intertwined, and sometimes like spaghetti. You might make a bug fix that causes other bugs to appear. Under the pressure to release a product under a tight schedule, it might be too risky to change the software. It may be better to leave in the known bug to avoid the risk of creating new, unknown ones.
-
It's just not worth it. This may sound harsh, but it's reality. Bugs that would occur infrequently or appear in little-used features may be dismissed. Bugs that have work-arounds, ways that a user can prevent or avoid the bug, are often not fixed. It all comes down to a business decision based on risk.
The decision-making process usually involves the software testers, the project managers, and the programmers. Each carries a unique perspective on the bugs and has his own information and opinions as to why they should or shouldn't be fixed.
What Happens When You Make the Wrong Decision?
Remember the Intel Pentium floating-point division bug? The Intel test engineers found this bug before the chip was released, but the product team decided that it was such a small, rare bug that it wasn't worth fixing. They were under a tight schedule and decided to meet their current deadline and fix the bug in later releases of the chip. Unfortunately, the bug was discovered and the rest, they say, is history.
Intel Pentium Floating-Point Division Bug
Enter the following equation into your PC's calculator:
(4195835 / 3145727) * 3145727 - 4195835If the answer is zero, your computer is just fine. If you get anything else, you have an old Intel Pentium CPU with a floating-point division bug—a software bug burned into a computer chip and reproduced over and over in the manufacturing process.
On October 30, 1994, Dr. Thomas R. Nicely of Lynchburg (Virginia) College traced an unexpected result from one of his experiments to an incorrect answer by a division problem solved on his Pentium PC. He posted his find on the Internet and soon afterward a firestorm erupted as numerous other people duplicated his problem and found additional situations that resulted in wrong answers. Fortunately, these cases were rare and resulted in wrong answers only for extremely math-intensive, scientific, and engineering calculations. Most people would never encounter them doing their taxes or running their businesses.
What makes this story notable isn't the bug, but the way Intel handled the situation:
Their software test engineers had found the problem while performing their own tests before the chip was released. Intel's management decided that the problem wasn't severe enough or likely enough to warrant fixing it, or even publicizing it.
Once the bug was found, Intel attempted to diminish its perceived severity through press releases and public statements.
When pressured, Intel offered to replace the faulty chips, but only if a user could prove that he was affected by the bug.
There was a public outcry. Internet newsgroups were jammed with irate customers demanding that Intel fix the problem. News stories painted the company as uncaring and incredulous. In the end, Intel apologized for the way it handled the bug and took a charge of over $400 million to cover the costs of replacing bad chips. Intel now reports known problems on its Web site and carefully monitors customer feedback on Internet newsgroups.
NOTE
On August 28th, 2000, Intel announced a recall of all the 1.13MHz Pentium III processors it had shipped after the chip had been in production for a month. A problem was discovered with the execution of certain instructions that could cause running applications to freeze. As the baseball legend Yogi Berra once said, "This is like déjà vu all over again."