I've seen a lot of bug templates all having Expected Result before Actual Result. To me, this does not make sense because it breaks the flow of reading through the bug/page.

Usually when you read (anything, not just a bug) you'd go:

top > bottom

and not

top > middle > bottom > middle again > almost bottom

I asked several coworkers why they write bugs in that way the general answer I got was that "that's how it was in a bug template" / "that how I was told to write it"

Can someone explain why those are reversed in bug templates and what are the benefits of having the expected before the actual?

  • Is there any value in having Actual before Expected? Like, what tangible difference does it make? I agree with you (Actual should be before Expected, because that's how you tell a story), but I don't understand why one way would necessarily better than the other. Can you just switch them in the template?
    – dvniel
    May 17, 2019 at 10:05
  • for sure i can switch them in the template i use but by question was mainly to make sure that i am not missing anything on the bigger picture.. as i always used Actual before Expected... May 17, 2019 at 10:22

7 Answers 7


The way I see it putting "Expected" before "Actual" eliminates bias.

Usually your brain "sticks" to the first things it hears about (that's what Anchoring is about, for example when bargaining the first side to bid will be closer to the final bid) so if you start with the Actual it will be more difficult to see the discrepancies between it and the Expected.

I don't understand why do you need to read bottom up, at the end of the text you are supposed to remember the two items anyway

  • I don't think it has anything to do with anchoring .. as i am not writing bugs to change someones mind... I write bugs to explain what is happening.. so when you read normally (top to bottom) once i am done with the steps i should see what is the current app behaviour, right? - but if i read a bug written following a template, when i am done with the steps expected is first and i have to go to the bottom of the page to see what are the result is. May 17, 2019 at 9:37
  • @JustATester Yes your way of reading output before expected is ok. It's just not the only viewpoint that works. For some people seeing"what I expect" first, before seeing the actual output is more logical. It really is not a right/wrong good/bad thing though, it's just two ways of approaching this problem. The bigger issue is when different approaches are used for different tests. That inconsistency can get quite confusing ! May 18, 2019 at 9:57
  • btw @JustATester the mind I believe Rsf is talking about changing is the mind of the tester, i.e. yours. A good tester needs that ability. This is not a slight on you. We all need that including me. May 18, 2019 at 9:59

Surely it makes logical sense to put the expected value first as it's the first known value. I will talk about the concept of expectation, an expectation comes logically first. Look at the definition of expectation from Google:

"a strong belief that something will happen or be the case." will happen.

i.e. it will happen after the expectation is set.

  • but if you put it like this then definition of result is: a thing that is caused or produced by something else; a consequence or outcome. so after the steps i should see the consequence of following those steps May 17, 2019 at 9:44
  • A result is a consequence of the requirement in this context. because expectations are generated from some basis ...right. May 17, 2019 at 9:54
  • but the expectation is generated by the design/story/documentation May 17, 2019 at 9:59
  • Yes... but how these "design/story/documentation" generated ...from some requirement only. May 17, 2019 at 10:05

I agree that Actual should come before Expected. This how I’ve written for bugs for nearly 10 years.

It’s also how directions and stories are told. The story, in this case, is “how to reproduce a bug” and the end of the story is “here is the bug”. In other words, what you Actually find, followed by what you Expected. The difference between Actual and Expected is the bug. Writing bugs in this manner, Actual before Expected, allows everyone on the team to quickly understand how the bug manifests, what the bug is, how it differs from the expectation. Having Expected first breaks up the flow of the bug.


Biggest reason I've ever seen for this ordering is Data Reuse:

Putting the 'Boiler Plate Stuff' first, followed by 'the Variables', offers a slightly more consistent workflow.

Find an issue in Screen X for when you press button Y, look up past ticket from when button Y did something weird a few builds back, clone it, clear the Observed/Actual Results, and replace with the new content before filing the ticket/report.

Anyone working with Button Y's bugs becomes familiar with the ticket layout, and visual spacing on the ticket remains consistent.

  • At least until a change in expected behaviour of Button Y is introduced, in which case the break in consistency adds a subtle highlight to the change.

It is horribly minor, and in the end the ordering standards for a given project aren't actually all that important:

  • Environment/Build/Actual/Expected
  • Actual/Expected/Build/Environment
  • Expected/Actual/Environment/Build
  • etc...

Are all perfectly valid orderings on Tickets/Reports that I've used on projects, and they all work just fine. The only thing you want to avoid is constantly changing how you order things, or having different people order things different.

If everyone else is already using the first order from the above list, and you have a burning desire to use something else... Then just use the existing order anyway. At least until you can convince the team that your way is better. [And that is often not a fight worth having.]


"Expected" coming first is just an implementation of the concept of:

Well I know what I actually want, that is the only known and certain thing and is the first 'fact' in my approach.
Then I have my experiment which produces a second 'fact'. I then compare the first fact to the second fact. That is how someone puts 'expected' first in my experience. It emphasize the correct answer

The other approach is similar but says "I have information and I know it is wrong" (first)
"I have facts that are right (first) that I then compare it to the output (second)"


Personally I always first write steps-to-reproduce, the actual result, and then the expected. I think this flow is most logical from a reading perspective. But as I was thinking about this question I came up with a reason why I think maybe the other way around might be better in some cases.

Possible reason to start with expected:

If you start with the expected result you could come to the insight that you don't know what to expect, or that the expected is actually the same as the actual.

While if you start writing with the actual and the above is true you just wasted time writing the actual results.

So starting with the expected might save you a little bit of time once in a while or gets you to start with gathering requirements first and understanding the issues better and do more research before reporting, before writing the full defect report first.


Experienced team member (dev/qa) As an experienced team member, one can definitely say the 'Actual Result' should be mentioned before 'Expected Result. Reasons being - I'm already aware of the functionality/ workflow /user flow for that feature. So while going through the bug report, after reading the STRs (Steps to replicate) my mind already figures out the expected result for that scenario. Hence I would be more interested to know the 'Actual Result' than 'Expected Result'.

New team member (dev/qa) If I'm new to the product, I wouldn't know the complete functionality/ workflow/ user flow, so while going through the STRs in a way I'm trying to understand the feature and hence I am more interested in 'Expected Result' than 'Actual Result'.

Why most of the companies prefer 'Expected Result' to be mentioned before 'Actual Result' Companies who hire freshers, they setup their processes in such a way that users with any level of experience can understand the flow properly. Hence while training freshers emphasize more on 'Expected Result' over 'Actual Result' as a process. And once these people move on from one org to another, they continue to use the same process which they have learned as fresher.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.