Defect triage is a process to prioritize the defects based on severity, risk, frequency of occurrence.
Though triaging can be implemented on any sized project, its benefits are more evident and tangible in large-sized projects. The list of defects could be proportionately big for large-sized projects. Alternatively, in a highly agile project that is spinning up, triage can help focus the team on the “right” defects. Either way, the triage process identifies defects that need immediate attention, while some may be deferred.
The triaging mechanism helps in preparing a process for testers and developers to fix as many as possible defects by prioritizing them based on parameters identified and fixed by the team.
Ideally, every test cycle should have regular triage sessions. Frequency can however depend on the number of defects identified with every test.
Every time the defects are reported by the testing team, there are always certain if’s and but’s involved. The developer(s) need to understand “what” defect and “when” was that defect discovered, so they can work on the “why” part of it.
If defects are not recorded, mapped, and reported properly, then the time and efforts involved in identifying the root cause and rectifying them are much higher.
It is worthwhile to note that multiple defects are reported at a time and it is vital to identify which one to fix first based on business and functional needs.
Defect triaging helps the development team to fix the bugs based on their priority and severity. Since all the relevant information about the defect is readily available to them, it makes the fixing process easier and less time-consuming. If triaging is done correctly, then it significantly reduces the time taken between reporting the defect and its resolution.
Automate testing for your web application in THREE days. Start Free Trial Now
The defect triage process involves holding a session with a triage team, which includes stakeholders like Product Manager, Testing Manager/Lead, Development Manager/Lead, and Business Analysts. The goal of this team is to evaluate the defects, assess them, and attach priorities and severity level.
Priorities correspond to business perspective and severity corresponds to technicalities.
Many times, few defects may be considered trivial and rejected at this stage. Accepted defects are prioritized and assigned for resolution.
Factors to be considered while evaluating and prioritizing the defects are:
This process is not just about attaching severity and priority to the defects. It also provides all relevant information required to track, replicate, and fix them.
The invalid defects and the basis of their rejection are also recorded for reference purposes.
Root cause analysis for every single defect is conducted. This analysis forms the basis for an improvement plan which ensures that chances of getting a similar defect are significantly reduced.
A report is generated based on the outcomes of the triaging process. A typical defect triage report will have the following information:
Every process tends to hit roadblocks if not planned and executed properly. The following challenges are commonly seen while conducting defect triage.
Webomates has a comprehensive defect triage mechanism. We ensure that the stakeholders get the correct and right amount of information to resolve issues with optimal usage of resources and time.
We have defect triage meetings on a weekly basis, monthly basis, and often with every Sprint. In order to help our customers in optimizing time for review defects, our reports include all triaged defect data. The sample report of the Webomates triaging process is shown below.
Defect Summary: It provides a short account of the defect discovered.
Replication Steps: This section contains detailed steps to help the developer to replicate the defect. It is important to have a detailed account here regarding all the involved parameters (input/output), configurations, etc in order to understand what conditions led to this defect.
In the replication steps, the tester provides console logs which further help the developer to quickly catch the issues.
Video: Our unique process presents a walkthrough video of an “actual instance of the bug” happening so that it is easier for the developer and other stakeholders to understand and relate and it removes the ifs and buts on how to reproduce a defect.
Priority Suggestion: Priorities are suggested and attached to the defect for easier categorization and defect management, however they can be changed based on stakeholders’ input.
Test Case Mapping: It is a good practice to map the defect with the test cases for analysis and tracking purposes. It is helpful when the defect has been fixed and the module is retested.
Comments: Additional comments, suggestions, and observations by the testing team are recorded here.
In addition to this, there are multiple categories in which defects can be classified during the review time, based on the analysis shared with stakeholders. These categories help in quickly identifying valid and invalid defects, hence focusing on valid Bugs to be prioritized and fixed. This ensures that there is no discrepancy or any confusion at a later stage.
| Category | Description |
| Valid New | A newly identified valid defect that needs to fix |
| Valid Known | A valid defect that has a previous ticket/story.Customers are aware of this defect. |
| Valid Won’t fix | Valid defect but need not be fixed since it does not impact business |
| Valid Improvement | Valid defect treated as improvement in functionality |
| Not Reproducible | A reported defect that was not reproduced during testing |
| More Information | More detailed information regarding the defect needs to be provided. |
| Invalid WAD | Not a defectThe feature is working as per the design and expectations |
| Feature Change | Defect occurred due to a feature change |
| Environment Issue | The defect occurs due to the configuration of the testing environment |
This process of defect categorization makes the task easier for the team responsible for fixing the defects.
Regular defect assessment is a basic requirement for maintaining the overall health of the project. It aids in managing and fixing defects throughout the testing cycle. If not executed in a timely fashion, the results could be one team chasing the other, ending up losing precious time. On a lighter note, check this video for what could happen.
At Webomates, we continuously work to evolve our platform and processes in order to provide guaranteed execution, which takes testing experience to an entirely different level, thus ensuring a higher degree of customer satisfaction.
Webomates offers regression testing as a service that is a combination of test cases based testing and exploratory testing. Test cases-based testing establishes a baseline and uses a multi-execution channel approach, to reach true pass / true fail, using AI Automation, automation, manual, and crowdsourced testing. Exploratory testing expands the scope of the test to take the quality to the next level. Service is guaranteed to do both and even covers updating test cases of modified features during execution in 24 hours.If you are interested in learning more about Webomates’ CQ service please click here and schedule a demo, or reach out to us at info@webomates.com
Read Next –
Requirements traceability matrix
Test Automation vs Manual Testing
Exploratory testing in software testing
Tracing the origin of defects during software testing
How Intelligent Automation optimizes your Testing?
Using AI to Create Model Based Testing
Tags: Defect Triage, Software Triaging
Test Smarter, Not Harder: Get Your Free Trial Today!
Start Free Trial
Leave a Reply