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
testing.
share the main mistakes in writing bug reports from my students. The
information will be more interesting for those who begin their journey in
testing.
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.
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:
- id
- priority
- severity
- stability
- header
- description
- environment
- preconditions
- playback steps
- actual result
- expected result
- additional information
- attachments
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:
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
error. - The bug report must be atomic, that is, it can describe an error for a
single value. - 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
redundant). - In general, title and description - for a text description without
data. - 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
was detected. - 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
expected. - The expected result can be only one to ensure the atomicity of the bug
report. - 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)
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)