Bug report

A bug report is a technical document that describes in detail an error in a program, application, or other software. It is compiled by a tester so that developers can understand what is wrong, how critical the defect is, and what needs to be fixed.

Bug reports are part of the workflow. They document the existence of a bug and assign responsibility for fixing it. If you report a bug in a team chat, it will likely be forgotten. Each team member will assume the other will fix it, and ultimately, it will remain in the code.

Types of bugs

• Functional. These occur when the actual results of work do not meet expectations: you can’t post a comment on the site, add an item to your cart, or open a page.
• Visual issues. These are cases where the app looks different than intended: a button overlaps text, images don’t display, or text extends beyond the window.
• Logical. A bug where something doesn’t work logically—for example, when you can enter a nonexistent date (February 31) or a birth date from the future (2077).
• UX defects. The app or program is difficult to use: when browsing the news feed, the user is constantly thrown back to the beginning, buttons are too close together, and they are constantly being pressed instead of one.
• Security flaws. Cases where, due to a coding error, user data (email addresses, passwords, photos, payment information) may be accessible to third parties.

Bug report structure

The fields vary depending on the specific company’s policies, but most often each document contains the following items:

Severity and priority of bugs

Severity is an indicator of a bug’s impact on a program’s operation, whether it can function without a fix or whether the bug breaks the entire system. There are five levels of bug severity:

• S0 Trivial (Trivial) — the bug doesn’t affect the program’s operation, so fixing it may not require a separate task, but rather be addressed alongside other, similar bugs. For example, when filling out a form, the “Date of Birth” field displays 1999 by default, not the current year.
• S1 Minor — the bug barely disrupts the logic of processes, so the program can function normally with it. For example, navigation in the interface is difficult.
• S2 Major (Serious) – the bug creates inconvenience in use, but does not yet impair the functionality of the program.
• S3 Critical — a bug prevents the app from performing basic functions: the expense calculator incorrectly calculates the budget, or text cannot be entered in the text editor.
• S4 Blocker (Blocking) is a situation where a program does not work at all: the site returns a “404 error” or the application does not launch.

Priority is the urgency of a task’s completion. There are three priority levels:

• P1 High – fixed first, as the bug breaks the application’s operation.
• P2 Medium – a bug that must be fixed after a critical one.
• P3 Low – does not require immediate action.

The life cycle of a bug

The status of a bug in a report is determined by its “life cycle,” which consists of four main stages:

• Open — a tester has identified a bug and added it to the report.
• In Progress — the bug has been reported to the performer and is being fixed.
• Fixed (Ready for check) — the performer has finished fixing the bug and has handed the project over to the tester for re-checking.
• Closed – the bug has been fixed and is no longer reproducible.

In addition to the main ones, there are several more statuses:

• Rejected — an error in the report prevented the bug from being fixed, such as an incorrect algorithm in the “Steps to Reproduce” section.
• Deferred – the bug is considered a low priority, and the fix is ​​postponed.
• Reopened – the bug was deferred or rejected, but now the performer has taken it on.

How to write a bug report correctly

A bug report is technical documentation, so it shouldn’t contain unnecessary phrases—just the facts, presented in simple language.

What should you pay attention to when describing a defect?

Identify the root cause. For example, if a website’s password recovery fails, the issue could be in either the backend or the frontend. The tester’s job is to figure this out, as this will determine which developer should handle the bug.

Test on different devices. If the issue occurs on the desktop version, it may also occur on mobile devices, so it’s worth checking.

Test the bug in different software versions. The bug may not be reproducible in the older version, but will appear in the newer version.

Describe the discrepancy with the expected result. To compare the current program performance with the expected result, new developers should consult the technical documentation and requirements specifications, which detail how everything works ideally.