When it Makes Sense to Replicate an Issue

Replicating checkout bugs can be a time consuming and difficult process. Starting the debugging process with replication is a path that we notice often results in wasted time and frustration. This document was create a framework to help guide the reader when faced with bug replication in the checkout process.

Topics for Consideration

OS, browser type, browser version, settings, and storage are just a few variables that make replicating a seemingly simple issue into a time intensive task. Although bug replication is useful for understanding the root cause of an issue, sometimes it makes sense to take other approaches first. Here are some factors to consider before getting too deep into the replication process:
  • Is the error an HTTP error or a JavaScript error?
  • How much data has been collected on the issue to this day?
  • Does the error seem to be a Browser or an OS specific error?
  • How much time do you have currently to allocate to the error?
  • Are there any immediate clues which identify possible root causes?
  • Does the timing of the error correlate to any timing of updates in code?


A Recommended Strategy

As their are many types of bugs we recommend a method similar to the approach listed below when attempting to track down problems.

  1.  Use the listed factors above to get a solid foundation, and structure your approach to the problem
  2.  Take a look at the stack trace or the error code received in the Noibu Developer tab
  3.  Try a quick replication to see if you get lucky and the error is there (don't spend more than 10-15 minutes on this)
  4.  Assess provided data, and formulate hypotheses for what currently could be causing the issue
  5.  Use the scientific method to try to test and disprove the hypotheses
  6. Take potential hypotheses and create potential solutions.
  7. Assuming you understand the bug well, this is a reasonable time to replicate a bug.
  8. Create and deploy the potential solution.
  9. Verify the solution is valid using data.


Although this strategy is not exhaustive it serves as a good foundation for an effective debugging method which we have seen users adopt in their stack successfully. It can be noted that you could do a bug replication at the start of your debugging process. The main takeaway from this article is that you should not expend too much time or effort on replication as it rarely leads to a successful outcome. Rather if you start with replicating the issue only spend 5-10 minutes on it. Furthermore it is important not to be be discouraged if you can't find it because probabilistically finding it is unlikely in the first place.
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Please sign in to leave a comment.