“A nickel for your thoughts.” How many times have you heard of this phrase?
Admittedly, I have heard less of that one over the years, but it is uttered every now and then. Usually, when something goes wrong, there could be more than one thing that could have gone wrong. In a QA testing capacity, one of the jobs we do is to find defects, abnormalities and unexpected results, whether you are in the trench, over the trench or viewing from the watch tower. It is a phrase we hate to answer and hear of. There are countless articles and statistical analysis on the inability to test everything but none the less we have all felt the pain of a bug in production. So how do we deal with the reality?
When performing triage on a situation (the bug(s) in production), at that moment, we look to stop the bleeding and immediately put in a ‘work around,’ but ultimately we need to dissect the history of events and perform a root cause analysis. As we backtrack through the processes and the associated handoff points, it has been my experience, that failure was due to a number of missteps by an individual and not from a group as a whole.
In recent years, I have seen examples of agile delivery limiting the phrase as the delivery team is co-accountable to quality and defects. There are many quality and project management processes (directing and operating SOPs) I can cite for a root cause analysis path, but for this blog, I will keep the focus on the testing process.
The lack of prioritization by the product/end user and/or weak understanding (by the tester) to under-stand the underlying business process is a major contributor to hearing that phrase. If your test cases and the requirements they support are not associated to a business priority, then your QA/test team may not run the most important tests first. Especially during crunch time, understanding the business priority will go a long way. Prioritization will also be one of the cornerstones in your regression and automation (functional and performance) strategy, so, obviously this one is critical. Risked based testing and prioritization go hand in hand. When you start to develop your white and black box, end-to-end tests and scenarios with the knowledge of business risk and priority ensure your chances of success (not hearing that phrase) increase dramatically. If a major defect was missed (change and code version control aside), one has to examine the regression approach. I have seen issues unexpectedly appear due to improper maintenance of regression. Regression suite maintenance (automated or manual) must be inherent to the fabric of your testing process. The ongoing costs of quality are just as important as the ones we invest to initially get there.
Testers, get out of your seats, walk over to your business partners and talk about the tests and the business requirements. Set up a WebEx/online meeting if you are geographically diverse and understand what is important. Understanding this could hopefully help you hear less of that phrase.