Unreproducible errors

In the case of software testing, the “detect-reproduce-fix” cycle must be done clearly and strictly without delay. If one finds it difficult to complete any of these stages of the QA process, it means that the software testing company will most likely face the problem of delayed project release.

Let’s stop in the middle of this cycle and try to understand why it is sometimes difficult to reproduce the reported error, what are the reasons for this, and how that defect is caused to reproduce in the end.

Imagine that an evaluator has created the bug report and has precisely written the “steps to reproduce”. Now you want to go through all these steps one by one to make sure it is a real bug. In the event that the same expected result occurs, the error can be considered reproducible. In contrast, the defect is termed non-reproducible.

Certainly, there are other mandatory fields to fill in and special additional information about the error must be specified, for example: severity and priority, screenshots, expected result, etc. However, the inability to repeat the “steps to reproduce” slows down the entire report.

When is it impossible to reproduce a bug?

  • The defect occurs only in the case of rebooting the system.

  • The error occurs randomly, for example, only 2 out of 5 users can place an order on the App Store.

  • After many hours of examining the defect and finally reporting it to the bug tracking system, an evaluator discovers that it is not reproducible.

The above-mentioned situations are rampant in software testing practice and only the most experienced and best-qualified testers don’t give up and continue to go towards their main goal – to detect the most serious system bugs.

It is quite difficult to specify all the conditions under which the error occurs, since an evaluator cannot reproduce it one more time. Therefore, you have to describe in detail everything that you have done before to provide as much information as possible about the error that occurred.

Tips to help reproduce a troublesome bug:

  • When performing any type of verification, be it functional tests, user interface tests, ad-hoc tests, security tests or acceptance tests, an evaluator must be very attentive to the process being executed.

  • During the performance of the test cases, cookies and cash should be cleaned periodically.

  • One should continue the report only after several times of the same error occurrence, not just once.

  • Using the patterns or previous experience can be of great help in the next activity.

  • Each step taken must be compulsorily fixed through the special screenshot tools, in order to simplify the further testing procedure.

Author: admin

Leave a Reply

Your email address will not be published. Required fields are marked *