Chapter 2: How to write useful “Actual and Expected results” details in your bug report
On WE ARE TESTERS, actual and expected results are the sections where you describe the bug you’ve experienced and what the normal behaviour of the bug is. Let’s be honest, most of the time, nobody knows what should be written in these categories. Consequently, the same information is often repeated in the summary, as well as in the actual results and expected results sections.
In the previous chapter, you learnt how to write a flawless summary of your bug report. In this chapter, you will learn how to provide useful additional information in the sections Actual Results and Expected Results.
Definition
Actual Results
You have to describe what you see on the website or the mobile app = the bug itself.
Expected Results
You have to describe what you consider the normal behaviour of the bug to be = the customer’s specification/web standards/your analysis.
Don’t
Summary: wrong currency
Actual results : wrong currency is used (pounds)
Expected results : use the right currency (euros)
The topic of the bug is clear: it will be about the currency
But where? Why does this tester consider it is a wrong currency? Is it an isolated case? global problem over the website?
Moreover in the example above the 3 fields indicated the same information which is useless and it would have been more interesting to expand on each piece of information.
Do
Summary: [Product list] mixed currencies for the products.
Actual results: in the product list, on the first page, at least 5 products have a different currency (pounds) than the others (euros).
Expected results: As the location and currency are selected in the header (France- EUR), products presented in Euros would be expected.
In the example above, Summary / Actual Results / Expected Results provide additional information.
This a good way to get your bug report approved by a mission manager on WE ARE TESTERS. This will also help you get your bug report classified as above regular or amazing and consequently increase your wage.
Global advice
1. Write a full (and normal) sentence
With a subject, a verb, an object and correct punctuation. You should separate your sentence into several ones if it is long and complex.
2. Avoid to use the first person in your sentences.
You will be more neutral when writing the bug report.
3. Don’t attempt to the developer what he has to change in the code.
Instead make sure that what you’ve described, in the actual and expected results, is the exact behaviour of the bug. If you lead the developer in the wrong direction, it will take much longer to fix the bug.
Actual Results
The keyword about this field is : FACTUAL
The main rule is to describe the bug without introducing your opinion about the bug.
In the example above, saying “wrong currency” is a personal opinion.
“A currency not matching my location” or “mixed currency on the same page” is more objective. It is a statement of fact!
To help you write a good “actual results”, we suggest that you remove these following adjectives from the description. You will see how easy it then becomes to describe the bug: bad, wrong, inappropriate, misleading, perfect, false, funny, improper, defective, properly, expected, faulty…
Expected results
To describe the expected results you can refer to 3 sources (most important first):
- The customer’s specification: this is your bible (if you have it)! Even if you think the customer’s choice is weird (your opinion), don’t describe a different expected behaviour than the one presented in the customer’s specification. If you disagree with the customer, write a suggestion instead and explain why you think it is more user-friendly.
- Web standards: refer to the web standards when you don’t have the customer’s specification. Web standards means “widely spread behaviour across websites”. For example, the navigation bar is commonly at the top or on the left side. A search bar is commonly a text field with a placeholder and a magnifying glass icon at the right border. In a list, the entries are generally sorted by alphabetical order. These are not unchanging rules. They are just commonly known behaviours. Over time, they have become a user-friendly behaviours.
- Your own analysis: at last, sometimes describing the expected behaviour equals to writing the common sense. For example, you have just set a filter, you would expect it to change the related list. In these cases, you don’t need a specification to write what was the expected result.
Don’t forget to refer to your source in your “expected results”.
Examples
Graphical bug:
Don’t
summary: the image is damaged
actual results: the image looks bad
expected results: the image should look good
Do
section: header menu
summary: [profile picture] picture is vertically flattened
actual results: the proportion of the profile picture seems to be altered vertically. The uploaded picture’s size was 450x450px. On profile page, the preview is ok but on the header menu, the picture is flattened.
expected results: The ratio of the profile picture should be maintained on any area of the website. If the picture doesn’t match the template, usually either it is automatically centered or cropped, or the users are asked to center it, or they are forced to upload a picture with the right ratio.
Functional bug:
Don’t
summary: can’t see a video
actual results: the video doesn’t start
expected results: the video starts
Do:
summary: [Video streaming] endless buffering whatever the network speed
actual results: when clicking to play the video, the buffering has started and never ended (still buffering after approx. 10min). The test was done with good network speed (105 Mbps) and videos from other websites were successfully launched. The test was also done on a mobile phone with a lower speed and got the same result.
expected results: based on web standards, buffering should be shorter. The resolution of the video should be adapted according the network speed to allow that.
< previous chapter: summary — — — — — — — — next chapter: categories>
