Steps to Reproduce a Not-Reproducible Defect in Testing

By Vijay

By Vijay

I'm Vijay, and I've been working on this blog for the past 20+ years! I’ve been in the IT industry for more than 20 years now. I completed my graduation in B.E. Computer Science from a reputed Pune university and then started my career in…

Learn about our editorial policies.
Updated May 9, 2025

In this article, we discuss in detail how to reproduce a non-reproducible defect and make the testing 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 highlight the dark areas of defect reproduction.

First of all, let us understand 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, it is called the reproducible defect.

How to Reproduce a Non-Reproducible Defect

reproduce a defect

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

Read more => How to get all your bugs resolved without an “Invalid bug” label?

Therefore, the “steps to reproduce” is quite critical. 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’.
  • It is important to recheck the steps to reproduce on the 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 understand why reproducing a defect is crucial.

reproducing a Defect

Technically speaking, if you can’t reproduce a bug, you can never fix it.

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

  • Detailed and complete info in the defect report
  • If the developer 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 for the whole day and in the end when you reported the defect, you find it’s no longer reproducible.
  • Observing an issue intermittently i.e., for example, assuming a new user is unable to add products to their 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 to investigate. These types of issues can’t be ignored, as the end-user/customer may observe them too.

bug

How to Reproduce a Defect

A few things that might help are the following:

  • Clear all cache and cookies while performing the scenario.
  • Watch and observe every step.
  • Sometimes looking for similar bugs 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 good practice to easily replicate the scenario.
  • Verify a few more times to determine the occurrence of the defect. Do not trust or report further on the basis of a single time occurrence of the issue.
  • Testing with patience is a key factor as this might and will take a lot of time

Additionally,

  • Even when 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 good practice to verify the same issue on different browsers/operating system combinations, different devices (supported). This helps in determining whether the issue is system or browser specific/ device specific.
  • Keep yourself updated with new trends and forums about different types of issues and their occurrences. This helps in differentiating system specific, browser specific, product specific, external issues, etc.
  • Instead of continuing to try to reproduce the issue once occurred, sometimes sitting back and analyzing the steps performed can help find a solution.
  • Discussing with other team members or managers can sometimes be helpful. There is a popular saying, Experience counts.
  • Sharing your screen can also be considered as an option apart from screenshots and videos to explain the issue to the developers.
  • Reproduce the issue 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 to the queries and concerns of the developers.

Conclusion

Keeping in mind the discussion in this article, it can be clearly concluded that it is very crucial to “reproduce a bug” in order to get that bug validated and fixed eventually. If the bug is not reproducible, then the testing effort used in finding, analyzing and reporting that particular bug/defect will become a complete waste.

For understanding and reproducing a bug, it is essential to have properly explained the “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 consuming 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 points that have been mentioned in the above article can be very helpful.

Don’t forget to give your feedback and share your experience with us in the comments section below. We would love to hear your thoughts and answer your doubts/queries. Thanks for taking the time to read this article.

Was this helpful?

Thanks for your feedback!

Recommended Reading

  • What is Defect Based Testing Technique?

    Defect-Based Software Testing Technique A Defect-Based Testing Technique is a technique where test cases are derived from defects. Instead of using traditional requirements documents or use cases (Specification-based techniques), this strategy bases its test cases on defects. A categorized list of Defects (called a Defect Taxonomy) is being used. The coverage…

  • Defect Life Cycle and Defect Management Process

    Introduction to Defect Management Process: The more focused process and testing will allow less buggy software in the market. Defect Prevention is much more efficient and effective in reducing the number of defects and also is very cost effective to fix the defects found during the early stage of the…

  • Defect density guide

    This article is an extensive and all-in-one guide to Defect Density. We will see its importance and how to calculate it. Let's get started.  Test Metrics can be tricky. They are the only way to measure yet the variety is overwhelming. You could be collecting something that isn’t giving you…

  • Defect Prevention methods

    Here is an article on effective Defect Prevention Approaches and Critical Views: Quality Assurance is the term that is commonly used to address the testing teams in IT projects. Technicalities aside, quality assurance activities are not just targeted at defect identification (which is finding defects after they have happened). This…


READ MORE FROM THIS SERIES:



18 thoughts on “Steps to Reproduce a Not-Reproducible Defect in Testing”

  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!!!!

    Reply
  2. 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!

    Reply
  3. 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 sheet.is there any way to find particular line number that have defect.to fetch that line number ,module name etc. or if its database side defect then how to find particular defect

    Reply
    • @ Dev patel and Rabi Mani Upadhaya
      Please find sample defect report as well as some more reading on the topic here:
      Softwaretestinghelp.com/bug-tracking-test-metrics-and-test-sign-off-free-qa-training-day-6/
      Softwaretestinghelp.com/sample-bug-report/
      Softwaretestinghelp.com/sample-bug-reports-for-web-and-product-applications/
      Softwaretestinghelp.com/how-to-write-good-bug-report/

      Reply
  4. 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!

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

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

      Reply

Leave a Comment