tester when a defect is logged; however they should be reviewed and adjusted as needed. More on that later.
Many Defect Tracking Systems use only Severity. Impact is probably a better term. Many systems use Priority when they really mean Severity. Really good ones use both and allow you to customize them. Priority is a really completely different concept than Severity. An effective triage system really needs both.
From a software triage perspective, Priority is used to rank the order in which defects are to be resolved. A defect may be Critical in terms of Severity, but the amount of time it would take to resolve it and the resources it would consume make it impractical to resolve now. Some critical defects may be assigned a very low priority, while other, less critical ones, may be assigned a higher priority and move to the front of the line. For example, a typo may not be critical, but makes you look bad. It's also an easy fix, so it may get assigned a higher Priority assignment and moves up.
Priority levels, like severity levels, need to be defined and documented. I like to use 3 priority levels (1-High, 2-Medium and 3-Low) because it tends to be simple and understandable to most of the team. 1-High is the highest priority and represents the front of the line while 3-Low represents those defects we can "live with for now" or the back of the line. These are the issues that typically end up in release notes and are deferred to future releases.
Priority determines the order in which defects are resolved. In most cases, Priority is assigned based on two primary factors: likelihood of occurrence, and impact on resources (time needed to resolve the defect and availability of resources such as developers, testers, etc.). A test may cause the system to crash, but takes an obscure set of keystrokes or user actions to make it crash. If it requires a detailed fix or major redesign, you may want to hold off on fixing it right now. Critical? Yes! High Priority? Maybe. Maybe not.
Priority levels are also helpful in determining "Readiness for Release" or defining the "Quality Bar" (but that’s another paper).
The Triage Team reviews, evaluates, prioritizes, and in some cases assigns all defects. Membership on the Triage Team may vary depending on organizational needs. As a minimum, I recommended the following required members:
Project Manager. The project manager serves as the process owner. Project managers are typically in the best position to evaluate impacts to the schedule and resources. As such, they are also in the best position to mediate disputes and make quick decisions if needed. They typically have "veto" authority.
Product Management/Business Analysis Team Lead. Product managers, or business analysts, represent the customer. They are typically the best resource to evaluate a defect from a customer perspective.
Development Team Lead. The development team lead is usually in the best position to evaluate a defect from a technical perspective, and can best assess how long it will take to resolve a defect and the impact on development resources for both current development efforts and resolution of defects.
Test Team Lead. The role of the test team lead is to evaluate the system and defects from a Quality perspective. As a Test or Quality Assurance Team Lead, I usually like to lead the Triage meeting since I am typically the owner of "software quality" and "Defect Manger."
In addition to their role as meeting leader, test leads are in the best position to evaluate the testing impact of a
|Software Triage||49.5 KB|