Know When To Release |
 |
 |
 |
| Written by Graham Stoney | |
|
If your goal is to release a quality product, or there are safety implications associated with defects in your software, then you must have an objective criteria for knowing when it is ready to release beyond simply what your marketing department or project plan might set as a release date. Some sensible metrics can help here, and your defect tracking and source control systems can help a lot here. At the very least, you should wait until all your show-stoppers have been fixed, and the rate at which defects are being fixed exceeds the rate at which defects are being found. If you have sufficient resources applied to testing in order to find currently unknown defects, you can infer the point at which the total number of defects is under control by noticing when the rate at which defects are being discovered by ongoing testing falls below the rate at which they are being fixed. Until you reach this point, you haven't passed the “hump” in the defect detection rate, and it's too early to release. If you aren't even fixing defects at the rate they are being discovered, then put your upcoming holiday plans on hold; you have much work still to do. I wrote a script to graph these using statistics from our Perforce server so it was visually obvious at which point the number of defects being discovered was starting to fall and how the rate of bug fixing compared. This gave me an objective basis to argue that more testing was required when some developers thought it was time to ship just based on gut feel. As Nick Hornby points out, people who fly just by gut feel have shit for brains. Social Bookmark this page:         
|