One of the most interesting methods of learning is writing useless and rather harmful advice. In our blog there are a lot of articles about how to write the bug reports correctly, what attributes should be added and what requirements they must meet. However, in this article we will look through the things that should not be done and some typical mistakes of the beginner tester on projects.
Typical mistakes in bug reporting
Typical mistakes in bug reporting
1. Usage of the «What? Where? When?» principle in cases where the bug summary can be shortened and «Where?» and «When?» can be omitted.
Actually, the summary must answer one question and that question is «What?». In some cases, the answers of «Where?» and «When?» questions can be omitted, but only in cases when they don’t have any valuable information. It means that you, of course, should follow the «What? Where? When?» principle but as well, you must make sure that your bug reports sound logical and sane, yet laconic without duplicating the information or some extra information that is not important in the case.
| Incorrect | Correct |
|
One of the slider images is not displayed on the images slider after entering the site. |
One of the slider images is not displayed on the images slider. |
2. Absence of the prefix in the summary of the bug report while performing a mobile and game testing.
What is a prefix? It’s simple as in linguistics – it is a part that must be written before the summary in case of testing an application or a game: browser, device model, OS version, localization, f.e. ([Mobile] iOS або iPad 2. ZH. Quest 356). Just by looking at the prefix you can understand the environment of the tested product.
3. Too much text in the preconditions.
It is especially relevant with a large number of actions in the background and a small number of steps. Preconditioning is not always necessary. If you need to specify certain important data that is needed before starting to reproduce the defect and there are too many to put in steps, feel free to write them in the background. However, it is important to remember that the information in them should be clear and understandable and in any case it is not necessary to transfer steps there.
4. Lack of important additional information or steps/actions to reproduce the bug.
Information about the user's role or directly their username/password may not be specified if the bug is reproduced only by a specific user. In addition, it is important to add all the steps necessary to reproduce the defect, as without them it will be more difficult to reproduce it. If you create a bug report about an error in the game, you must specify in steps the platform on which the test was performed with the version of the operating system and the build number on which the test was performed. These peculiarities are needed for the developer to reproduce the bug in the right environment and in the right version of the build.
5. The reference to the primary domain is not specified or specified with an error in the first step.
The first step is usually to link to the primary domain. This is where the reproduction of the bug begins. If you specify it incorrectly, there may be a misunderstanding between the tester and the developer, who will be assigned to fix the bug.
6. The steps include links to specific pages of the site.
Only one link is allowed in the steps, only in the first step and only to the main domain. This is because page addresses may change. Instead of direct links, you need to add the names of the required pages and steps that describe how to go to these pages.
7. Detailed description of the error in the last step.
In the last step, you need to pay attention to the area with the defect – so the developer or other tester will quickly understand which part of the site/application/game to look at to see the defect. No need to describe the mistake itself. Leave its interpretation for other attributes of the bug report. The last step is to draw attention to the place, block, page, etc., where the error is reproduced. This will help detect the defect faster without opening a screenshot or video.
8. One of the results is described as a denial of the other.
Of course, the actual and expected results are opposite. When describing them, it is better to indicate a more specific expected result than to simply add «no» to the actual one, as such a description of the results is not always enough. Very often this does not give the developer an understanding of what the system should look like or work.
| Incorrect | Correct |
| Actual result: The error is displayed in the login form after filling the field with valid data.
Expected result: The error is not displayed in the login form after filling the field with valid data. |
Actual result: The error is displayed in the login form after filling the field with valid data.
Expected result: The successful authorisation is performed in the system after filling the field with valid data. |
9. Extra items in the screenshot (video) and the lack of necessary ones.
The screenshot or video should show the address bar visible in the browser. In the screenshot, the red rectangle and arrow should indicate the location of the error. The absence of these elements or the presence of unnecessary, distracting (bookmarks bar, third-party tabs, desktop, etc.) is a mistake.
10. The presence of extraneous sounds in the video.
To record video from the screen you need to use special programs. One of the common mistakes is the extraneous sounds in the video. It is solved very simply – you need to turn off the sound recording in the settings. Now when watching a video file, all attention will be paid only to the error.
11. Display third-party messages in a screenshot or video (messengers, etc.).
Creating a screenshot or recording a video, you need to make sure that it does not contain any extraneous messages or elements. They distract from the defect and may contain personal information.
12. Having a simple screenshot instead of a complex one to confirm the functional bug.
For a functional bug, there is usually one screenshot with a highlighted defect. You need to display the steps taken that led to the error and merge the screenshots into one. Also a good option would be to record a video of the defect.
13. The presence of several accents in the screenshots.
Adding more than one red rectangle and more than one red arrow to one screenshot can make it difficult to understand. It is necessary to allocate a rectangle to the defect instead of the whole section in which this defect is observed. Also, do not add two arrows to one rectangle or highlight one error with two rectangles.
14. Highlighting the error in the screenshot with a color that blends with the product design.
In the screenshots, it is customary to highlight the problem area with a red rectangle and a red arrow. If the element of the software product has a color close to red, then highlighting the area with an error should be another that contrasts with the background color.
15. No video crash from devices and file with logs in attachments.
Designing a crash bug, make sure to add a video bug and a file with logs. With the help of the logs, you can find out the reasons for the emergency shutdown of the software product.
We hope that the description of tips in this format will help to analyze your own bug reports better, understand the importance and reasons for the presence of each requirement for the report. After all, a good description of the error will help improve mutual understanding of the project and efficiency.
