Regression bugs, are they really a sign for bad quality, or for innovation and improvement?

The definition for a regression bug may vary from one organization to another. In this blog, I will use the definition of the regression bug as appears in the Wikipedia:

“Regression bugs occur whenever software functionality that previously worked as desired, stops working or no longer works in the same way that was previously planned. Typically regression bugs occur as an unintended consequence of program changes”

In all organizations that I worked for, a regression bug is a big scandal. KPI's are set to count number of regression bugs for every developer, and for every component or business area. There may be another grouping level to categorize regression bugs before and after deployment. While we should acknowledge that a regression bug gives a very bad impression about the development team and the product quality, we should also ask several questions:

• In which context was this bug opened? Was this a refactoring effort for improving the code? Or was it a side effect of normal day to day development?

Rod Johnson, in one of his excellent lectures: "Why J2EE Projects Fail", identified 10 reasons why projects fail. One of these was not being open for refactoring and change. If regression bugs are due to improvement, or refactoring effort that is done to enhance to code, then, this bug should not be counted against the development team.

Counting such bugs against the development team, and evaluating them accordingly, will effectively kill the open atmosphere for change. If the project old code is never touched, and the team is intimidated not to do so, then the product code will deteriorate over time, the level of complexity will rise, simple bugs will become complex, and complex bugs will become sever. At one point of time, maintaining the product will cost so high and customers will search for other solutions.

Ok, what should be the solution? Here is the key:

• Never do a refactoring for a component except after writing automated unit tests for the component functionality. This is like writing a contact with the code. If the code does not keep this contract, simply do not deploy the code. For a simple guide for stages of refactoring legacy code, refer to my later blog: Measuring the Progress of Code Refactoring.
• Write automated test scripts for old bugs. Bugs show a tendency to be reproduced. The reason is that developers think the same way. If a component is refactored or re-written, the bug that the first developer fixed sometime ago and never wrote a test script for it; this bug surely will be reproduced by the developer who is refactoring or re-writing the component.