Bug/Defect Triage Process in our internal

Testing Process

By Quality Assurance Team

Tranzact
2019
 Defect Triage Process
• Considerations
• Defect Triage Meeting
• Frequency
Overview Defect Severity Defect Priority Jira Workflow Process Glossary
• Involved Parties
• Responsibilities by Role
/ • Outcome

Contents
Overview
The word “Triage” is basically used in
the medical field.

Actually, the term Triage is introduced in

software testing for defects in the
application or a project to define the
severity, risk, frequency of recurrence and
priority of defects.
Defect Severity

In our internal Testing Process, Defect severity can be categorized into four class:

Critical: This defect indicates complete shut-down of the process, nothing can proceed further
Major: It is a highly severe defect and collapses the system. However, certain parts of the system remain functional
Medium: It causes some undesirable behavior, but the system is still functional
Low: It won't cause any major break-down of the system
Defect Priority
Defect priority can be categorized into three class:

Low: The Defect is an irritant but repair can be done once the more serious Defect has been fixed
Medium: During the normal course of the development activities defect should be resolved. It can wait until a
new version is created
High: The defect must be resolved as soon as possible as it affects the system severely and cannot be used until
it is fixed
Jira workflow Defect

To Do

In
Canceled
Progress

Fixed
 Defect Triage Process

A member of the team prepare a list of Defects, the same member or different reviews the defects, identify possible
root cause. Defect assessment will be done on the basis of defect severity. In this assessment process, the triage team
will decide whether these defects are needed to be fixed or kept on hold or removed from the list. The defects which
are in the list of “to be fixed” will be assigned to the concerned department/person after proper analysis of the
defects.

Defect Defect Defect

Review Assessment Assignment
Considerations

This process does not apply to all types of initiatives in our Agile/Kanban methodology.
Different agile teams have different processes because they have different needs.

As usual, we discuss in our daily meeting about our internal blocked tasks testing but what happened when
we have more than 15 defects in the same sprint, how we can talk about those defects or other
unpredictable situation in 5 minutes, in this case we need to applies our ‘Defect/Bug Triage Process’.

If you are working in KTLO initiative you can follow Bug Internal Process.
Defect Triage Meeting

Bug Triage Meeting is done to sort out the priority of all open bugs. When and how these open bugs need to be fixed
is decided in this Defect Triage Meeting.

The objective of a triage meeting is to track all the defects and makes sure the correct resolution in a timely manner.
During Defect Triage Meetings, Triage Team decide how to categorize and prioritize defects.

Other activities involve assigning or rejecting new defects created from the last triage meeting.
 THE FR EQUENCY OF
D EF ECT TR I AG E

Frequency M EETI NG I S NOT

F I X ED. I T D EP END S
ON P ROJEC T
S I TUATI ON.
Involved parties
Below members are involved in Defect Triage meeting :

• Release Manager
• Development Team
• Tester
• Product Owner
• Business Analyst
Responsabilities – Test Team (Internal Defect)
Before Triage Meeting

1. Has enough information to understand the defect for all the participants in the meeting.

2. Has reported under correct project and category.

3. Assign priority and severity of the defects.

4. Create a defect Triage report and send it to all attendees before the meeting.

5. Scheduled Defect/bug triage meeting and send meeting notification for attendees.

During Triage Meeting

1. Kicks off the meeting with the pending action items from the previous triage meeting.

2. Discuss each defect and impact on the schedule if any functionalities are blocked due to the defect.

3. Helps in assigning priority and severity of each defect if it was not assigned correctly earlier.

After Triage Meeting

1. Every meeting note is captured and sent to meeting attendees (MOM).

2. Tracking agreement of the meeting.
Responsabilities – Development Team
Before Triage Meeting
1. Share updates on the action items pending from the last triage meeting.
2. Assists in identifying the root cause of the defect.

During Triage Meeting

1. Discuss all the defects from a technical perspective.
2. Identify how much time it will require for fixing based on the complexity of the defect and functionality.
3. Discuss the complexity of the defect and risk associated with the defect if any.
4. Development Lead assigns defect to the appropriate developer after validating all the available detailed.
information.

After Triage Meeting

1. Updates the defect with the expected resolution date.
Responsabilities – Release Manager
Before Triage Meeting
1. Ensure that if all the representative from every area is available for the meeting.

During Triage Meeting

1. Help in the prioritization of the defects.
2. Acts as a mediator if any dispute or conflict happens between the teams and takes the necessary decision.

After Triage Meeting

1. Take the confirmation from the development team for the release target date for QA.
2. Make aware of the updated schedule and release date of the initiatives to all the teams.
3. If the defects are not moving or if there is any major blocker then escalates with the escalation process.
During Meeting – All parties
Once the meeting kickstarts, participants in the meeting discuss the previous triage meeting’s pending issues.
Then they move on to the report which was circulated by Test Lead to review and evaluate. In this process, defect description or
Severity and Priority of the defect will be updated, if something is inappropriate.

Triage Team in the meeting look into the issues and come to a conclusion on which defects should require immediate attention and
which defects can be postponed for future releases. In the initial stage of the project, even the lowest priority bugs will be accepted to
fix it. When the deadline is reaching, teams will concentrate more on high priority bugs and keep others on hold
In this meeting are resolved questions as what…

• We are going to fix this now.

• We are going to fix this later.
• We are never going to fix this.

Status of the bugs will be updated and assigned to the respective teams
Finally, Test Lead calls out for the meeting after taking a note of all the action items.
Outcome – Post Triage Meeting

At the end of every meeting, Defect Triage Metrics will be prepared and given to all the attendees. This report acts as the
meeting minutes which will prove helpful for future meetings.

Related to Internal defect

After the triage meeting, Test lead or member representative of QA Team shares the MOM (Minutes of meeting) to the
Triage Team.

Related to UAT Bug

After the triage meeting, Product Owner shares the MOM (Minutes of meeting) to the Triage Team.

If Product owner found issue in UAT Testing then she/he should perform report issue, but you as assigned QA
member should track and prepare the standard outcome of this process, and then store in our QA Lesson
Learned Repository.
 Priority of a defect is related to
Severity of a defect is related to how quickly a bug should be
how severe a bug is. Usually the fixed and deployed to live
severity is defined in terms of servers. When a defect is of high
financial loss, damage to severity, most likely it will also
environment, company’s have a high priority. Likewise, a
reputation and loss of life. low severity defect will normally
have a low priority as well.

Glossary

A bug is the A defect is a variation or

consequence/outcome of a deviation from the original
coding fault. business requirements.
Anexo 1 – Sample Template Defect Report Format

Jira ID Defect Title Created Report By Assigned to Severity Priority Status Resolution Root Caused
Date

9856 HMA – Failing 01/15/19 Kim Bass Arturo Critical High Open Configuratio
Outbound Huerta n
Dialing Deployment
9854 OMA – Call are 01/15/19 Tom Don Carlos Bruce High High Open Configuratio
redirected to n
invalid skill Deployment

9851 HMA-Wrong 01/14/19 Mario Pablo Cortez Medium Low Open Bad
verbiage in Ugarte Configuratio
Agent Scripting n in LM
9853 OMA-Wrong 01/14/19 Celeste Tany Lopez Low Low Open Bad
Campaign Bravo Configuratio
notification for n in LM
16983 AFID
Anexo 2 – Tips to determinate the Severity of a defect

Take some consideration: if the occurrence of a minor-defect is frequent in the code, it can be more severe. So from a user's
perspective, it is more serious even though it is a minor defect.

Critical Non Critical

Outbound Wrong Text in

Dialing Does Agent
not work Scripting

Override
Calendar field
Supervisor
accepts
approval does
characters
not work
 Don’t Forget always Think from the users perspective.

Please send me your feedback we are improved our internal process.