Common Mistakes in Bug Reports and How to Fix Them
Too Long; Didn't ReadA bug report is a document describing an error in the system, as well as a sequence of actions on how to reproduce this error. The bug report has the main fields that are filled in when creating: id- priority- severity- severity, stability, header- description, playback-step- and results. Bug reports do not need to be overloaded with text, especially for text descriptions, they should be moved to the playback steps. The title should be written briefly and succinctly about the error in (What? Where? When), but without losing the meaning.
Hi all! As a teacher of software testing at an IT school, I want to
share the main mistakes in writing bug reports from my students. The
information will be more interesting for those who begin their journey in
It's no secret that the skill of writing a bug report is very important
for a tester. From a brief description, a bug report is a document describing an error in the system, as well as a sequence of actions on how to reproduce this error. Information is also given on how the system should have worked in the context of the described error, based on the requirements for this system.
The bug report has the main fields that are filled in when creating:
- playback steps
- actual result
- expected result
- additional information
- Of course, you can add something else, but each testing team decides
individually. Well, knowing the definitions of a bug report and its fields that need to be filled in, the questions arise:
- how and what to write
- write long or short
- where you can enter certain data, where you can not
In order to answer these questions, I present to you a selection of tips
for writing a bug report correctly, of course, from the point of view of my
knowledge and practice:
- A bug-report should not refer to another bug-report.
- The bug report must be atomic, that is, it can describe one type of
- The bug report must be atomic, that is, it can describe an error for a
- When checking one field, other fields need to be filled with valid
values, this should be added to the playback steps.
- The input data in the title or description does not need to be
written, it is in the playback steps.
- You do not need to write the received data in the title or
description, it is in the result.
- Bug reports do not need to be overloaded with text, especially for
titles, descriptions, results.
- If there is data that overloads descriptions, they should be moved to
steps or results, depending on the purpose.
- The title should be written briefly and succinctly about the error in
the form (What? Where? When), but without losing the meaning.
- The description is slightly expanded than the title.
- The description should not contain arguments and assumptions about the operation of the system (mention or description of the requirements is
- In general, title and description - for a text description without
- Playback steps and results - mainly for writing short text data.
- In the playback steps, you do not need to describe the data, you need
to write what was entered.
- In the playback steps, write the data that was entered when an error
- In the actual result, you need to write the data that is displayed as
a result, if any.
- In the expected result, there should be only the result and there
should not be arguments and assumptions about the operation of the system.
- The expected result should contain only the result without a
description of the user's behavior (this is superfluous).
- In the results, there should be only results and there should not be
arguments and assumptions about the operation of the system.
- We write the results after the fact briefly, what happened, what was
- The expected result can be only one to ensure the atomicity of the bug
- Bug report with the wording (enter any word, or value, or arbitrary
number) is incorrect, you need to work with specific data
- Bug-report with the wording (input of unlimited quantity, infinite
quantity, any quantity) is not reproducible. It needs to be removed or
reformulated. Need to work with real and specific data
- You can use abbreviations, the main thing is that teammates understand
what is at stake.
- Bug-reports are better to issue on an error in the boundary value, so
the developer can more accurately understand the place where the error was found in the system.
I hope in this list someone found out their mistakes at the beginning of
the journey). Also hope, that my notes can be useful for you in the future and I wish everyone successful testing and good bug reports)