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)

This story contains new, firsthand information uncovered by the writer.

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Common Mistakes in Bug Reports and How to Fix Them

Too Long; Didn't Read

Alexey Taranenko

STORY’S CREDIBILITY

Original Reporting

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Common Mistakes in Bug Reports and How to Fix Them

Too Long; Didn't Read

Alexey Taranenko

STORY’S CREDIBILITY

Original Reporting

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES