A Defect is an application/document anomaly or a flaw. Symptoms of faults in applications/documents that are sufficiently mature for testing are considered Defects. In other words, a deviation from the expected outcome is termed a Defect. The defect management process is the same for any velocity of the program. Jira is the tool to capture Defects and track them.
Changes required in current Jira workflow – Jira has defined defect workflow as the same as user story workflow. Defect workflow has to be modified to reflect all types of priorities, severities, same workflow consistently across the projects and programs. So that, it will ensure data consistency while capturing and helps to automate the metrics dashboard with a single approach and with more data accuracy. Guidelines for all critical areas of the defect management process are provided in the below sections.
Defect Prioritization
Defect Severity:
Defect severity is used to determine how the defects must be attended to. Defect Severity is a classification of a software/document anomaly or flaw based on the degree of impact the error or fault has on business operations, the development of a system, or the operation.
In Jira, the field ‘severity’ is not being used; instead, an issue has a priority level which indicates its importance being defined by the backlog prioritization list.
The best indicator for defining severity is the impact on the business. However, when Quality Engineers raise defects, the impact on business may not be immediately known. Furthermore, certain defects that cause significant disruption in testing or development efforts, or affect many users, may still be classified as high severity.
The currently defined priorities are listed below. The Severity Levels are:
Defect Status/Jira Workflow
The Defect Status provides insight into activities underway for the defect identified.
| Severity Level Definition | IEEE | JIRA | Priority Prioritiztion |
|---|---|---|---|
The defect results in the failure of the complete software system, of a subsystem, or of a software unit (program or module) within the system. This means a show-stopper in terms of the testing activities or a potentially catastrophic impact on business after the system or application is put into Production. |
1-Critical |
Blocker |
Blocks development and/or testing work, production could not ru |
The defect results in the failure of the complete software system, of a subsystem, or of a software unit (program or module) within the system. There is no way to make the failed component(s) work as they are. However, there are acceptable processing alternatives that will yield the desired result. |
2-Major |
Critical |
Crashes, loss of data, severe memory leak |
| The defect does not result in a failure, but causes the system to produce incorrect, incomplete, or inconsistent results, or the defect impairs the system’s usability | 3-Average |
Major |
Major loss of function |
| The defect does not cause a failure, does not impair usability, and the desired processing results are easily obtained by working around the defect | 4-Minor |
Minor |
Minor loss of function, or other problem where easy workaround is present |
| The defect is the result of non-conformance to a standard, is related to the aesthetics of the system, or is a request for an enhancement. Defects at this level may be deferred or even closed because no action will be taken | 5-Exception |
Trivial |
Cosmetic problem like misspelled words or misaligned text |
| JIRA Status | Description | |
|---|---|---|
TO DO |
Defect or bug is logged pending review and assignment. |
|
ANALYSIS |
The defect or bug is currently being analyzed. |
|
PRIORITIZED |
The defect or bug in the JIRA backlog is being reviewed and prioritized by the product owner |
|
IN PROGRESS |
The defect or bug is being assigned to a resource to resolve the defect. |
|
CODE REVIEW |
The code is currently being reviewed and not ready for QA testing. |
|
READY FOR QA |
The assigned resource has corrected the defect or bug. |
|
IN QA |
The correction has been placed in the QA test environment to be validated by a test resource. |
|
READY FOR REVIEW |
The defect or bug has been tested by a QA resource and waiting for review. |
|
IN REVIEW |
The corrected defect was reviewed and/or tested and was found to satisfy the requirement /acceptance criteria or technical design specification or need to be re-opened. |
|
DONE |
The corrected defect or bug was found to satisfy the requirement/acceptance criteria or technical design specification. |
|
CLOSED |
The corrected defect or bug was found to satisfy the requirement/acceptance criteria or technical design specification. This status is not always used. |
Defect Type
All the defects logged in testing are predominantly categorized by commonly occurring root causes, as described below. This is captured under the “Root Cause” field of Jira. The developer must update this field when marking the defect as Fixed.
| Status | Status Definition | |
|---|---|---|
Code |
Defect related to a code issue |
|
Content/Configuration |
Defect about a configuration error |
|
Network/Environment |
Defects related to environmental issues |
|
Requirement |
Defect related to requirement error |
|
User/Tester Error |
The problem was with the tester, or the person who found the bug |
Defect Management Process Capability Deployment
Defect Identification and Submission
| Entry Criteria | Responsibility |
|---|---|
The test case failed during execution, and a defect was found |
QE Specialist |
Key Activities:
| Activity | Responsibility | Deliverables/Outputs |
|---|---|---|
Log a defect in Jira with Status = “To Do” |
QE Specialist |
The new defect created in the corresponding Jira project and linked with a test case (for traceability)
|
Assign it to Defect Manager for triaging |
||
Link the defect to the corresponding test case in Jira |
Exit Criteria:
A new defect is created and assigned to Developer for analysis or Release Quality Manager (RQM)/QE Specialist for triaging
Defect Triaging:
| Entry Criteria | Responsibility |
|---|---|
A new defect is entered into Jira for the project |
Release Quality Manager (RQM)/ Quality Engineer |
Key Activities
| Activity | Responsibility | Deliverables/Outputs |
|---|---|---|
Discuss the weakness in the triage meeting (Validate severity, priority)
|
Release Quality Manager (RQM)/ Quality Engineer |
A validated defect was assigned for remediation |
Validate that the defect is an actual defect, as confirmed by the development team in the triage call. |
||
Assign the defect to the correct development team or developer for remediation OR cancel the defect if not valid.
|
Exit Criteria:
The defect is prioritized, determined to be valid and assigned to the correct development team for remediation.
Alternatively, if the defect is invalid – the defect is marked as CLOSED, and Root Cause for the defect is updated
Defect Triage Meetings (if required)
Defect Triage Meetings are where outstanding defects are discussed to prioritize, discuss workarounds and assign defects to the development team. Defect Triage Meetings are chaired by the
ART Release Quality Manager (RQM) assigned for the project/release. Meeting frequency occurs regularly, as defined in the test strategy, depending on the project’s volume of defects and criticality of release.
| Purpose |
|
| Attendees | TBD |
| Frequency | As indicated in the test strategy |
| Inputs | List status TO DO, need more information or rejected defects, ordered by severity and then by status (e.g. Critical New defects first) |
| Outputs |
|
Defect Remediation:
| Entry Criteria | Responsibility | |
|---|---|---|
A new defect is triaged and assigned to the development team for remediation. |
ART Release Quality Manager (RQM) |
| Activity | Responsibility | Deliverables/Outputs |
|---|---|---|
Fix the defect in the development environment
|
Developer |
Updated Jira defect |
Assign to Dev Lead / Environment team for deployment |
||
Post Deployment – update defect status to “Ready for QA” |
Development Lead |
|
Assign defect to Quality Engineer to Retest |
Development Lead |
Exit Criteria:
The defect is either the “Ready for QA” . Defect details explaining the fix/reason for rejection are mentioned
Exceptions / Alternate flows
Developer Needs more information (from QE team) for remediation
| Activity | Responsibility | Deliverables / Outputs |
|---|---|---|
|
Quality Engineer |
Updated Jira defect with Question |
Invalid Defect:
| Activity | Responsibility | Deliverables / Outputs |
|---|---|---|
|
Development Lead |
Updated Jira defect |
Defect Closure & Retest the Defect:
| Activity | Responsibility | Deliverables/Outputs |
|---|---|---|
| The defect is fixed and re-assigned to Quality Engineer in the “READY FOR QA” Status. | Development Lead | Updated Jira status |
Retest the defect
|
Quality Engineer | Updated Jira status |
Exit Criteria:
The defect is either “DONE” or “IN PROGRESS”
“DONE” is the final status. “IN PROGRESS” implies the defect is not fixed and must be remediated again.
Roles & Responsibilities:
| Role | Responsibilities |
|---|---|
Defect Manager (RQM) (Defect Manager might be played by ART Release Quality Manager (RQM) in many projects) |
Review critical/high-severity defect ownership
Review rejected defects
Review critical/high severity defect business priority and technical severity
Defect Triage Meeting Minutes
Identify defect trends and deviations above threshold values in key performance indicators related to defects.
Develop and present Root Cause Analysis Report to Leadership
|
Defect Originator (Quality Engineer) |
Log Defect in Jira with steps to recreate Review the defect fix described in the defect record Prepare/re-execute failed test cases for system defects Reopen the defect and assign it back to the correct team; if the defect retest fails |
|
Correct requirement errors
Participate in Defect Triage meetings as needed
Provide solutions/clarifications as needed |
| Development Lead |
|
| Jira Tool Admin |
|
