Wherever you are, you can help Ukraine

Act Now! Flag Ukraine

“Cannot Reproduce”: 10 Steps to Get Rid of Persistent Bugs

TestFortExpert by TestFortExpert on 03/7/2014

“Cannot Reproduce”: 10 Steps to Get Rid of Persistent Bugs

Unreproducible bugs can easily make a tester’s existence painful. Too often testers find a bug, then report it and get the answer “This is not a bug – I can’t reproduce it.” Still, the bug may be there, awaiting its next victim.

Unreproducible bugs can be very much expensive because of their increased lifetime and investigation time. They may as well have a quite damaging effect on your product perception in case the users reporting such bugs are ignored. Therefore, testers should do better to prevent them.

Here are 10 things testers can do to reduce the number of unreproducible bugs even now.

  1. Regularly do stress testing of your system unless you want to run across some unexpected failures when it is heavily loaded.
  2. Test timeouts. Make tests which fake or mock dependencies for timeout code testing. If the timeout code works wrong, it can cause a bug appearing only under certain conditions of the system.
  3. Test with optimized and debug builds. It happens that a good debug build works right, but your system fails in some strange ways as soon as optimized.
  4. Test with constrained resources. It’s a good practice to simulate the reduced network bandwidth as well as minimize the number of data centers, threads, machines, processes, available disk space and memory.
  5. Test for longevity. There are some bugs that require a long time to expose themselves. For instance, persistent data can become corrupt over some time.
  6. Utilize dynamic analysis tools such as memory debuggers regularly. They help identify numerous categories of unreproducible threading and memory issues.
  7. Perform fuzz testing to check your system’s hardiness at the time of enduring bad data.
  8. Always test the error handling code. Usually this is best achieved by mocking and faking the component which triggers the error.
  9. Remember to test concurrent data access when it’s the system’s feature. And if it’s not, verify that your system rejects it.
  10. Save the test logs for later potential analysis.

These seemingly obvious and not so obvious software testing guidelines will help you reduce the chances of “can’t reproduce” bugs to occur in your project.

Inspired by Google Testing

We use cookies to ensure your best experience. By continuing to browse this site, you accept the use of cookies and "third-party" cookies. For more information or to refuse consent to some cookies, please see our Privacy Policy and Cookie Policy