How to Reproduce a Non-Reproducible Defect and Make Your Testing Effort Worth It

In the world of software testing, a defect once found should be consistently reproducible so the tester can report with conviction, a developer can fix with clarity and the QA team can close with confidence.

However, this process sometimes comes with its own set of challenges. This article tries to illuminate those dark areas of defect reproduction.

First of all, what is “Reproducing a Defect”?

If a certain sequence of steps has landed the tester at a point where a deviation in expected behavior is observed- the “steps to reproduce” is the defect field that contains a record of this exact sequence of steps. If we encounter the same problem, every time we follow those steps, then this is called the reproducible defect.

In addition to steps to reproduce more evidence such as data used, screenshots or screen recorded videos can be provided too. In case this information is found inconsistent or incorrect, the bugs could get discounted and marked as invalid without a further resolution.

Read more => How to get your all bugs resolved without any ‘Invalid bug’ label?

Therefore, ‘steps to reproduce’ is critical and the following are some of the points to keep in mind when writing this part of the defect report:

How to write defect “Steps to Reproduce”:

• Be precise
• Include exact data used during testing for easy reference
• The steps have to be in the exact order
• Mention pre-requisites when applicable
• Do not write composite steps. For example: If the scenario requires a user to save a document from Microsoft Word, then it should be written as, ‘Open the File menu and click on save option’.
• Always recheck your steps to reproduce on a new system, clearing all cookies and cache memory.
• Make sure the sentences are short and unambiguous

An incorrectly written “Steps to reproduce” could not just jeopardize the validity of the defect but also involve a lot of time wasted in terms of seeking out clarifications and answers regarding things that aren’t clearly mentioned.

Also, read => How to write a good defect report

Why reproducing a Defect is so important?

Now, let us find out ‘Why reproducing a Defect is so important?’

Speaking technically, if you can’t reproduce a bug, you can never fix it.

The following are some of the factors that determine if a defect gets fixed:

• Detailed and complete info in the defect report
• If the developer is able to understand the actual occurrence of a defect under certain conditions?
• If the environment, tools, and exact application versions are available with the developers on which the defect is reported by the testers?

What are ‘Non-Reproducible’ bugs/defects?

Every tester must have experienced these situations:

• Observing an issue whole day and at the end of the day when you reported that defect, you find it’s no more reproducible.
• Observing an issue intermittently i.e., for example, suppose a new user is unable to add products to its cart. This happens 6 out of 10 times.
• Issue observed only when we restart the application.

In all these cases, it is hard to determine the exact condition and report it right. Such issues/defects take a lot of time in the investigation of. These types of issues can’t be ignored, as the end- user/customer may observe them too.

How to Reproduce a Defect?

A few things that might help are:

• Clear all cache and cookies while performing the scenario.
• Watch and observe every step.
• Sometimes looking for similar bug or patterns can be helpful in reproducing a bug. It will be easier to identify the scenario if the pattern is understood.
• Noting down each and every step and other factors (like test data, environment, system settings, screenshots, server logs etc) will be a good practice to easily replicate the scenario.
• Verify a few more times to determine the occurrence of defect. Do not trust and report further on the basis of one single time occurrence of the issue.
• Testing with patience is the key factor as this might and will take a lot of time

Additionally:

• Even when you are performing exploratory testing, make sure you are aware of all the configurations as well as system set-ups.
• It is good to use your creativity to explore the application in different ways and try some uncommon scenarios. Even in this case, it is advisable to follow logical sequences rather than performing random steps.
• Once an issue is observed, it is always a good practice to verify the same issue on different browsers/operating systems combinations, different devices (supported). This helps in determining whether the issue is a system or browser specific/ device specific.
• Keep yourself updated with new trends and forums about different types of issues and their occurrences. These help in a differentiating system specific, browser specific, product specific, external issues, etc.
• Instead of keep on trying to reproduce the issue once occurred, sometimes sitting back and analyzing the steps performed can help find the solution.
• Discussing with other team members or manager can sometimes be helpful. Also, there is a saying, Experience counts.
• Sharing your screen can be also considered as an option apart from screenshots and videos to explain the issue to the developers.
• Reproduce the issues more than once to be sure of the occurrence of an issue. In such cases, you will be confident in your testing and will be able to reply the queries and concerns of developers.

Conclusion:

With the overall discussion, it can be clearly concluded that it is very important to ‘reproduce a bug’ in order to get that bug validated and then fixed. If the bug is not reproducible, then the testing effort used in finding, analyzing and reporting that particular bug/defect is a total waste.

For understanding and reproducing a bug, it is essential to have detailed and properly explained ‘Steps to Reproduce’, state and environment in which the bug occurred. It is possible to fix a not reproducible defect, but it can be very time to consume as well as a very difficult task. Another most important factor is proper communication without which, a valid bug can be invalidated.

So, to make your testing effort in finding defects worth it, the above mentioned can be helpful.