5 Most Common Bug Writing Errors: Day #3

If you don’t have an Expected Result, you don’t have a bug! Period (or exclamation point). There is no way you could have found a bug if you didn’t have a clear expectation of what should have happened. There is simply no way.

Error #3:
Omitting the Expected Result

You can’t even test properly without a clear idea of what is supposed to happen when you run your tests. How can you?

I can make any program crash (trust me, I’ve done it) – does that mean it shouldn’t? Under what circumstances should a program remain stable and when should it crash? If you can’t tell me what is supposed to happen when you press the big, red button, then don’t tell me you have a bug if something or nothing happens!

In order to execute your testing, every test needs to state the desired outcome. Then if the functionality of the program differs from what is stated, you can log a bug. And when you do, please state what was supposed to happen.

This will save you time and frustration when you have to regress the bug and it will help the developer know what you thought should happen. It is possible that what you expected wasn’t accurate.

If that is the case, and you have stated your expectation clearly, then the documentation, test case, and program can all be updated so that everyone has a clear vision of what is, truly, supposed to happen.

Regardless of where the error is, whether in the code or in the documentation, you must always include a clear Expected Result in every bug you write. Remember: if you don’t include an Expected Result, then you haven’t written a bug.