The Battle of the Bug

Software defects become more costly to find and fix as a software project moves from design to development to testing and deployment. However, many teams struggle to define an effective defect management process.

Because of difficulties categorizing, reproducing, and setting the importance of defects—as well as timing and verification of fixes—these struggles often consume valuable project time and can slow down the release of new features. In the very worst case, they can paralyze ongoing project work and cause a project to fail.

The cause of much of this struggle is that project participants often have different motivations in the defect management process. Developers, who consciously or unconsciously interpret defects as a reflection on their understanding of the project or on their professional skills, prefer to minimize the perceived importance and impact of issues.

Many testers validate their existence by finding defects and calling attention to issues that may otherwise be resolved quickly and without debate. Project managers are focused on staying on schedule and ensuring milestones are met. Lacking agreement on the defect management process, team members can spend hours in futile meetings and other exchanges without coming to a resolution on how to proceed with specific defects.

The solution to this challenge is a well-defined and documented defect management process. An important part of project kickoff has to be an agreement on defect management for that project. The agreement should include the categorization of defects, a protocol for determining their severity and when to fix them, and an escalation process in case of disagreement.

Once agreed to, the process should be documented as a workflow and enforced automatically through defect management software, so there is no debate about how defects will be handled during the project. Individual defects that meet predefined criteria can be resolved and scheduled in a matter of minutes with little or no discussion.

For defects that don’t meet predefined criteria or can’t be easily categorized, the workflow should include an escalation procedure that ensures defects are efficiently analyzed, evaluated, and dispatched according to the predefined process. Some issues may in fact be challenging—with team members disagreeing about how to proceed. What you don’t want is a situation where those hard choices cause disagreement and debate that delays the project.

Workflows, Decision Timelines, and Approvals
This approach requires a workflow that includes explicit actions to take on defects at every step, set lines of responsibility, timing checks to ensure the process doesn’t bog down, and formal approvals to make sure decisions aren’t revisited. The workflow defines the steps taken from when a defect is logged in to when it’s resolved, including if and when to fix it.

No one likes defect triage meetings. The only thing worse than long triage meetings is a contentious meeting where few definitive decisions are made. Getting bogged down in meetings is one certain way to cause a project schedule to slip. Unless the software is perfect, the only way to avoid these meetings is to agree on a process and classifications beforehand and to enforce them with a defect management workflow.