paint-brush
Common Mistakes in Bug Reports and How to Fix Themby@taacoder
442 reads
442 reads

Common Mistakes in Bug Reports and How to Fix Them

by Alexey TaranenkoOctober 30th, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

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. 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.
featured image - Common Mistakes in Bug Reports and How to Fix Them
Alexey Taranenko HackerNoon profile picture

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)