Common Mistakes in Bug Reports and How to Fix Them

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.

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:

• 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:

• 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)