One of the things that I see going by the wayside in most places is the bug triage process.  The step of taking incoming issues and validating them and prioritizing them. It’s a real shame when that happens; both of those functions are important. Establishing the priority of the defect relative to the existing work is arguably the more important for delivering the most value per unit time. However, validating the issue is the single most useful thing that can be done. It provides two main benefits. First, it makes sure that the issue is ready to be worked, that it’s not going to waste the time of people downstream in the process trying to figure out what the problem is. Secondly, it’s the quality assurance on the quality insurance process.

Auditing the QA process is an overlooked thing that gets lost in the attempt to increase velocity. Increasing velocity is all about doing things more efficiently. Doing the right thing at the right time. That’s exactly what the bug triage process is about. When you insure that bug reports are clear and reproducible from the information in the report, it saves a lot of time. Taking that moment to figure out how to exercise the bug decreases the amount of time to work on the issue for every other person involved with that issue.

To start with, after reproducing the problem, the person doing the triage really understands the issue and can better prioritize fixing it. You would think that the benefit of this would be obvious; I’m always surprised at the number of people that say “I don’t need to understand the problem, I’m only assigning the priority to it.” If all the triage process is doing is glancing at it and assigning a priority, that’s a job better handled by a shell script or other piece of automation.

The most valuable part of that is to QA to QA process. Providing feedback to QA about the quality of their work. If an issue can’t be reproduced, then it needs rework before it can be worked on. Identifying that early in the process is a good thing, it requires a lot fewer resources than identifying that later. It’s basically applying agile methodology to parts of the typical workflow within an agile process.  Shortening the amount of time between the action and feedback on it, so that course corrections can be made more easily.

The other main benefit is that it allows the QA person to improve their results. Getting that feedback and being required to explain the bug more clearly means that future issues will also be more clear.  There are very few good people that aren’t interested in how to do their jobs better. That feedback for a QA person to know how they’re doing is the key way to know how to do that aspect of their job better.

If the process is only ever going to be an issue is submitted, then the developer sits down with the submitter talks about the issue until it’s understood and then can work on it, you may was well have every issue just entered as “I have a bug, see me”. That would make it very quick to enter issues and reflects that process, but we all know that it would be a real time suck for everyone involved.

This is an area where as an industry we don’t want to spend the effort to improve.  It’s considered irrelevant to agile processes.  That’s wrong, improving the process is the heart of any agile process, by definition. It’s time that we invest the time in working on a frequently neglected part of the development process.

 

Advertisement