A successful bug report shows the developer the difference between the expected behavior and the actual test results. It is a tester’s job to know how to write actual and expected results properly.

Asset 40 1

Following the bug summary, the actual results describe the output as initially observed by the tester, regardless of what the software is supposed to do in that development stage. 

On the other hand, expected results cover the typical behavior or output of the item currently in testing. These intended results are usually previously described in the existing specifications or requirements, so the developer and tester know what to expect when tests are run. 

While writing actual results is solely based on observation, expected results depend on the amount of documentation you have access to. 

Here are our suggestions, depending on your starting point: 

Situation 1: you do not have requirements or specifications

There will be cases when you do not have a requirement or documentation to explain why you wrote a bug. After noting the results as you observed them, you should illustrate the intended output as precisely as possible. You should describe the ideal scenario in as much detail as possible, so it’s best to avoid pointless observations such as ‘The captions should load, but they don’t.’

This situation has two possible scenarios: 

1.1 What you are presenting is just an improvement of an existing process. This time, it’s best to use the word “could“:

E. g.: Expected result: The app could make it as easy for the user to reject cookies as it is to accept them.

See more: It’s easy to accept all cookies, but how difficult is it to reject all of them?

1.2 The bug behavior is based on industry standards. This time, you need to use “should“:

E. g.: You can log in with a regular user account into the admin section of the product.

Expected result: You should not be able to log in with a regular user to the admin section of the app.

Situation 2: you do have requirements or specifications

In the previous examples, the tester writes the expected results based on their assumptions and suggestions. When we have access to requirements and specifications, the predicted output already exists in the documentation. 

In this situation, the bug report template involves presenting a link to the existing documentation followed by a screenshot, as shown in the examples below: 





Bug reports are the main form of communication between testers and developers, so try using these templates and standards to simplify the development process.