Defect Tracking
Overview
Defects uncovered during QA activities, with the exception of unit testing, will be log. Defect reports will be recorded in the JIRA Issue Tracking system. Before recording a new defect, testers should:
- Verify that the problem can be re-created.
- Check the existing logs to ensure this problem has not already been recorded and is currently open or has been accepted.
Defect Tracking Lifecycle
The diagram below shows the lifecycle of a defect report.
Defect Tacking Processes
Typelists
Defect Statuses
Use these values in the Issue Settings - Statuses
| Open | The issue has been created and is ready to be assigned. |
|---|---|
| In Progress | The issue has been assigned and is being worked. |
| Pending Verification | The defect report is awaiting verification by reporter. From here issues are either reopened, or are closed. |
| Closed | The issue is considered finished, the resolution is correct. Issues which are closed can be reopened. |
| Reopened | This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved. |
Priorities
Use these values in the Issues Settings - Priorities.
| Critical | A significant number of test cases and testers have been affected and are unable to continue testing. |
|---|---|
| High | Testing cannot continue on this test case. |
| Medium | Testing can continue with conditions. |
| Low | Problem is visual in nature. |
| Unknown | The priority of the defect is unknown. |
Severity
Add Severity as a custom field with these values:
| 1 - Catastrophic Error |
| 2 - Major Functional Error (default) |
| 3 - Minor Functional Error |
| 4 - Minor cosmetic errors |
Resolutions
When a defect is resolved, a resolution that most closely describes the defect will be selected. This field is mandatory.
| Accepted – Technical decision | Selected when the defect has been accepted for technical reasons. Usually used when the defect has little or no impact to the function or the fix was so complex and significant that a decision has been made not to pursue it further. |
|---|---|
| Accepted – Workflow | Indicates the defect has been accepted and can be incorporated into the workflows. Usually used when the defect is very minor or cosmetic in nature. |
| Configuration Error | Used when the cause of the defect is determined to be a problem in the configuration of the system. |
| Data Error | Used when the cause of the defect is determined to be an error with the data. |
| Deferred | A fix for the defect has been deferred to a future release. |
| Design Error | Selected when the report was generated due to an error in the design. |
| Duplicate | Indicates another issue had already recorded this problem. |
| Environment Error | Selected when the cause of the defect is determined to be a problem with the test environment. |
| Fix Rejected | Selected when the original fix(es) for a defect had been rejected. |
| Future Iteration | A defect is written for a failed result, but a decision is made not to make the fix because the requirements for a future iteration are changing the expected results. |
| Integration Error | Indicates the issue was generated due to a defect in the integration code. |
| Legacy Error | Indicates the issue was generated due to a defect in the legacy code. A fix has been implemented to resolve the problem. |
| Production Problem | Used when the cause of the defect is determined to be in the production code, rather than the program being tested. |
| Regression Error | The defect was fixed and then reappeared. |
| Specification Error | Used when the issue was generated due to an incorrect or missing requirement or specification. |
| Unable to Recreate | Issue cannot be recreated by developer or testing team. |
| Working as Designed | Used when a report has been opened for an issue that is not a defect in the code or the requirements. The program is working as intended. |
by William Shaffer