Bug reports allow the developer to understand what happened, where it happened, and under what circumstances. What is a bug report for, and how do you create one? Let's talk about that in this topic.
A bug report
Bug reports are documents containing information about errors or malfunctions found in an application during testing. They are created by testers or test teams to report problems and pass them on to developers for correction.
Attributes of a defect report
Identifier (id). Unique identifier in the issue tracking system, set automatically by the system.
Summary. It should briefly and comprehensively address the questions of what happened, where it occurred, and under what conditions it happened.
Detailed description. Presents the necessary information about the fault in a detailed form.
Pre-conditional. Describes the conditions under which the fault can be reproduced. For example: You must be an administrator.
Environment. Describes the environment in which the defect can be reproduced, on which platform, in which operating system, etc. For example Browser – Chrome 86.2.415, OS – Windows 8.
Steps to reproduce. Describes the actions to be taken to reproduce the error. The steps are described in as much detail as possible, including specific input values and the smallest details, since the lack of this information in complex cases may make it impossible to reproduce the defect.
Reproducibility. Indicates whether each pass through the steps of defect reproduction succeeds in causing its manifestation. This field takes only two values: always or dynamically. It is often the case that when the steps are run, the problem occurs 1 out of 3 times, and the tester cannot find a specific reason for this behavior.
Severity. Indicates the degree of impact on the product. The following severity levels are distinguished:
Critical – the existence of the defect leads to large–scale consequences of a catastrophic nature. Example: Messages in Messenger are not sent.
Important – the existence of the defect causes significant inconvenience to many users in the course of their typical activities. Example: A user is typing a message in a messenger and suddenly the application hangs and does not respond in any way. The user has to restart the application to continue working.
Medium – the existence of the defect has little impact on typical user scenarios and/or there is a workaround to achieve the objective. Example: On the website there is the possibility to authenticate via Google, Facebook, email. However, Google authorisation no longer works, but there is a workaround for Facebook and email authorisation.
Minor – the existence of the bug is rarely noticed by a small percentage of users and has almost no impact on their work. Example: a typo in a deeply embedded paragraph of the product manual.
Priority. Indicates how quickly the defect should be fixed. Generally, the following levels of urgency are used:
ASAP (as soon as possible, highest) urgency indicates the need to correct the defect as soon as possible.
High urgency means that the defect should be corrected immediately because its existence is objectively affecting the work or will begin to do so in the very near future.
Normal urgency means that the defect should be corrected in order of general priority. Most defects are assigned this priority level.
Low urgency means that the correction of this defect will not have a significant impact on the improvement of product quality in the foreseeable future.
Actual result. The result was obtained after going through the steps to reproduce.
Expected result. Describes the expected behavior of the software in accordance with the requirements after the steps have been performed (correct behavior).
Attachments. This is not so much a field as a list of files attached to the bug report (screenshots, videos, logs, etc.).
Example of a bug report for the User Registration application:
Common mistakes
Mistakes in layout and wording:
Poor summaries.
Ignoring quotation marks, which distorts the meaning. All names of buttons, fields, etc. should be in quotation marks.
Unnecessary elements in playback steps.
Multiple actions in one step.
Screenshots of the screen where the problem is not highlighted. Circling the problem area with a red line will in most cases speed up the process and make it easier to understand the nature of the problem.
Postpone report writing "for later”. Putting off writing a report "for later" leads to either forgetting important details or forgetting the existence of the problem in general.
Punctuation, spelling, syntax, and similar errors.
Logical mistakes:
False errors. Scenario when the correct application behavior is mistakenly described as incorrect, even though it is not. For example, a new tester on the project, not knowing the application, decided that this is a bug (for example, the long loading time of an application page), but this is the expected behavior of the program.
Overestimation or exaggeration of importance and urgency.
Focusing too much on small details and ignoring the overall picture. A vivid example: a tester found a problem that caused the application to crash with loss of user data, but recorded it as a cosmetic defect.
Technical illiteracy. Imagine such a short description: "The number of files found does not match the operating system". What should it mean? It's almost the same as "the color of the cat does not match this size".
Including information in the replay steps that is not important for reproducing the error.
Leaving out crucial details in the steps.
Conclusion
The main purpose of creating a bug report is to provide information about the problem. A bug report allows you to prioritize the problem – to determine the extent to which the problem affects the product. A quality bug report not only provides all the details necessary to understand the bug, but also helps to analyze the causes of the problem.