Managing bugs is difficult. Often bugs become a battleground within a company. Questions like which bugs to fix when or what amount of bugs is ok to ship a release with becomes unclear and divisive. It take a little process and a lot of leadership to address bug management.
Here are the basics:
- Improve quality so you do not have as many bugs
- Provide clear direction on what bugs to fix
- Track and forecast the trend and effort to meet your goals
We know that we are not perfect developers but there are some good hygiene things that all companies should adopt in order to improve quality:
- Do feature/design specifications and reviews
- Do code reviews
- Require automated passing exhaustive feature unit tests before code complete
- Determine and review root cause for bugs
It will always be better to catch bugs early or better yet never create them. You should pay attention to why bugs occur and help your organization address those reasons. One of the big issues in many companies is how to prioritize bugs. The first problem stems from ambiguous categories like priority described with P1, P2, P3, ... and the plethora of other categories like severity, customer priority, etc. While your company many need to gather the emotion and need of your customer regarding a bug, the only thing your engineers should care about is when to fix a bug. Here are my suggested categories:
- Now (either for a patch or release build)
- Must fix for a particular release
- Should fix for a particular release Future
Don't confuse your engineers with overloaded codes. Make sure that bug backlogs that "must be fixed" for a released are legitimately scheduled and are not expected to be addressed in someone's overhead or free time. Make sure product management prioritizes the bugs in the must-fix categories appropriately and that you have resources allocated to fix them.
Finally, as I said in a previous blog, you need to track the trend of bugs. If your incoming rate does not go down, it does not matter how many bugs you have fixed, you will not have a stable release. Set an outstanding bug goal for your release acceptance criteria. Forecast when you get down to the bug goal for the release and manage to the forecast. Remember that there is always a tail and if you do not defer some bugs for the next release at the end of the cycle, you may never close on the current release. Bugs are tough. Pay attention and make your products quality products.
More later ...
No comments:
Post a Comment