Unreproducible Bugs

In the case of software testing, the “detecting-reproducing-fixing” cycle should be performed clearly and strictly without any delays. If one finds it hard to finish any of these stages of the QA process, it means that more than likely software testing company faces the problem of the project release delay.

Let us stop at the intermediate part of this cycle and try to understand why sometimes it is difficult to reproduce the reported bug, what the reasons for this are, and how one makes that defect be reproduced at the end.

Imagine that a tester has created the bug report, and has accurately written the “steps to reproduce”. Now he wants to follow all these steps one-by-one to assure that it is a real bug. In the case of the same expected result occurrence, the bug may be considered as reproducible. In the opposite, the defect is called non-reproducible.

Certainly, there are other required fields to be filled in and special additional information about the error should be specified, e.g.: severity and priority, screenshots, expected result, and so on. However, the inability to repeat the “steps to reproduce” slows down the whole report.

When Is It Impossible to Reproduce a Bug?

  • The defect occurs only in the case of system restarting.
  • The error occurs randomly, for instance, only 2 users out of 5 are able to make an order from the App Store.
  • After many hours of examining the defect and finally reporting it in the bug tracker system, a tester founds out that it is not reproducible.

The above-mentioned situations are widespread in the software testing practice and only the most experienced and well-qualified testers do not give up and continue going to their main goal – to detect the most severe system bugs.

It is quite difficult to specify all conditions under which the bug occurs, as a tester cannot reproduce it one more time. So he has to describe in details everything he has done before to provide as much information about the occurred error as possible.

Tips Helping to Reproduce a Problem Bug:

  • Fulfilling any kind of checking, whether functional testing, user interface testing, ad-hoc testing, security testing or acceptance testing, a tester should be very attentive towards the executed process.
  • During the test cases performance, cookies and cash should be periodically cleaned.
  • One should proceed the reporting only after several times of the same bug occurrence, not only one.
  • The usage of the patterns or the previous experience may greatly help in the following activity.
  • Every taken step should be obligatory fixated through the special screen capture tools, in order to simplify the further test procedure.

Source by Helen Johnson