Live Production Defects: Don’t let QA take the Blame

The aim of all organizations releasing apps or hardware to market is to deliver the products free from live production defects. When bugs are still present in the marketplace, there can be bigger problems. It can lead to product recalls, refunds, and depending on the severity, the need to restore a once trusted reputation, let alone having to factor in the unexpected expense to rectify the situation.

Testing throughout the Software Development Life Cycle needs to adhere closely to (presumably thorough and accurate) user requirements, so the test team can minimize the possibility of any bug being missed. As we all know from experience as end users ourselves, discovering a live production defect can be too common. As they say ‘to err is human…’ and somewhere along the SDLC line, mistakes can happen which can result in problems at the production level which can hamper the performance of the application. There can be factors such as time pressure, tight deadlines, or complex functionalities, which cause bugs to be missed in the testing environment.

In organizations, when a live production defect is found, management sometimes assumes the tester was unable to carry out the task properly and the blame game begins. Management summons the team members involved in executing testing activities on the particular project and their only question is to ask how the bug escaped, even with all the tools and expertise available.

Whose Fault is it anyway?

How well defects are discovered can depend on the quality of the requirements, the complexity of the application, and the thoroughness of the testing process, but a tester is still unlikely to be able to identify and catch all of them. However, by using certain strategies and risk-based approaches, a tester can identify the majority of important bugs so they can be fixed. But, regardless of the efforts made, still there is a risk that bugs will arise in the production phase which can affect the application performance and user experience. Given the wide range of possible factors, it is most important that blame should not be placed entirely put on the testers. Each team member must take responsibility because pinning the blame on an individual (tester) is neither fair nor most probably, accurate. The best approach is for organizations to put their emphasis on exploring the root causes of the problem and to take appropriate measures that will help them avoid such circumstances in the future. Such situations should be taken as a lesson and should not be treated as an opportunity to start blaming the team members.

What to do?

It is a wise move for organizations to work towards shifting the culture of blame towards one instead of shared ownership. There should be collaboration between all stakeholders when testing activities are being executed so that a common goal is achieved with transparency. Only by working together and sharing knowledge will the problem be resolved. Failing to do so can result in a lingering and unpleasant atmosphere of mistrust and resentment in the work environment.

Conclusion – No individual is to blame

The first step towards avoiding problems in production is to eliminate the culture of blame. Those who convey blame to an individual such as a tester must be advised to alter their perspective towards a more productive outlook. QA functions as the front line for bearing any mistakes made by developers which can affect customers. Developers can be too focused on implementing major functionalities that they sometimes forget to test all scenarios which can sneak past the testers into the production environment. Rather than appointing blame, all efforts must focus on analyzing the cause of the problem so a shared solution can be proposed to avoid future mistakes. QA individuals and teams must collaborate to establish a partnership with all stakeholders, especially developers, and develop their testing strategy accordingly, for the smooth identification of defects or bugs to avoid uncomfortable situations from thereon.