This article is dedicated to analyzing the mistakes that testers make while writing bug reports in bug-tracking systems and also, gives helpful tips for all new testers that start their career development.

Mistake 1. Using the” what, where, when” principle in the cases when the “where” and “when” parts should be omitted

Frankly speaking, a topic mustn’t always contain the answers to the “what” question only.

[highlight dark=”no”]In some cases, you need to omit “where and when” but only if they don’t contain any useful information.[/highlight]

Hence, you should always follow the “what, where, when” bug report requirements, constantly use right this order but not forget about common sense, sometimes omitting the answers to the questions that may destroy clearness, duplicate the data or are simply unimportant in a certain case.

Incorrect example / Correct example

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.

Mistake 2. A bug report’s topic doesn’t contain a prefix

What do we mean by the prefix? It’s easy – it’s the information that must be written before the topic when testing the performance of an application or testing another web software on a smartphone or in a game (browser’s name, device’s type, OS version, game’s locale).

[highlight dark=”no”]By analyzing the prefix, a tester can easily understand what testing environment has been used for testing and what is the best way to write a message for a developer.[/highlight]

Mistake 3. Preconditions contain too much text

This issue often occurs when preconditions contain numerous actions and a few test steps.

A precondition is actually not always needed. If you need to mention certain data, required for the bug reproduction, and their number is very high to mention them in test steps, then you can simply write them in the preconditions.

[highlight dark=”no”]But we shouldn’t forget that data inside them should be properly written and clear and that you should never add test steps there (to the preconditions).[/highlight]

Mistake 4. A complete absence of crucial additional data or bug reproduction steps

Sometimes the data related to the user’s role or his/her registration data are not mentioned in the case when the error can be reproduced only by using the account of a certain user.

[highlight dark=”no”]Moreover, it’s crucial to add test steps that are needed for bug reproduction since it’s very hard to reproduce the error without them.[/highlight]

If the error is mentioned in a bug report, such as the bug about non-working functionality in a game, you should mention the platform where you have reproduced the defect together with OS version and a number of the build where you have directly performed testing in a separate line.

You should specify this to help a developer reproduce defects in a proper environment and on a proper software build version.

Mistake 5. The description is absent or there is no link to the main domain in a test step

As we know, the link to a main web product’s domain is commonly mentioned in the first step. The defect reproduction always starts right from this action.

[highlight dark=”no”]If you make an evident mistake while doing this, there may be some misunderstanding between a tester and the developer who is responsible for fixing the found bug.[/highlight]

Such small details may lead to impeding the bug’s validation and verification and this may have a negative impact on time needed for test execution and bug fixing with their help.

Mistake 6. There are several links to certain website’s pages in test steps

Test steps should contain only one link, only in the first test step and only to the main test domain.

This is required for the cases when a web page’s address may change. [highlight dark=”no”]You should add the names of the required pages and test steps that describe how to rapidly reach such pages, instead of mentioning direct links.[/highlight]

Mistake 7. Detailed bug description in the last test step

[highlight dark=”no”]You should pay attention to the bug’s field in the last step.[/highlight] This will help a developer or another QA engineer to rapidly understand what part of software he/she should pay his/her attention to, to find the bug himself/herself.

You shouldn’t describe the bug itself. May its interpretation be postponed for other bug report’s attributes.

The last step is aimed at attracting the developer’s attention directly to the place where the bug always appears.

Such actions will help to rapidly find the bug, not looking at a screen capture or a video file.

Mistake 8. One of the results denies another one

Obviously, an actual result should be absolutely opposite to an expected result.

[highlight dark=”no”]You should describe each of them as a more expected result than just add the “not” word to the received actual result since such a description may be not always sufficient.[/highlight]

Frequently, such situations don’t give a developer a complete picture of the way the system should look and what functionality has been implemented in it, according to the client’s requirements, and what functionality is incorrect.

An incorrect example

Actual result: a system error is displayed in the user’s mobile phone field of the registration form.

Actual result: the defect is not displayed in the phone field of the corresponding form.

A correct example

Actual result: the error is displayed in the phone field after entering a valid value in the corresponding field.

Expected result: a user is successfully authorized in the system after entering the correct data in the phone field.

Mistake 9. Unnecessary attributes in a screen capture or absence of the required ones

[highlight dark=”no”]Photo or video files should display complete visibility of the used part of a web page in a browser with an address line.[/highlight]

If it’s a photo, a red square or a directed graphical line should point the bug.

A complete absence of the mentioned elements or presence of unnecessary ones that distract a project manager’s attention, and also, the developer’s attention, is the consequence of incorrect bug capturing. And this will lead to spending time and related costs and losses.

Mistake 10. Outside sounds or interrupting sounds and noises on a video

You can use various programs and applications for video recording.

One of the frequent mistakes that happen while video recording is the presence of outside sound.

[highlight dark=”no”]You can solve such issues very easily: just switch off the function of audio recording while recording a video.[/highlight]

Such an approach to bug capturing will help a developer to completely focus on the error.

Mistake 11. Unnecessary notifications are constantly being shown on a screen capture or a video

[highlight dark=”no”]When creating a screen capture or recording a video, a tester should ensure it doesn’t contain outside attributes or elements.[/highlight]

Since such objects can distract our attention from bugs and can (but not always) contain user personal data.

Mistake 12. Presence of a simple screen capture when the description of a functional defect is complex

Sometimes a functional bug doesn’t need a simple screen capture with the error highlighted.

[highlight dark=”no”]You need to display all actions that led a tester to the bug and unite them into one subsequent capture series.[/highlight]

It’s required to record a bug in the form of a short but informative video.

Mistake 13. Presence of several focuses on screen captures

If you add more than one field with the highlighted bug to one capture and draw numerous graphical arrows, a reader of the bug report can be simply complicated in the information he/she has received.

[highlight dark=”no”]You should highlight the bug itself but not the entire page where this error appears.[/highlight]

Also, you shouldn’t add several arrows to one square or highlight one bug with two squares.

Mistake 14. Highlighting a bug with the help of the color that does not contrast with the design color

It’s required to highlight weak spots with a red square and red arrow on all screen captures.

[highlight dark=”no”]But if a software object has a color that is too close to the red one, you should highlight the bug with another color that is in contrast to the background.[/highlight]

Mistake 15. Absence of video crashes from devices and a log file in the bug report’s attachments

[highlight dark=”no”]When describing the defect where software is crashing, you should always add the bug’s video or even a log file.[/highlight]

Logs help to rapidly find the reasons for the fast crashing of software.

Conclusion

All the above-mentioned tips should help new testers to easily analyze their own bug reports and find ways to improve their reports.

It’s important since only a qualitative bug description helps to improve mutual understanding of the projects and has a positive impact on the growth of productivity of the entire team.