I had a senior Quality manager decide to help us out in our defect reviews.  He, being new, wanted to talk about each and every defect that we had to review.  He wanted to try and fully understand all those defects.  He wanted to do this in our defect review meeting.

He couldn’t understand why I was “rushing him on” and moving onto the next defect before he was able to fully understand it.  He didn’t get it that it would take us a week to review just the new defects that came in today with his approach.  We knew this because when I took over the meetings, that is what was happening.  With his approach, we would get a new batch of defect reports the next day, but we couldn’t look at those because we were still reviewing, discussing, and asking more questions of programmers about the defects that came in yesterday.

The review process had been completely broken.  By the time the review team could completely understand and hence make a decision about the priority and importance of a defect, the defect was either already fixed or found out to be an already understood defect or turned out to be a testing error and not a defect at all.

See related Meeting Madness?  Don’t Do It!

The new Quality manager was certain that all we needed to do was understand. Which meant to be educated by the rest of the organization that was trying to do their job to fix the defects. He was sure that we would then be able to prioritize the defects so that they were fixed in the right order and nothing really important was under-prioritized.  Previously we had tried for years to take this approach.

Compare with Are Self Managing Teams Really Possible?

Instead, our current approach resulted in us reviewing on average one defect per minute. We knew in broad terms where the defect stood in being resolved (e.g., was someone assigned the defect? was it recreatable? did the programmer understand the defect? did we have a fix yet? was the fix tested?)  We were able to keep up with the incoming reports of defects and we had a clean and concise history of each defect. This helped us to characterize and then prioritize defects as a whole and to decide if we even needed to change how we prioritized and repaired defects.

See more in Defect Reports Are Our Best Friend

The key to this whole process was a laser focus on what we were trying to achieve and the ability to do the work rapidly.  The quality manager’s desire to intuitively improve the process only slowed it down without adding any real value.  He (and others)  were just sure that if we asked more questions and better understood each and every defect we would somehow better and faster eliminate the backlog of defects.  It never happened.  It did the opposite.

The ability to intervene and understand hundreds of issues being worked by hundreds of programmers was never achieved.  Instead, when left to our own devices our tracking and quick review with the programmers were able to successfully resolve all the issues, deliver on time and even improve the quality of the software so much, that successive releases confounded testers because they could no longer readily find errors.

For more on this see Want To Stress Your Test Team? Give Them Good Quality!

Make sure that what we do really adds value, and doesn’t just get in the way of people who know how to do their job.

Is the help you are providing supporting or hindering your project?