Bugs in Production Environment

Below, we will go over some common questions you might be experiencing, and help give you solutions to a bug-free product!

What to do when finding bugs

1. QA’s are the gatekeepers for a product. But that doesn’t mean that they are entirely responsible for each and every bug that leaks out. After all, quality comes from team effort and the whole team is responsible for making a good product. 
2. Perform Root Cause Analysis (RCA) – Gather more information about the bug. Understand the steps leading to the bug & try to reproduce it on your end. Find out what really caused this issue. Check if this was tested through the existing list of test cases and scenarios or was it missed. It can also happen due to missing requirements.
3. Check the repercussion­s and assess the need for a fix – Ascertain the impact of the bug. Find out if the bug really needs fixing or can be lived with. This decision can be backed up by checking analytics as well. Understand the use cases around the bug to check if it has any other issue that hasn’t been reported yet, but could come back in the future.
4. Learn from it – Evolve from the mistake. Create new test cases based on what you have learned from the issue and ensure that you add those test cases in your existing test suite to make it more robust for the future. Document all these steps for future reference.

How to avoid bugs in production?

1. Maximize test coverage – Before a product is released, it needs to be thoroughly tested. In order to achieve this, you need to maximize the test coverage. The scope of coverage can vary based on products.

In general, it will entail test coverage across different browsers (and their versions), operating systems and their flavours, different OEMs, devices with various screen sizes, memory, storage, battery capacity, testing on various network providers, etc.

It must be noted that it is impossible to get 100% test coverage at first, but you can get excellent coverage over time. It is a continuous process and you need to ensure that you build on the existing test cases/scenarios as your product evolves. There is no hiding from the fact that it will take time and effort to achieve this, but it will be worth it!

1. Get a second opinion –  As mentioned earlier, QAs are responsible for maintaining the quality of the product. That being said, it is always good if everyone in the team contributes to improving quality. Having more eyes on the product will help QAs in scoping out new use cases and give them a fresh perspective on testing the product.
2. – Apart from ensuring the execution of regression test suites, you can leverage alpha and beta channels to get some real-world feedback. This way you have all bases covered before it rolls out to the masses.

You can make use of additional safety nets like staged rollout and feature flags which give you the ability to turn ON/OFF a feature at a moment’s notice, to help in mitigating any critical issues.

1. Get involved in the early stages of the development cycle – In an agile environment, when sprint planning and refinement are discussed, all team members can be involved so that any loopholes and hurdles for future development can be caught and discussed.

Guidelines for code reviews, unit testing, and dev testing should be followed strictly before it passes on to the QA team.

1. Break the chain – Gone are the days when a QA would be limited only to monotonous test case execution. Now, it is vital to start thinking more about exploratory and negative testing as well. Keep in mind that an approach used for testing today might not yield the same result tomorrow.
2. Effective communicatio­n – We can draw parallels with Pareto’s principle when we say “it is well known that the majority of the issues are usually caught in newly added modules rather than existing ones”.

We need to invest more time in the right set of modules by assessing the change. Who better than the developer to help us with this! So, communicatio­n with them is the key to scoping out the impact of the changes.

Summary

As a QA you can try to reduce the number of such incidents, but let’s face it, this could happen at any time. It’s better to avoid it, and if faced with this challenge – be prepared for it. Every company has faced such an issue in their past but they become better by learning from it.