In the previous post we’ve considered the 8 stages of a regular defect management process. However, the right functioning of your defect management system greatly depends on the tools you will choose to utilize.
Defect management tools should have the following core features.
- Having a centralized repository aiming at tracking defects throughout the projects.
- Providing the automated notifications about resource assignments.
- The ability to define the status of defect resolution so that to map back into the defect management process.
- The ability to deliver management reporting, such as a set of open defects classified by various criteria like defects by project, priority and severity.
Here are also some optional features that should be considered while selecting a powerful defect management tool.
- The ability to capture not only defects such as project-related issues and customer suggestions, but also other Items like enhancement suggestions or customer complaints which often get lost if are not logged in the centralized system. In case other tools are unavailable, your defect management tool may be used for tracking these items types as long as it’s possible to easily filter them out or separate from defects logically.
- The ability to support either internal or external teams. The feature gives the opportunity to engage external teams and customers in some situations, if appropriate.
In addition, your defect management system’s effectiveness also depends on the organizational culture in which it operates. It makes sense for most environments to utilize processes and tools that focus on the tracking, identifying and defect resolving speed. This gives the basis for perceiving root cases as well as making appropriate improvements in the process. If the team (or organization) culture considers defects negative, people tend to spend more time while trying to avoid them and are also less likely to provide report on defects when encountered. All this may lead to many defects identified later during the process, when it’s harder and more expensive to fix them.
As practice shows, organizations considering defects part of the process tend to deliver software faster and of higher quality than those considering defects negative occasions worth blame.