Finding a bug in a production environment may turn into a real problem for a tester who was responsible for testing it.
This article is dedicated to describing the actions that will help a tester to eliminate bugs in a production environment and gives some tips on the ways to prevent their appearance in the future.
Action 1. Keep calm and don’t panic
It’s clear that a person who tested a product and then passed it to release will worry if a defect is found in the online production environment. A tester immediately thinks, how this could happen.
He/she starts analyzing his/her work, to find the answer to this question. And this decision is definitely inefficient.
First, you should be sure that the bug has been eliminated. If panic takes over you, you won’t be able to do this and will, instead, not complete testing and studying this issue.
Action 2. Reproduce the defect
If a client or another team member has informed you of the bug presence in production, try to reproduce it at once. It may be a user’s error or a configuration issue.
Check if you have taken all steps, previously taken by a user and check that you are using the same software and hardware that a client or user uses.
For example, you can open the product on a smartphone of the same type and use the same build. If an issue is not reproduced, send a request for receiving additional information and keep trying.
Action 3. Try to receive as much information as possible
After bug reproduction, try to get all possible information on this issue: whether it happened in a previous build, whether it’s reproduced on a test board, if it appears in a certain browser (operating system), if you need certain configurations for its reproduction and so on. The more information you get, the faster the bug will be fixed by developers.
Action 4. Find the cause
A developer is currently working on finding the cause of this issue.
Your task, as a tester, after finding the cause will be to know what it was and understand how this could happen. Only after this, you will understand how to test the fixed bug and what tests should be executed.
What You Should Do in This Case
Action 5. Indicate the time when the bug should be fixed
When a defect is found in production, you wish to fix it ASAP but this isn’t always correct. It frequently happens that fixing one bug leads to the appearance of the new ones. So you should primarily check all areas that may be affected by the bug.
Before proceeding to fixing it, define a number of users that has been impacted and the magnitude of the problem.
The bug may impact only 1 % of users but if it’s critical and they have difficulties in using a product, it should be fixed immediately.
Or another case: the issue affects all users but it’s has a low severity, so that it won’t affect application using.
Action 6. Check if the bug has been fixed
You should test the fixed bug for several times. Check it on all available devices and browsers, then execute regression testing of the areas that may affect the code.
If you have faithfully taken action 4, you should know what fields should be tested. And finally, it’s recommended to perform smoke testing, to be sure that the application’s functionality is not broken.
Action 7. You should analyze why the issue has happened
When the bug is fixed in production, a tester may breathe a sigh of relief. But there is one crucial thing: you should analyze the situation and try to define the ways the issue has appeared in a production environment.
The main task is not to find who is responsible for this but simply understand how this has happened, to prevent such cases in future.
Developers could make changes to code and didn’t inform you of this so that the fixes didn’t been checked.
You could also check not all browsers while testing a certain function so that a bug appeared in one of the browsers. This doesn’t matter now, the main thing is to be sure that you chose the right words to inform your team on the issue.
Action 8. Brainstorming as the way to prevent such issues
When you found the cause of bug appearing in a production environment, you should develop strategies to prevent this in the future. We recommend you do this with your team.
Maybe, you should change the process itself: for example, a product owner should convince you that he/she hasn’t missed anything. Or you should know about any change that developers have made to code, even if they convince you that nothing has been changed.
Maybe, you need to change the strategy of your work: if one feature is tested by two testers, then it will be less likely to make a mistake.
Or maybe, you should change either a process or a strategy.
Leave A Comment