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, [highlight dark=”no”]you should be sure that the bug has been eliminated.[/highlight] 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, [highlight dark=”no”]try to reproduce it at once.[/highlight] 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, [highlight dark=”no”]try to get all possible information on this issue: [/highlight]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 [highlight dark=”no”]to know what it was[/highlight] and [highlight dark=”no”]understand how this could happen.[/highlight] Only after this, you will understand how to test the fixed bug and what tests should be executed.

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, [highlight dark=”no”]define a number of users that has been impacted and the magnitude of the problem.[/highlight]

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 [highlight dark=”no”]for several times. [/highlight]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: [highlight dark=”no”]you should analyze the situation[/highlight] and [highlight dark=”no”]try to define the ways the issue has appeared in a production environment.[/highlight]

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, [highlight dark=”no”]you should develop strategies to prevent this in the future.[/highlight] 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.