Most common mistakes in a bug report

Have you ever seen a bug report?

Or maybe you have created one at some point?

I’m quite positive you replied ‘yes’ to these questions on at least one occasion.

This would mean that you have an idea about what an effective bug report is referring to its structure, format, useful attachments, etc.

Not everyone is perfect, and they tend to make some mistakes when putting together a bug report. That’s why I have prepared some examples of the most common mistakes I have faced during my work as a QA engineer at a travel company selling tickets for different means of transport (trains, buses, flights, and ferries).

Mistake 1: Too abstract a summary

A good summary should help to evaluate the issue at first glance. In other words, it should answer these two questions:

“What is broken?”’

“How big is the impact?”

At the same time, a title should be as short as possible to avoid deviating from the main topic.

The real issue: Train results are not available on a route between small towns.

A bad title example: Search doesn’t work.

Why?

This statement tells that the application is not workable at all and teams should stop work in progress until a fix is delivered whilst the affected route has low priority and there is no urgency.

How to improve: No train results between A and B.

Mistake 2: The summary doesn’t reflect the real problem

Real issue: Names on tickets issued for passengers aged 0-25 years old, are wrongly assigned.

A bad example: “[Provider name] youth ticket not generated.”

Why?

Tickets were issued, so the problem is different.

How to improve: “[Provider name] names are swapped in youth tickets.”

Mistake 3: Unsuitable evidence format

Very often testers overdo and attach a video file to show a static problem.

Real issue: Elements overlap each other on a page.

A bad example: The captured video shows scrolling from top to bottom of the homepage.

Why?

The issue is static, meaning wording in the button is always the same. It doesn’t matter what is searched is or what result is selected.

How to improve: Attach a screenshot of a page and highlight the overlay.

Mistake 4: Lack of device/version/browser information

Real issue: Styles are screwed up in a specific iOS version.

A bad example: Device and browser are specified in the description, but not on the iOS version.

Why?

The bug might be closed with status ‘Can’t reproduce’ or team spends time to reproduce, but in the end a decision to close without a fix is made because the version is not supported due to a low number of users.

How to improve: Add information about affected iOS version.

Mistake 5: Useless information

Real issue: This case is opposite to the previous one. The translation is missing, so the only keys that are displayed are in two out of the ten supported languages.

A bad example: Description includes information about devices and a separate bug report is created for each of the broken locales.

Why?

Two developers start the investigation thinking the root cause is device-specific because someone added devices into the report.

Why the need for two developers?

That is because they have got two issues in the backlog.

How to improve: The description should include only relevant information and any issues should be consolidated by the same root cause.

Mistake 6: Not formatted description

Real issue: Text formatting is not applied.

A bad example: All the required information is available, but the description isn’t structured.

Why?

The issue is hard to understand because readability is low.

How to improve: Split description into the logical part using bullets, numeration, text styles, etc.

The list can be extended as more and more cases come up but let me stop here and ask you to share your experience in the comments.

Check out our other Thought Leadership pieces here.