Software defects generally fall into two primary classifications: defects that represent functional misses of a new implementation, or defects that are regressions in the behaviour of the system due to some change. This paper discusses a major reduction in the Time-To-Fix for regressions. In a previous role I lead a team of engineers in implementing this system.
To improve the Time-To-Fix, it was ultimately determined that we needed to resolve two problems that accounted for the majority of the time developers spent dealing with regressions:
- Reduce effort to isolate the regression. Early effort on bug analysis can be greatly accelerated if the guess-work on which change causes the regression is removed. Using bisection provides an absolute level of confidence of the regression trigger. There is no guessing or supposition. I have written on the use of bisection in preference of code diving in this blog post.
- Ensure that the regression goes to the correct team the first time. Reduction of the bouncing around of the defect report is achieved by identifying the engineer who regressed the issue and ensuring that it is fixed by that person or team. In particular breaking the attempt to reproduce, debug, re-queue cycle prevents days of wasted engineering time.
We implemented and deployed the system described between 2008 and 2010. Read on for more information.
Continue reading “Using Regression Isolation to Decimate Bug Time-to-Fix”
use-cases.org - Matthew Tippett's Blog 