5 Keys to a Bulletproof Bug:
Day #5

The Expected Result is where you state, without ambiguity, what you expected to happen. Very often this is just a way to clearly state the opposite outcome than what you witnessed (the Result). Whether the Expected Result is simple or complex, you must articulate it with as much clarity as you have the rest of the bug.

Key #5: Expected Result

Remember that the test you were running had a pre-defined outcome – this is the Expected Result. This outcome was expected for a reason; either because the link you clicked read “Help” and so you expected the Help Menu to open, or you changed the armor on your character and expected to see a change in your defense rating. Whatever you did, there was an expectation. This is your Expected Result.

If there is a document that you can cite to point the reader to the reason for your expectation, cite it. Tell them which document, where in the document, and quote it if at all possible.

When you are writing your bugs, be sure to give as much attention to this Key, the Expected Result, as you give to the other Keys. If you do not include an Expected Result, you don’t have a bug.

This seems simple, but I have encountered many testers who do not spend the necessary effort when writing this part of their bug. They write “verify above result” or “this behavior seems wrong”. That is not good enough. In this Key, you must state what should have happened and, if at all possible, why it should have happened.

Although I will delve more deeply into this Key in the upcoming free course 5 Most Common Bug Writing Errors, here is a glimpse into one of the reasons that the Expected Result is so important: Re-testing the bug.

When a bug has been fixed, QA must perform a type of testing known as Regression Testing. In this scenario (commonly known as “Regressing a bug”), you will be testing to see if the applied fix actually worked.

Now think about that. If you are testing the fix, how do you know if the fix was successful? You would know because the current behavior would match your test’s expected outcome – it would match your Expected Result.

If you have not identified and described a clear Expected Result in your bug, how can you validate the fix? Here's a tip: YOU CAN’T!

So, let me repeat: If you don’t write an Expected Result, you don’t have a bug. Does that make sense?

I am guessing that you get the point. You are here to add value and quality to the project – this is just another detail at which you have a chance to excel.

Here is an example of poorly written Expected Results and well written Expected Results:

Bad Expected Results:
Program should keep running
– OR –
Program should not crash

Good Expected Results:
Help Menu should open and the program should continue running
– OR –
FAQ page should open (per requirement 4.1.2 in Technical Specification Doc 6.1a, page 32, paragraph 4)

Remember to clearly state what should have happened so that there is no question as to whether or not the behavior you encountered was a bug. A good Expected Result will leave the reader knowing that you have done your job with proper attention to detail.

And there you have it! Simple really. The 5 Keys that you need in order to write a Bulletproof bug!

I know that it seems like a lot of detail to keep track of at first, and might even seem a little intimidating, but don’t fret. Just review the sample bugs that you downloaded from our Forms & Templates page to get an idea of what a Bulletproof Bug looks like.

Then when you need to write a bug, just refer to the sample bugs to jog your memory. Use the included Bug Template.

When you write your bugs, just make them match the samples. You will get the hang of this in no time, it just takes practice. Strive to practice writing your bugs as perfectly as possible and before you know it, you will be writing Bulletproof Bugs all the time, every time!

The 5 Keys to a Bulletproof Bug

1. Descriptions (brief and expanded)
2. Reproducibility (X-out-of-Y)
3. Steps
4. Result
5. Expected Result

You will have mastered the fine art of bug writing and can help others improve their skills at it too! You have the knowledge, now put it to work!

The winds and waves are always on the side of the ablest navigators.
~Edward Gibbson

Congratulations!