Top 8 Mistakes When Making Bug Reports

Only those who do nothing make no mistakes. And our students work hard in the process of learning a new job. Performing tasks on the course, students learn from others and their mistakes. In this article, we have collected the most common mistakes of students in the description of bug reports. Hopefully, this article will help you better understand how to write a clear and complete description of a bug.

1. “Page is not working”, “Authorization is incorrect”, “Nothing happens after pressing the button”

If the goal is to describe the bug as informatively and incomprehensibly as possible – this type of description is what you need. From the above, it is not clear what exactly is wrong with authorization or what should happen after clicking the button. This is one of the most serious mistakes in describing the nature of the defect. You should always clearly indicate the bug.

2. Bug Is Described NOT According to the Principle of “What? Where? When?”

Many people may find it difficult or unnecessary to follow this requirement to describe bug reports. But this principle helps to briefly and fully describe the defect, where it occurs, and under what conditions. This principle is a general rule, an algorithm for compiling a description of the bug. The absence of any of the above makes the bug description less informative.

3. Description of Two Different Bugs in One Bug Report. Duplicate Bug Reports

One bug report can describe only one error. You cannot combine the description of two bugs in the title or write two different sentences. But do not make duplicate bugs: if the same defect is repeated in different places or with different elements, it must be indicated in additional information.

4. Excessive Information in Steps to Reproduce

Reproduction steps must describe only those actions and their sequence that lead to the bug. After fixing the bug this is necessary to check its non-reproducibility. You do not need to add extra information to the steps, such as a description of the nature of the defect in the last step. The last step is to pay attention to the place, block, or page, where the defect is reproduced. This will help detect the bug faster without opening a screenshot or video.

In addition, the steps often include links to other pages of the website, which is unnecessary. The link to the pages may change. Instead of direct links, you need to add the names of the required pages and steps that describe how to reach them, and in the first step – a link to the main domain of the tested website.

5. Missing Bug Report Attributes

A bug report has required attributes, without which it is meaningless. You must always include the title, the description of the bug, the steps to reproduce it, and the expected result. And, of course, without a screenshot or video, you cannot confirm and prove that this bug was reproduced.

6. Absence of Test Environment

A very serious and frequent mistake. The bug can only be reproduced in a specific browser and its version, resolution or OS. For example, in one version of the browser, the bug can be reproduced, in another not. To reproduce and fix the bug, you need to know the version of the browser and operating system where the bug was detected.

7. Extra Items in the Screenshot (Video) or Absence of Any Attachments

The screenshot or video should show the full part of the page with the address bar visible in the browser. In the case of a screenshot, the red rectangle and arrow should point to the place of the defect. The absence of these elements or the presence of unnecessary, distracting (bookmarks, tabs, etc.) is a mistake. It is important to add a screenshot, even if there is a video.

8. Spelling Mistakes in the Bug Report

The bug report is the same documentation as any other and must be handled correctly. Spelling mistakes interfere with the perception of the bug described in the report. You should check the written text and watch grammar. To do this, you can use online tools.

After reading this list and following the tips, it will be easier to make a good bug report, which will be clear after the first time and will not require additional clarification. A good bug report increases the chances of successful and productive training on the course, as well as reduces communication time and speeds up the process of fixing bugs in the real project.