Defect Triage

So recently, one of the members of our defect triage team has left and an additional helping hand has been required to determine if a reported issue is an actual issue. Here’s where I come in, assisting in confirmation of bugs.

The following piece of writing will answer the following:

  • What is ‘Defect Triage’?
  • Why do we need a ‘Defect Triage’?
  • What’s a simple process we can use?
  • What happens in a ‘Defect Triage’ meeting?
  • What is the outcome of the ‘Defect Triage'?

What is ‘Defect Triage’?

Think of a hospital and how fast a patient gets seen. One patient comes in with a headache and another comes in with a stab wound, who would get seen first? The person with the stab wound as their life is in danger, once this issue has been resolved then the doctor gets to see the patient with the headache. 

Similar to how hospitals do it, defect triage is a process where issues are screened and prioritised to ensure the following:

  • The issue is an actual issue
  • Resources are used most effectively
  • Maintain a more ‘healthy’ system

Why do we need a ‘Defect Triage’?

Going back to the hospital example above, the point is to evaluate and prioritise work based on the limited amount of resources that we have. Take for example the following scenario: An issue has been reported by a member of the wider business team and it’s a confirmed bug. However, it’s a bug where only admins of the platform have access to and there is a workaround. How severe is this bug? Not very, it might be fixed when we have time but the development team will most likely get given work that is of higher significance than this.

A simple process

  • New - A bug has been added to your bug tracking system, we use JIRA for this
  • Under Investigation  - The product team/tester determine using the following guidelines to confirm a bug report
    • Is it following the correct format?
      • Situation (What's happening?)
      • Steps to Replicate
      • Problem (What's the impact of this problem?)
      • Expectation (What do I expect to happen?)
    • Has it been reported before?
    • Who found it?
      • If a client finds it we normally expedite
    • How critical is the issue?
      • Critical - Main functionality of the system has stopped working
      • In Between - To be discussed in triage meeting
      • Low - Only visible to internal users and there is a workaround
  • Rejected - Triage team is unable to replicate the issue / Bug report duplicated / Bug reporting format is not used
  • Confirmed - Bug is confirmed and awaiting resolution
  • Dev in Progress  - Bug is in sprint
  • Released  - Bug has been resolved / fixed

The Defect Triage Meeting

Who are involved and what are their roles?

  • Product Manager
    • Final decision on defect prioritisation
  • Wider business team representative
    • Discuss the effect of the bug on the business team and clients
  • Technical Lead 
    • Gives top line thought on how long the fix would take and its impact
    • Allocation of bug to appropriate developer
    • Get all relevant information for developers to work on
  • The Tester
    • Give top line estimate on how long testing will take when bug completes development
    • Gains insight on upcoming work to aid test plan creation

What happens now?

  1. Participants look into the bug board and do a top level analysis on each defect from highest severity to lowest
  2. Adjust priorities and severity based on business needs, technical complexity, and resources
  3. Bugs are added to upcoming sprint or after

My role...

With my knowledge of the system I aid the product team in confirming whether the bugs follow the standards that we have set out above and validate them (move them to confirmed)

Here's a few pointers I always make sure I do when analysing a bug report

  • Sitting down with the bug reporter - We schedule a few minutes conversation to demo the issue and sometimes I've found that a gap exists in the knowledge of how the system works or it's a feature request, if that's the case I refer them to our feature request process
  • When the bug is confirmed, I make a note of this to ad to my test scenarios to consider when writing test cases
  • Do it at 5pm -  Everyone is winding down, always making sure that I've done all the important stuff first (unless a critical issue has been reported and then I get on it straightaway) 

What I'm reading now - 12 Rules for Life: An Antidote to Chaos


Happy Testing!

2 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *