Zero bug releases
One of the companies I worked for had a rule which dictated zero bugs in each release. Any bug that was found during the formal QA process had to be fixed before the release could go into production. This sounds like a good idea at first, however, it is fraught with problems:
- Some reported bugs have very low impact. For example, a label might be misaligned a few pixels. Or maybe a certain bug is only seen by internal users. Fixing bugs takes time away from new features, which may be more important. New features drive application development, and focusing on minor bugs slows down the project.
- The requirement to fix every bug led people to fear reporting new bugs. They knew that we would have to spend time fixing it before cutting the release. We did not want the person finding the bugs to decide whether or not to report the bug. All bugs should be reported, and the business should prioritize and decide which ones are worth fixing.
These problems stemmed from the fact that fixing bugs once the software reached formal QA was expensive. Each bug must first be fixed by developers. Then, the tester had to verify the fix (possibly by pushing a new build into a signoff or local QA environment). Once the fix was verified, we had to release a new version of the software in order to promote it to the formal QA environment. Finally, the formal QA had to verify the fix. This entire process took at least half a day, and could take much longer.
Obviously, this process was a point of pain. The time and people involved meant that we should only fix bugs worth fixing, and the business sponsors had the final say.
Comments
-
You know, one of the favorite things I learn from my Comp Sci instructors at Western Oregon University... well, almost 15 years ago, is that there is no such thing as zero bugs. You can be assured I had instructors who were doing real world work! The problem isn't the major defects, it is the human definition of the term bug, which can mean anything from something that melts down the Mars probe to something that does not happen to meet a particular user's UI preferences - even of those preferences are in direct contradiction to some other user's UI preference (unit test THAT with FITNESSE... HA!)
-
- Don't treat each support incident as a bug. "zero bugs" practice assume bug report as "confirmed bug". - Bugs have severity. Healthy practice is to fix minor bugs only when you have time (in practice - never :-))
-
Zero bugs, haha, such a nice thought. We categorize our bugs as priority 1, 2 and 3. For a build to progress to release candidate stage it has to have no priority 1 and 2 bugs. So there could be as many priority 3 as you like, as these are low impact bugs.