All articles

Bug Report

Bug Report

A bug or defect report is a document describing a situation or sequence of actions that led to an incorrect operation of the test object, indicating the reasons and the expected result.

The following information will help to get an idea of the structure, features of writing and some other nuances necessary for writing, good bug reports:

  • Structure of the bug report
  • Severity and Defect Priority
  • Writing a bug of reports
  • Life cycle of a bug

After reading the Bug Summary, the developer needs to understand what the problem is, by reading Bug Description, he must know the line of code that must be edited.

You can agree or disagree, but the point of this statement is that you should do everything so that there are fewer questions for you on the merits of the problem described in the bug report. Since every bug returned with a status of “Rejected”, “Can not Reproduce”, “More info” is a loss of time, both yours and the developer. And time, as you know, is money.

We are sure that if in the future you use all the recommendations we proposed, the quality of your bug reports will be at a high level, and in the process of work, there will be the least complaints from both managers and developers.

Bug ReportSeverity and Defect Priority

Different systems of bug tracking offer us different ways of describing the severity and priority of the bug report, only the meaning attached to these fields remains unchanged. Everyone knows a bug tracker like Atlassian JIRA. In it, starting with some version instead of using the Severity and Priority fields simultaneously, only Priority was left, which collected the properties of both fields: Originally, JIRA did both a Priority and a Severity field. The Severity field was removed for a number of reasons …  Thus, those who are accustomed to working with JIRA do not always understand the difference between these concepts, since they did not have experience of their joint use. Based on personal experience, I insist on the separation of these concepts, or rather, using both the Severity and Priority fields, since the meaning invested in them is different:

Severity is an attribute that characterizes the effect of a defect on the health of an application.

Priority is an attribute that indicates the order of execution of a task or the elimination of a defect. You can say that this is a tool for the planning manager. The higher the priority, the faster you need to fix the defect.

Severity Grading

S1 Blocker

A blocking bug that causes the application to become inoperable, as a result of which further work with the system under test or its key functions becomes impossible. The solution of the problem is necessary for the further functioning of the system.

S2 Critical

A critical bug, an incorrectly working key business logic, a security hole, a problem that resulted in a temporary server crash or causing a part of the system to fail, without the possibility of solving the problem using other input points. The solution of the problem is necessary for further work with the key functions of the system under test.

S3 Major

A significant mistake, part of the main business logic is not working correctly. The bugis not critical or there is an opportunity to work with the function under test using other input points.

S4 Minor

A minor bug that does not violate the business logic of the tested part of the application, an obvious problem of the user interface.

S5 Trivial

A trivial bug that does not concern the business logic of the application, a poorly reproducible problem, barely visible through the user interface, the problem of third-party libraries or services, a problem that does not have any impact on the overall quality of the product.

Priority grading

P1 High

The bug should be fixed as soon as possible, because its availability is critical for the project.

P2 Medium

The bug must be corrected, its availability is not critical, but requires a binding decision.

P3 Low

The bug must be corrected, its availability is not critical, and does not require an urgent solution.

The order of error correction according to their priorities:

High -> Medium -> Low

Requirements for the number of open bugs

We would like to offer you the following approach to determining the requirements for the number of open bugs:

The presence of open defects P1, P2 and S1, S2, is considered unacceptable for the project. All such situations require an urgent decision and are under the control of the project managers.

The presence of a strictly limited number of open errors P3 and S3, S4, S5 is not critical for the project and is allowed in the issued application. The number of open errors depends on the size of the project and the established quality criteria.

All requirements for open errors are discussed and documented at the decision-making stage on the quality of the product being developed. As an example of documenting such requirements, it is the Criteria for completing the test in the test plan.