Defect Triaging is a formal meeting where
all the defects of the current Sprint are discussed and triaged i.e. Prioritized
based on its severity, frequency, risk, etc.
The defect triage meeting discuss about if
defect is valid or user error. If the defect is considered as valid defect then
the next question will be is this defect reproducible? If it is
inconsistent then that will be assigned for thorough analysis. If bug is
reproducible then comes next question is this defect worth of a
fix? i.e., how much it impacts the business of the client. If the impact
is low then it will be deferred to next releases or bug can be closed. If the
impact is high then that will planned for the immediate releases and assigns to
the developer to provide fix with defect status as “Assigned”
If your company is using Trello for project management
Try creating Change Request Flow(plan, protocol). Agree with the client on the steps which are going to happen each time they request a new change. E.g. if they request a new feature, the feature will be included into the next iteration/sprint.
Try to systematise their requests. If they want to add a new button to the existing page, create it as a separate card, not as a comment. If they ask for numerous copy updates, put down these requests to a separate “Copy updates” card.
Non-reproducible bugs – defect has not reproduced on developer pc, i.e a defect coming on your pc does not happen in developer pc’s
Test environment – mismatch of browsers, devices, or configuration of your application with developer.
Duplicate bug – Someone else has already reported the same bug
Misunderstanding the requirements – For any reason, if you did not understand the requirement properly, you would definitely look out for the misinterpreted requirement in actual implementation and when you would not find it, it would be a bug according to you, which will finally get rejected
Change in requirement – When testers are not communicated about requirement changes, more bugs will be reported and ultimately rejected.
Test data used – Test data used for testing was mismatching with a requirement
Improper bug description – If developer does not find proper description and required details in bug report, no matter how critical the bug is, it is expected to be marked as Rejected.
Suppose you have an application which is having a UI bug that doesn’t really affect the apps usability. In this case the severity is very low, but it is of high priority because it’s looks ugly. As priority indicates business value, this defect should get fixed at high urgency.
Inconsistency defect is nothing but the
defect which is not stable, a bug which is not reproducible while retesting
i.e. the defect is valid but it’s not reproducible always. For example, observing
an issue whole day and at the end of the day when you reported that defect, you
find it’s no more reproducible.
Here are the steps to reproduce defect
Include exact data used during testing for easy reference
The steps have to be in the exact order
Mention pre-requisites when applicable
Always recheck your steps to reproduce on a new system, clearing all cookies and cache memory
indicates how soon the bug should be fixed. Severity indicates the seriousness of the defect on the product
functionality. More severe the defect is, higher the priority is given to
ensure the defects are fixed as soon as possible to maintain the quality of the
A bug that would damage data is more severe than something that is just
annoying like say some functionality taking too long to load. Both should be
fixed but those with higher negative impact should be fixed first.