Why is "expected" before "actual" in bug templates?

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.]

Answer 5

"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)
and
"I have facts that are right (first) that I then compare it to the output (second)"

Answer 6

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.

Answer 7

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.