All implementations and releases will Go-Live with defects! That sounds ominous, doesn’t it? For decades software product firms have graded defects / bugs / issues in their applications by severity levels defined by levels of impact to the software product. Just Google defect severity and one finds a multitude of explanations, definitions and meanings. One thing everyone agrees on is that this is a point of conflict between business, QA / testing and software development. Here is what we found on one of those Googling expeditions on defect severity. Having done this in our past avatar for years we don’t deny that this situation is real….and sometimes has even lead to fist fights!
“Defect Severity is one of the most common causes of feuds between Testers and Developers. A typical situation is where a Tester classifies the Severity of Defect as Critical or Major but the Developer refuses to accept that: He/she believes that the defect is of Minor or Trivial severity. Though we have provided you some guidelines in this article on how to interpret each level of severity, this is still a very subjective matter and chances are high that one will not agree with the definition of the other. You can however lessen the chances of differing opinions in your project by discussing (and documenting, if necessary) what each level of severity means and by agreeing to at least some standards (substantiating with examples, if necessary.)
ADVICE: Go easy on this touchy defect dimension and good luck!”
Source: http://softwaretestingfundamentals.com
The biggest issue with defect severity is that it is usually seen as assigning blame for something not working. Here is what traditional defect severity levels look like:
- Critical/Showstopper - An issue in any software that affects critical functionality or feature. This is a state of complete failure of that functionality or feature and can at times include data issues too. These issues typically do not have workarounds and need to be addressed immediately
- Major/High - These are issues that are lesser in severity than Severity Level 1 but still affect important functionality. These issues might have complicated workarounds but more often than not need to be addressed before Go-Live
- Minor/Medium - These are issues that are lesser in severity than the Severity Level 1 and 2 and may or may not impact important functionality. These issues might have simple workarounds and more often than not do not need to be addressed before Go-Live
- Trivial/Low - These are issues that are lowest in severity and do not impact important functionality. These issues have simple workarounds and definitely do not need to be addressed before Go-Live
Don’t get us wrong, these severity levels are important from a software development perspective. In fact it would be hard to find anyone who disagrees on severity 1 and severity 4 issues. It is severity 2 and 3 defects that cause the most heartburn. Add the pressure of an aggressive project timeline and the thin line between prioritization and defect severity categorization blurs.
At Go-Live Faster, we extensively work with banks helping them accelerate product launches and releases by making their technology implementations predictable. A typical bank implementation consists of multiple code drops over a 6-12 month period with customization and integrations being delivered in trenches. QA / testing takes place in an incremental manner and defect fixes are delivered in cycles. Some other common characteristics of these implementations are that they are always behind schedule and over-budget.
Given this situation, these implementations are prime for a constant change in priority, conflict when assigning severity to defects and a last minute scramble to determine "what defects we can live with" and "what defects have to be fixed". We found the traditional severity levels to fall short for this unique situation faced at banks. While creating Go-Live Faster’s suite of Readiness solutions, our teams came up with a simple yet effective way to prioritize Go-Live impacting issues up-front thus leading to better prioritization and consensus across teams. At Go-Live Faster we call it the Go-Live criteria. The Go-Live criteria is broken into four main areas that impact any implementation; i.e.,
- High Go-Live Impact - Revenue and regulation impacting
- Medium Go-Live Impact - Indirect revenue impacting and reputation impacting
- Low Go-Live Impact - Impacts Go-Live but has workarounds or can be fixed once you Go-Live
- No Go-Live Impact - Trivial/ low impact defects that need not be fixed even after you Go-Live
Further, to make it more quantitative, Go-Live Faster provides a Go-Live Score that indicates the overall readiness to Go-Live with an implementation. This table above helps achieve a consensus between LOB, IT and vendor teams. Typically driven by LOB teams, they define what it means to them to have each one of these issues in the system. Once frozen (typically at the start of the project), the IT and vendor teams tag defects based on the Go-Live criteria. This is done in addition to the traditional severity tagging and acts as a substitute for non-scientific prioritization like High, Medium and Low.
One additional improvement that one can make to the above table is to add user experience impact to the high and medium categories instead of just reputation. However this requires extremely high levels of maturity in a project team as user experience impact is very subjective and means different things to different people.
Get in touch with us today to understand how to come up with a Go-Live criteria for your next implementation.
