In terms of the «QA for the beginners» rubric we will look through the «What? Where? When?» principle closely.
We all know that bug reports are created in a special system called a bug tracking system.
Nowadays there are a lot of bug tracking systems, however they have one aim - to describe the essence of the defect precisely and laconically. This is the reason why they all have the similar filling principle.
When reporting a bug, it is recommended to include the following information:
- Summary;
- Description;
- Priority/Severity;
- Steps to reproduce;
- Attachment.
Writing the bug report, you may notice that some fields can be defined according to the requirements. This option depends on the type of bug tracker and the requirements for the individual project.
So, let’s consider how to properly fill in the required «Description» or «Summary» fields.
Most testers, especially beginners, face great difficulty formulating the essence of the bug. Understanding the essence of the problem, it is very important to be able to competently convey it to the programmer, who will later read the bug report.
In order to avoid confusion, as well as to save the already limited time of the project, in IT practice it was decided to unify the approach to filling this field and thus make life easier for programmers and testers who will work with bug reports.
Describing the defect, it is very important to indicate the essence of the problem, in what place of the system it happened, as well as under what circumstances. In other words: the field «Summary» is filled in on the principle «What's going on? Where is it happening? When does it happen?», answering the questions strictly in this order.
Incorrect wording can lead to misunderstandings from the developer side, who will undertake the correction of this bug. As a result, the bug will not be fixed as expected, or will not be fixed at all. Also, the developer will lose a lot of time trying to understand the essence of this problem.
Let's look at examples to consider the main problems may arise when describing a bug:
- Usage of slang. Of course, the constant communication within the team, can not but affect the work as such. However, you should not use slang words in bug reports, as the developer or another person who will read your bug report may misunderstand the problem. Moreover, familiarity and the usage of the inappropriate language (swearing, profanity etc) should also be omitted in bug reports as it is an official document too. For example:
| Incorrect | Correct |
| An exception is displayed on the adding the employee form after clicking the «Save» button | An error is displayed on the adding the employee form after clicking the «Save» button |
- The «When?» part is not always clear..Usually the action that led to a different result than expected is not clearly described. For example:
| Incorrect | Correct |
| There is an exit from the exam on the last question of the questionnaire when you click on the «Previous Answer» | The test is finished on the questionnaire page after selecting the button «Previous answer» |
- Failure to comply with the principle «What? Where? When?». The most serious and at the same time the most common mistake in the process of writing a bug report. If you understand that this principle is designed to facilitate the process of designing the topic of the bug report, then the reporting will take much less time.
The «What?» part of the principle is NOT a noun, but what happened - to some extent - is VERB-clarification («What is happening?» Or «What is NOT happening?»). This problem is especially well illustrated by the example of the English version of the report.
For example:
| Incorrect | |
| Misinformation validation error message in the registration form during incorrect filling registration form. | «Misinformation validation error message» – WHAT?
«.. in the registration form» – WHERE? «.. during incorrect filling registration form» – WHEN? |
| Сorrect | |
| Misinformation validation error message IS SHOWN in the registration form after filling the registration form with incorrect data. | «Misinformation validation error message IS SHOWN» – WHAT IS HAPPENING?
«.. in the registration form» – WHERE? «.. after filling the registration form with incorrect data» – WHEN? AFTER WHAT? AS A RESULT OF WHAT ACTION? |
- Adding a link to the site to the Summary, Description and results. The link to the site is always indicated in the first step, and in the specified attributes it is necessary to add information about the location of the bug: the name of the form, page, block.
| Incorrect | Correct |
| The color is not changed on the site http://prestashop.qatestlab.com.ua after choosing the red color option. | The color is not changed on the «Printed Summer Dress» product page after choosing the red color option. |
This principle is designed to facilitate the work. When one starts to be guided by it, then they will have more time for their favorite activity: finding bugs and errors in the software.
We recommend students of our online courses to read this information carefully, as it will be one of the reference points in the process of checking and evaluating homework.
There are cases when it is not possible to place all the necessary information to describe a lot of information in the «Summary» field. The reason may be a limit of the characters in the field. In such cases, it is recommended to formulate a description of the bug so that the essence of the bug was described as clearly as possible in the minimum amount of text. And in the «Description» field put a more detailed version of the description of the bug.
