The most important yet confused concept in Defect Management – Defect Severity and Priority. Additionally it is one of the most popular interview question after explaining Defect lifecycle – What’s the difference between Defect Severity and Priority? I don’t know what’s so difficult in understanding the concept? I guess it is not the concept but the application of it that confuses more…let’s explore what actually is Defect Severity and Priority. But before moving to it, let’s first clarify the two different perspectives of the application-under-test.
Understand the Technical and Business perspective
As you move up the ladder of Software testing profession there are always two crossroads to opt from – stay in the technical domain (yeah, everybody starts from here) OR move into Project Management. What do you think is the major difference between the two? Yeah! Technical professionals are more concerned about the application (the technology stack, application design, development, testing and optimization) whereas Managers are more concerned about the Business (the client expectations, business usage, successful delivery, end-users, etc.). Rewards option not working in a payment gateway is a serious glitch from technology perspective, but not so much from a business usage perspective since it doesn’t stop the transaction and will be used by only a fraction of the end-users. Hope you got the two perspectives around a particular functionality – the technical and the business-oriented.
The Defect Severity (Technical)
As you would have understood – Defect Severity defines its impact to the application, from technical perspective. Generally Defect Severity can range from Cosmetic to Critical,
- Cosmetic: The appearance, i.e. if the defect is related to just the look-and-feel of the application
- Minor: Defect doesn’t result in termination or damage to the functionality, work-around is available
- Major: Defect results in the termination of one or more system components but an acceptable alternative functional flow exists
- Critical: Shut-down! Defect results in the termination of one or more system components and NO other acceptable alternative functional flow exists
The Defect Priority (Business)
In simple words, what is the precedence, importance or urgency to fix a defect? Say you click on the ‘Help’ link and the application crashes. Whoaa! Bing-Bang Craaaashh..! Quite a severe defect, right? But how many of us really click the ‘Help’ link? Business usage statistics show less than 2%. Now what do you think should be the urgency to fix a defect that impacts just the 2% of the end-users? Yeah! Not ‘High’ obviously. There would be other urgent defects to fix prior to this!
Defect Priority defines the order in which defects should be fixed, i.e. its impact to the end-users, the business perspective. Generally Defect Priority can range from Low to High,
- Low: The defect is an irritant which should be repaired, but repair can be deferred until after more serious defects have been fixed.
- Medium: The defect should be resolved in the normal course of development activities. It can wait until a new build or version is created.
- High: The defect must be resolved as soon as possible because the defect is affecting the end-user behavior severely.
- Urgent: Show-stopper! The defect must be resolved immediately, cannot proceed further without resolution.
Defect Severity and Priority | Mix and Match
Interviewers are quite clever people. They don’t want theoretical answers, instead they want practical scenarios. Also you might have heard “Experience is a bigger teacher than Education”. Practical examples give you much more insight & understanding of a theoretical concept. Let’s look at some of the practical testing experiences with respect to different Defect Severity and Priority,
- High Priority + Critical Severity: A show-stopper! User is unable to login to the system (E.g. Net Banking)
- High Priority + Low Severity: Company Name (the Brand) is misspelled at the website homepage
- Low Priority + High Severity: The ‘Help’ link example above J OR end-users using outdated browsers (< 2%) cannot make a purchase
- Low Priority + Low Severity: Any small cosmetic issue in the appearance
- Don’t confuse Defect Severity and Priority, i.e. don’t use them interchangeably OR by default keep the value same for both
- Priority defines the Business impact (urgency to fix) | Severity defines the impact to a functionality
- Priority requires business input | Severity can be defined by the QA team
- Priority might change depending upon the project parameters | Severity is less likely to change
As you might have understood – Defect Severity and Priority is one of the most important concept for proper defect management – it covers both Technical as well as the Business perspective of the application-under-test. Don’t just match the values 😛 High for High, Low for a Low. Assigning the correct Defect Severity and Priority is one of the task that you master over the years of experience. But why wait – understand its importance, be a responsible tester, stay aware and get started.