Think Like A Tester: How To Reproduce Bugs

Have you ever experienced something wrong in an application, yet you have not been able to reproduce it? Has a user reported a bug with a scenario that your team couldn’t recreate? It is certainly possible to lose track of these bugs, but chances are that if one user experiences an issue, other users will experience it as well. It is really important to have the ability to reproduce a bug. Teams that manage to identify steps to accurately reproduce a bug, can save several hours of research. Identifying the steps that lead to bugs allows in detecting the source of the bugs too. Issue tracking tools are helpful in detecting, recording, and rectifying issues appearing in a software application. In this post, we shall discuss some helpful tips for reproducing bugs and getting to their root cause.

Why is it Important to Document the Steps to Reproduce an Issue?

When reporting bugs, it is important to document the steps to reproduce for the following reasons:

To Prioritize:

Anyone who requires examining issues by themselves can easily follow the steps and understand clearly what is being reported. Product owners prioritize and assign a severity level to bugs and stories. Without clearly understanding an issue, chances are that it may not be prioritized and released into production, whereas it should have been fixed. However, if the issue is prioritized, there won’t be any misunderstanding and developers could focus on areas that are more important. 

Resource Allocation 

It is crucial that the bug assigned to the right team should be dealt with. Since a screenshot does not contain enough information to allow the issue to be assigned to the correct team, it is important to write down the steps. This helps in allocating the right resources to the issues.

Recreating Issues 

The first and foremost thing a developer should do when resolving a bug is to reproduce it in the development environment. If the steps to recreate are not devised in the beginning, it can cause the developer to assume that the issue has already been fixed, thus he might assign it to the QA experts for testing. Such delays can hamper the software development process and affect the release timelines. 

Test it Again 

It is crucial for developers to perform due diligence before submitting a bug report. They should test the bug in other environments with a range of devices and browsers. The bug reports should also have additional information. When a developer attempts to reproduce a bug on a different operating system in a different environment, it is most likely that he won’t be able to reproduce it.  It is easier to save time and money by documenting all these details. 

How to Reproduce a Bug

The considerations to reproduce are the only way to follow how a user experienced a similar bug earlier. Let’s have a look at the ways:

Identifying the Conditions of the Bug:

Type of User – Answer questions like who is experiencing the bug? It is an admin, moderator, or end-user? Is the user in a specific status? Is the user related to action with a specific status? Can the location of the use affect how the product is supposed to work?

Authentication – Make sure that a user is logged in. There can be a bug that appears when the user is not authenticated or it only appears when the user is authenticated.

Environment – Where is the bug located? Is it appearing on a website or mobile app? Has it occurred in a development or production environment? 

Data – What kind of data does the user have? Is it possible to reproduce with the same data? Typically, the bug may appear if a user has a very long last name or an image file.

Configuration – If an application is not set up properly, a bug can appear. For instance, a user does not get an email notification, may not be getting it because email functionality for their account may be turned off. It is crucial to check the configurable settings in an application and try to reproduce the issue with the same configurations. 

Back Button – There can be a lot of mysterious bugs appearing in the Back button. If a user navigates to a page using the Back button, the state of the data on the page may be different from what it would be by using the standard forward navigation. 

Caching – Caching can also result in unexpected behavior of the application. For instance, it may appear as if data is the same, while it has been changed. If a cache expires or takes too long to expire, the condition of the state can vary from what is displayed. 

Page – Where exactly is the issue? Has it occurred on the home page? Or on the side menu, cart, or profile page? 

Medium – On which device has the bug appeared? A mobile, computer, or tablet?

Action – What was the tester performing when he found the issue?

Other factors – Any significant event that could have caused the bug to appear should also be mentioned.

List Down the Mandatory Information: 

When describing the steps to reproduce bugs, some information is mandatory, such as: 

• URL – The URL where the bug is located.
• The User Data – Login/password (in case of a fake user set) or only the login (in case of a real user) or visitor access that is granted some rights. 

A few more tips include:

• Splitting the actions – A tester can write one step per line which means one action per line. 

• Consolidate actions into one – Testers should save their time and consolidate the essential steps under one heading. 
• Order them logically – They should arrange each stage step by step. 

The above tips can help testers in reproducing bugs so that there are no delays in the software development process.