Testing 9

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 1

What exactly is a "Bug Triage"?

The word "Triage," which is used in the medical field, comes from the French word "Trier," which means to sort
or sort out. The definition of this phrase includes the actions of separating, selecting, and sorting. In the context
of software testing, it is used to determine the severity and priority for new problems. It is appropriate for big
projects only, since this is the only circumstance in which a significant number of serious defects may be
expected to arise.

Bug triage is a procedure that involves identifying and ranking the many problems that have been reported in the
tracker. It is helpful in ensuring that the reported problem, regardless of whether it is a bug, an improvement, or
a feature request, is handled correctly. The Bug Triage Meeting is convened based on the defects that were
reported by the testing team after the QA Team begins the process of test execution and begins reporting the
issues. Bug Triage Meetings, also known as Bug Councils, are meetings for the project in which open bugs are
sorted into three distinct categories: bugs to be fixed immediately, problems to be fixed later, and issues that will
never be fixed. The Quality Assurance Lead, the Development Lead, and the Project Manager are all present at
this meeting. The Quality Assurance Lead is in charge of facilitating the Bug Triage Meeting, and the primary
objective of this meeting is to take action on the most pressing defects. The status of the project will determine
how often these meetings take place.

To properly prioritize a problem, you must:

1. Determine if the description of the fault that was provided by a tester is sufficient to enable the developer to
grasp the nature of the issue with relative ease. In the event that this is not the case, the triage team should
reassign the defect to a reporter and ask for the reporter to provide any further information that would be
necessary in order to have a complete knowledge of the problem.

2. Determine if the issue has been reported under the appropriate project and module. 3. Determine if the
"Severity" and "Priority" columns for the fault are complete and accurate.

You might also like