When I was a teenager, I received guitar lessons from a small shorts-wearing man called Matt…or Lee…, maybe Tom. It doesn’t matter what his name was; this was well over a decade ago and I’m pretty sure he doesn’t rely on referral business via software testing blogs. For the sake of this article though, let’s just say his name was Antonio and move on.

Expected outcome

For about six months when I was about 15 years of age, each Tuesday at 10:20am, I would leave whatever class I had that morning (normally R.E. or Geography – an added perk) and walk across the school grounds to what can only be described as a large cupboard. In that cupboard sat Antonio, shorts and all, with two chairs, two guitars and two amplifiers (I was supposed to bring my own guitar to the sessions but regularly forgot, so he just brought a spare with him every week).

The half-hour lesson would then consist of me naming whatever song I was into at the time (probably ‘United States of Whatever’ by Liam Lynch, the biggest punk dropout song of them all in 2002), and then Antonio would try to teach me a pretty watered down version.

When it was my turn to have a go at playing the song, I would inevitably make mistakes (I am only human after all), and when I made a mistake, Antonio would tell me that I had played the wrong thing.

Where he really earned his ten quid lesson fee is that not only did he tell me that I’d played the wrong thing, he would also continue on to tell me what he was expecting me to play!

Mind blown, right?

Well, no, probably not. It would have been bizarre, awkward and down right unprofessional to tell me what I did wrong, but not tell me the expected result.

But man on the internet, what on Earth has this got to do with software testing?

Good question, person in my head!

The connection here is that as a software tester, if you log a bug without stating what you expected, you’re putting whoever is tasked with either fixing the issue, or deciding whether or not it needs to be fixed, at a massive disadvantage.

Some bugs, such as those that produce error messages in the UI, may speak for themselves, but much of the time there is a lot more ambiguity than you might think. What you expect to happen is obvious to you, because expectation is based on experience and personal bias.

To remove the ambiguity, all you need to include is a line or two explaining what you expected to happen, and maybe even why you think it should behave that way.

But testers don’t decide how the software should work; that’s for the product owner!

I have heard this several times in my career and it’s a nonsense argument. ‘Expected Outcome’ does not equal ‘Correct Outcome’, and it shouldn’t be approached as such. When I tell someone what I expect to happen, I fully expect a response such as they disagree and why, or what they would expect to happen instead.

As with a user story, a bug report should be a placeholder for a conversation, not a standalone oracle to be followed to the word. If project managers, scrum masters, developers etc., are just taking bug reports as gospel, there are bigger problems going on.

Come on now, does it really matter that much?

An ambiguous bug report can often result in a software change that from the developers point of view fixes the bug, but from the testers point of view does not. This ends up wasting everyone’s time, as it needs both fixing and retesting twice.

Surely the fact that including an expected result can minimise such waste is more than enough reason to include just a line or two in your bug reports?

Now that’s sorted out, all you have to do is sit back and work out what you’re going to do with the time and money you’ll save. I hear Antonio is available…