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.

reproduce a 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?’

reproducing a Defect

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


  • 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.


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.

Recommended Reading

18 thoughts on “How to Reproduce a Non-Reproducible Defect and Make Your Testing Effort Worth It”

    • @ Dev patel and Rabi Mani Upadhaya
      Please find sample defect report as well as some more reading on the topic here:

  1. I have experienced these kinda situations while testing. When we came cross the “add to cart” kind of scenarios, we used to raise that bug as a “Random” bug and we submit “Error log” report for the Dev reference.

    By the way, nice post. Keep rocking!!!!

  2. It happens all the time. I had one issue that was completely consistent. Reproducible every time. I put a sniffer on the wireless data and the problem went away. Never got the issue back.
    Another thing to consider while testing do you clean up the device every time? From a testing standpoint it’s nice to have a clean baseline but users will never have it. When you don’t clean up the data unrepeatable issues can occur. Testing from the viewpoint of the final user means lots of slop in the device. Don’t test clean test dirty!

    • @ roger richardson
      agree, all our tests should be on clean as well as on production like environment. the tip shared in this article for starting with fresh/clean setup is to try reproducing a non-reproducible defect. it’s one of the steps when you have tried all the steps on your existing setup to reproduce a defect.

    • Hello, I have a question about clean up the device; I’m testing the desktop app and I’m a bit new at this, so how are the clean-up desktop apps?
      Thanks in advance

  3. Thanks Vijay for such article !
    I was struggling with Runtime issue and i was not able to reproduce it .
    Noted down every steps and i found it out.

    Thanks again!

  4. How to attach Logs if it is Frond side Error Or if it is database side Defect .For particular tool bug tracking tool like You tracker or if as manual tester if we maintain test cases in excel there any way to find particular line number that have fetch that line number ,module name etc. or if its database side defect then how to find particular defect


Leave a Comment