HOMEBlogCourse materialsHow to describe results in the bug report?

How to describe results in the bug report?

  • 14.03.2017
  • Posted by: Admin
How to write results in the bug report
In our regular rubric  «QA Tips for Newbies» there is a very important topic – rules for bug-report results.

Defect (bug) – a discrepancy between the actual result of the program and the expected result. Defects are discovered during the software testing stage when the QA engineer compares the results of the program (component or design) with the expected result described in the requirements specification.

Bugs must be reported for:

  • the official description of defects;
  • the appointment to those responsible for fixing them;
  • the defect monitoring;
  • the collection of reports on work on the project or its separate component.
The document that describes a bug is called a bug report.

Bug report – a technical document and that’s why the language for describing the issue must be technical too. A bug report contains a complete description of the bug, including information about the bug (summary, severity, priority, etc.), and about the conditions for the occurrence of this bug. The bug report must contain correct and universal terminology for describing the elements of the user interface and steps to reproduce this bug.

This article explains in detail the rules for describing the actual and expected results, which are required fields of the bug report.

Writing the bug report, the actual result is always written first and only then the expected result takes place.  There is a lot of controversy about which type of the results should come first and it is worth considering for what purpose the report is being created – in order to quickly inform the product developers and the whole team that something went wrong. A lot of QA engineers, especially QA interns, have difficulties creating a bug report. Understanding the essence of the problem, it  is very important to be able to inform the developer who will read the report in the future in the correct way. In order to avoid confusion as well as to save the time that is already limited by the project,  in IT it was decided to unify the approach to filling this field and as a result make life easier for testers. You need to get familiar with the terminology to understand how to describe the results in a bug report correctly.

The actual result – the observed or generated behavior of a component or system during testing. It describes what was obtained as a result of going through all the steps of the bug report. It is necessary to use the «What? Where? When?» principle for actual results which is also used in the bug summary. This principle is well-known. First, you need to write «what», and only then «where» and «when». The key difference between the description of the defect and the actual result is the more detailed spelling of the result. However, do not use complicated sentences. Compound and complex sentences, participial and adverbial expressions complicate the perception of the text. The simpler the sentence is – the better. It is also possible to split the text into several sentences, if necessary.

Example 1:

Bad Good
Nothing happens when adding an item to the cart. The item is not added to the cart on the «Item description» page after clicking the «Add to cart» button.
Let's consider each part separately:
  • «What?» (What happened?) Is NOT a noun, it is what happened, a kind of VERB-clarification («What is being done?» Or «What is NOT being done?»).
          «The item is not added to the cart» – WHAT?
  • «Where?» is the location in the system (application/website) where the bug was found.
           «on the "Item description" page» – WHERE?
  •  «When?» (After what? Due to what action? During what period?) – an action that resulted in a different result than expected.
            «after clicking the "Add to cart" button» – WHEN?

Example 2:

Bad Good
Application crashes when password recovery The application crashes on the «Login» screen after clicking the «Forgot password» button
Let's consider each part separately:
  • «What?» (What happened?) Is NOT a noun, it is what happened, a kind of VERB-clarification («What is being done?» Or «What is NOT being done?»).
          «The application crashes» – WHAT?
  • «Where?» –  is the location in the system (application/website) where the bug was found.
           «on the "Login" screen» – WHERE? 
  • «When?» (After what? Due to what action? During what period?) – an action that resulted in a different result than expected.
           «after clicking the "Forgot password" button.» – WHEN?

Example 3:

Bad Good
User cannot log into his account The transition to the «Profile» screen is not performed from the «Login» page after clicking the «Login with Facebook» button
Let's consider each part separately:
  • «What?» (What happened?) Is NOT a noun, it is what happened, a kind of VERB-clarification («What is being done?» Or «What is NOT being done?»).
          «The transition to the "Profile" screen»– WHAT?
  • «Where?» –  is the location in the system (application/website) where the bug was found.
          «from the "Login" page» – WHERE? 
  • «When?» (After what? Due to what action? During what period?) – an action that resulted in a different result than expected. 
          «after clicking the "Login with Facebook" button» – WHEN?

The expected result – the behavior of a component or system under specified conditions, as defined by the specification or other sources. In this field it is necessary to describe what should be and how the product should behave at the last step of the defect reproduction. However, why do you need to write this if everything is already obvious? There are very complex bugs where everything seems to work, but the behavior of what does not correspond to the behavior declared in the requirements. Therefore, the field is important and necessary to fill.

NOTE! What is obvious to you is not always obvious to the other person. Sometimes, when reporting a defect the expected result is not fully described. This is wrong and all results must be fully described.

Example 1:

Bad Good
The page is displayed correctly The login field is displayed within the «Registration» block on the main page
As mentioned earlier, sometimes the «What? Where?» principle is sufficient to describe the results. Let's consider each part separately:
  • «What?» (What happened?) Is NOT a noun, it is what happened, a kind of VERB-clarification («What is being done?» Or «What is NOT being done?»).                                            
           «The login field is displayed within the "Registration" block» – WHAT? 
  • «Where?» –  is the location in the system (application/website) where the bug was found.
           «on the main page» – WHERE?

Example 2:

Bad Good
The application works stably in the «Gallery» section The application is not frozen on the «Gallery» screen after downloading a large number of pictures
Let's consider each part separately:
  • «What?» (What happened?) Is NOT a noun, it is what happened, a kind of VERB-clarification («What is being done?» Or «What is NOT being done?»).
          «The application is not frozen» – WHAT? 
  • «Where?» –  is the location in the system (application/website) where the bug was found.
          «on the "Gallery" screen» – WHERE?
  • «When?» (After what? Due to what action? During what period?) – an action that resulted in a different result than expected. 
          «after downloading a large number of pictures» –WHEN?

Example 3:

Bad Good
The app is fully synchronized The personal data is synchronized with the server on the «Settings» screen after clicking the «Synchronize» button
Let's consider each part separately:
  • «What?» (What happened?) Is NOT a noun, it is what happened, a kind of VERB-clarification («What is being done?» Or «What is NOT being done?»).
          «The personal data is synchronized with the server» – WHAT?
  • «Where?» –  is the location in the system (application/website) where the bug was found.
          «on the "Settings" screen» – WHERE?
  • «When?» (After what? Due to what action? During what period?) – an action that resulted in a different result than expected.
           «after clicking the "Synchronize" button» – WHEN?

A notable feature of stating results is to avoid formulating expected and actual results that differ only in negative form. It isn't enough to add negation in one of the sentences.

Bad Good
Actual result: The information is matched by the «Compare products» page.  Expected result: The information is not matched by the «Compare products» page. Actual result: The information is matched by the «Compare products» page.  Expected result: The description of all products is displayed on the «Compare products» page.
Bad Good
Actual result: The error message is displayed on the registration page after filling in the «Password» field with valid data. Expected result:  The validation message is not displayed on the registration page. Actual result: The error message is displayed on the registration page after filling in the «Password» field with valid data.  Expected result: The successful registration is performed in the system after filling in the «Password» field with valid data.
Bad Good
Actual result: Registration is not performed on the site after filling in personal data.  Expected result: Registration is performed on the site after filling in personal data. Actual result: Registration is not performed on the site after filling in personal data.  Expected result: The message about successful registration is displayed on the site after filling in valid data.
Pay attention to the fact that in some bug trackers (including Mantis), there isn't a separate field for result description. That is why they must be written in the «Steps to Reproduce» field without numeration as in the steps. It is necessary to leave an empty string (indent) for visual separation of the basic bug report information blocks between steps and results. Furthermore, we should consider the fact that several results cannot be written in one bug report.
Bad Good
…
  1. Pay attention to the «Telephone number» field.
  2. Actual result: The «Telephone number» field is highlighted in green on the registration page after inputting invalid data.
  3. Expected result: The «Telephone number» field is highlighted in red or/and the error message is displayed under the field on the registration page after inputting invalid data.
 …
  1. Pay attention to the «Telephone number» field.
Actual result: The «Telephone number» field is highlighted in green on the registration page after inputting invalid data. Expected result: The «Telephone number» field is highlighted in red on the registration page after inputting invalid data.
Bad Good
Actual result: 
  1. The «Telephone number» field is highlighted in green on the registration page after inputting invalid data.
Expected result:
  1. The «Telephone number» field is highlighted in red on the registration page after inputting invalid data.
  2. The error message is displayed under the field on the registration page after inputting invalid data.
 Actual result: The «Telephone number» field is highlighted in green on the registration page after inputting invalid data. Expected result: The «Telephone number» field is highlighted in red on the registration page after inputting invalid data.
Bad Good
Steps to reproduce
  1. Open the site (the link on the main page)
...
  1. Pay attention to the «Email address» field
 Steps to reproduce
  1. Open the site (the link on the main page)
...
  1. Pay attention to the «Email address» field
Additional information Actual result: The placeholder is overlapped with the text in the «Email address» field in the footer after inputting the text. Expected result: The placeholder is not shown in the «Email address» field in the footer after inputting the text. Actual result: The placeholder is overlapped with the text in the «Email address» field in the footer after inputting the text. Expected result: The placeholder is not shown in the «Email address» field in the footer after inputting the text. Additional information This bug is also reproduced in the following browsers: Chrome 60, IE 11.41, Firefox 54.
After writing and correcting bug reports, rereading them from beginning to end is necessary. Typo, repeating words, or extra symbols might be found. It is also important to check clarity, grammar, punctuation and especially be attentive when writing reports in foreign languages. We must never use slang and reductions that aren't generally accepted. The most severe and common error during the report writing is not to comply with the «What? Where? When?» principle. If one understands that this principle facilitates our thought process, then producing reports will take less time. Therefore, it is essential to know that this principle is designed to simplify work and allow the QA engineer to spend more time on the favorite task: searching defects and inaccuracy in software.

Some more examples:

Bad Good
Tapping area is shifted in the application The taping area is shifted in the in-game inventory window after opening the promotional chest
Let's consider each part separately:
  • «What?» (What happened?) Is NOT a noun, it is what happened, a kind of VERB-clarification («What is being done?» Or «What is NOT being done?»).
          «The taping area is shifted» – WHAT?
  • «Where?» –  is the location in the system (application/website) where the bug was found.
          «in the in-game inventory window» – WHERE?
  • «When?» (After what? Due to what action? During what period?) – an action that resulted in a different result than expected. 
          «after opening the promotional chest» – WHEN?
What to do if you found a mistake?
Careers
Tags
bug bug-report game testing glossary homework assessment Lecture #1 of software testing courses Lecture #2 of software testing courses Lecture #3 of software testing courses Lecture #4 of software testing courses Lecture #5 of software testing courses Lecture #6. Software Testing: Basics and Practice Lecture #7. Software Testing: Basics and Practice lecture materials mobile testing QA terms qa tips for beginner self-training test case test design training organizational questions
UP