From a high-level view, defect management systems are made up of a combination of some defect management tools or tool and a defect management process. These two primary components work together to support each other. Ignore either one, and sub-optimal results can be expected. Below I will provide an overview of a typical defect management process. I will also list the key features to look for in an effective defect management tool. All of this information will be useful for you to review. But I would be remiss if I left out one of the most overlooked aspects of software defect management that goes beyond tools and processes, which I will also disclose later in this article.
Defect Management Process
High Level Steps in a typical defect management process:
The typical defect management process includes the following high level process steps. When implemented inside of a specific organization, each of these high level steps would have more detailed standard operating procedures along with policies to carry out the details of the process.
- Identification–This step involves the discovery of a defect. Hopefully, the person discovering the defect is someone on the testing team. In the real world, it can be anyone including the other individuals on the project team, or on rare occasions even the endcustomer.
- Categorization–When a defect is reported, it is typically assigned to a designated team member to confirm that the defect is actually a defect as opposed to an enhancement, or other appropriate category as defined by the organization. Once categorized, the defect moves on in the process to the next step which is prioritization.
- Prioritization–Prioritization is typically based on a combination of the severity of impact on the user, relative effort to fix, along with a comparison against other open defects. Depending on the size and structure of the organization, the prioritization is often handled by a formal change control board. The priority should be determined with representation from management, the customer, and the project team.
- Assignment–Once a defect has been prioritized, it is then assigned to a developer or other technician to fix.
- Resolution–The developer fixes (resolves) the defect and follows the organization's process to move the fix to the environment where the defect was originally identified.
- Verification–Depending on the environment where the defect was found and the fix was applied, the software testing team or customer typically verifies that the fix actually resolved the defect.
- Closure–Once a defect has been resolved and verified, the defect is marked as closed.
- Management Reporting–Management reports are provided to appropriate individuals at regular intervals as defined reporting requirements. In addition, on-demand reports are provided on an as-needed basis.
Defect Management Tools
Features of a defect management tool:
Following are the core features of a defect management tool:
- Provides a centralized repository for tracking defects across projects.
- Provides automated notifications of resource assignments.
- Ability to define defect resolution status in order to map back to your defect management process.
- Ability to provide management reporting, like the number of open defects grouped by various criteria such as open defects by project, severity, and priority.
Following are a few optional features worth mentioning when selecting a defect management tool:
- Ability to capture other items in addition to defects, such as customer suggestions and project-related issues. Items such as customer complaints or enhancement suggestions are often lost if not logged in a centralized system. If other tools are not already available, a defect management tool can be used to track these types of items as long as they can easily be filtered out or logically separated from defects.
- Ability to support internal and external teams. This feature provides the opportunity to involve external teams and in some situations, customers if appropriate.
Another consideration when selecting a defect management tool includes ease-of-use. Comparing a list of features is useful, but seeing how intuitive a system is to the people who have to use it provides a more concrete sense of how much training might be needed along with how well the system will be received.