Get Your Defect-Tracking Database Back on Track
A defect goes through a lifecycle identified by its status. The typical status path goes from unassigned (upon its initial reporting) to assigned (when a developer is selected to correct the defect) to fixed (after the defect has been rectified by the developer) to closed (after a tester has verified that the defect no longer exists).
Although each reported defect should be properly managed throughout its lifecycle, it’s not uncommon for defects to be ignored or mismanaged, which could compromise the integrity of the defect-tracking database. When this happens, defects could go unfixed, or code fixes may not be verified by the production release.
Before you can resolve a compromised defect-tracking database, you need to know how to recognize one.
How to Identify a Compromised Defect-Tracking Database
A compromised defect-tracking database can be identified by performing a set of database queries. Ideally, each defect should have the status of assigned, fixed, closed, or deferred. Any defect that is not in one of these states is in an indeterminate state, or one that needs to be questioned, and is a potential indicator of a compromised database.
There are a few statuses to look out for:
- Unassigned
- Needs more information, either for the defect management team to determine the next steps or for the developer to understand or recreate the issue
- Developer cannot reproduce the problem
- Reopened because after being reported as fixed by the developer, the submitter has determined it has not been fixed
- Closed parent defects don’t have all their child defects closed
A defect in any of these situations could be a red flag for compromised database integrity.
Why Defect-Tracking Databases Become Compromised
One of the most common reasons is negligence—ignoring or overlooking a defect, failing to enter a defect’s status correctly, or not taking the time to query the database.
Another possible reason is the pressure of overly tight deadlines or higher-priority tasks, which can lead to human error or hinder someone’s ability to follow through with indeterminate issues.
How to Resolve a Compromised Defect-Tracking Database
Performing database queries to identify the indeterminate state defects, and addressing those defects or bringing them to the attention of the appropriate individuals, can improve the integrity of your defect-tracking database tremendously.
You should also keep your eye on unassigned defects. Although a reported defect’s initial status is always “unassigned,” if your query results reveal a defect with a status of unassigned, it’s important to ascertain why the reported defect has not yet been assigned and to deal with it accordingly.
It’s essential to hold defect review meetings periodically. During the test execution cycle, the project’s team members should meet regularly to review and address all open defects.
Each defect that is in an indeterminate state or open should be followed up on in the next defect review meeting. If there are any previously reported defects that are still unassigned at this point, you need to find out why and take the appropriate action.
By taking a little extra time to manage it properly, you can put your defect-tracking database back on track.
