Main attributes of bug-reports

Bug report is a technical document that describes a situation or a sequence of actions that lead to the incorrect functioning of the test object with mentioning the causes and the expected result.

Let’s list and analyze the main attributes of the bug report in details:

Summary

The first attribute which is filled by a tester is a short description of a bug (Summary).

This field should be briefly summarized with the essence of the bug. In order to fully describe the bug you will need to consequentially respond to three questions: WHAT works wrong? on what place of the product, in other words WHERE? and WHEN the issue appears?

For example:

Required fields are not marked on the registration form after clicking the «Send» button.

Description

In the Mantis bug tracker this field is used for a more detailed description of the bug, if it is necessary. In all other popular bug tracking systems (Jira, Redmine) the «Description» field is used for describing the Steps to reproduce and the Actual/Expected results.

In the Mantis bug tracker these attributes (steps and results) are described in the «Steps to reproduce» field.

Steps To Reproduce 

It is necessary to describe the steps accurately, so that the issue can be reproduced without any obstacles.

For example:

1. Open the (site domain name) site.
2. Click the «Sign up» button.
3. Click the «Send» button.
4. Pay attention to the registration form.

In cases, if there are too many (more than 8) steps to reproduce, you can add them in the preconditions, for example:

1. The user is signed into the system.
2. The product is added to the cart.

Actual/Expected Result

Actual result indicates what does not function correctly, in which section of the product and under what conditions (in other words, for describing the actual result, once again, it is necessary to follow the «What? Where? When?» principle ). 

Expected result indicates how exactly the system should work according to the tester, for example:

Mandatory fields for filling out are highlighted in the «Registration» form after clicking  the «Send» button.

Attachments

You need to attach some files to bug reports, such as a screenshot, a video or a log file. It is necessary because the information is better perceived  visually than in the written form. Sometimes, developers don’t have to read the steps to reproduce the issue and the description if you'll attach a screenshot with red highlighting and arrows just right to the issue.

Priority 

This is an attribute that indicates the order where a task is completed or a defect is resolved. It's like a work scheduling manager's tool. The higher is the priority, the faster the defect needs to be fixed.

One of the options for the defect Priority gradation:

P1 High
The bug should be fixed as soon as possible because it’s presence is critical for the project.

P2 Medium
The bug should be fixed. Its presence is not critical, but it requires a mandatory solution.

P3 Low
The bug still should be fixed. Nevertheless, its presence is not critical and does not require an urgent solution.

The order of fixing bugs by their priority: High -> Medium -> Low.

Severity 

This is an attribute that characterizes the impact of a defect on the performance of an application.

Here are the options for the defect severity gradation:

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

S2 Critical
A critical bug, incorrectly working key business logic, a security hole, a problem that led to a temporary server crash or rendered some part of the system inoperative without the possibility of solving the problem using other entry points. The solution to the problem is necessary for further work with the key functions of the system. 

S3 Major
A major issue, when a part of the main business logic is not working properly. The error is not critical or it is possible to work with the function using different input points.

S4 Minor
A minor issue that does not violate the business logic of the part of the application and is an obvious user interface problem.

S5 Tweak
Inconvenience, which is an obvious user interface problem. It means that you need a «fit», an increase in the usability of the interface.

S6 Text
Minor text error or a typo. Punctuation or spelling error.

S7 Trivial
The severity that does not impact on the business logic of the application. A poorly reproducible problem that is hardly noticeable through the user interface. A problem with third-party libraries or services, an issue that does not have any impact on the overall quality of the product.

Status 

The main attribute defining the current state of the bug. It reflects the life cycle of a bug from the initial state to its completion.

Defect status names can be different in different bug tracking systems, and also differ from those used on the course. 

Standard set of statuses (according to the Mantis bug tracker):

New –  the basic status of the new bug report;
Feedback – the status which is given in case when the additional information to reproduce the defect is required;
Acknowledged –  the status that is given when the defect has been studied, but there has not been confirmation of it being a bug and the person in charge has not been appointed yet;
Accepted – the status that means that the defect has been reproduced and confirmed;
Assigned –  the bug report status which means that the bug has been assigned to the developer to resolve;
Resolved – the status asssigned when the issue is resolved, confirmation of it is pending;
Closed – the status that informs that the defect has been fixed, confirmed, and does not require any further action.

The environment of the bug

Components and Environment are defect attributes that indicate where this defect is reproduced (iOS, Android, Windows, Mac, and their versions, names and versions of browsers where the defect is reproduced). The environment is specified in the «Platform» (browser name and version, PC or Mobile), «OS» (operating system name), and «OS Version» (operating system version) fields in Mantis.

You should also specify the minor attributes of the bug report:

Fix Version is an attribute that indicates on  what stage of software development the defect was found.

Assignee is an attribute that indicates the person for whom this bug report is assigned for further verification or correction.

Build is an attribute that indicates the build number on which the defect was found.

Label is an attribute that indicates that a defect belongs to one or another type of defect (graphic defect, localization defect, etc.)

Look at the example of the correct  bug report:

You can find more examples in the Mantis bug tracker in the «Examples of well-formulated bugs» project as well as in the user's personal account in the «Documents» > «Lecture Materials» section.