I am sure most programmers and me know by now the 101 rule: Maintain a bug database if you develop software. This post is not about this. I assume you know and practice it already. I want to talk about what a bug report should include and I encourage you to train the people who will report bugs to follow this advice.
Every bug report should include the following information:
- Steps
- Result
- Expected
- Bypass
- Information
Steps
Here we write the steps up to the point the bug occurs. We want clear steps that reproduce the bug each time we follow them. This is important because without these steps it is difficult to reproduce the bug, and it makes the programmer want to avoid dealing with the bug.
Result
What happened? What was the behavior with think is a bug?
Expected
What behavior did we expect? Here, we explain what the correct behavior is in our opinion. This helps the programmer compare his model with the user model. These two should be the same in successful applications.
Bypass
Are there any actions that can bypass the problem? This helps the programmer understand the nature of the problem and also the severity of the problem. For example, he might choose to work on a bug that is severe and doesn’t get bypassed, instead of working on a bug that can be bypassed.
Information
Any information that can help and doesn’t fit to one of the sections above. For example, one might mention the version of the application, what he thinks might be the cause of the bug etc.
Let me give you a very simple boring example:
Lets say we develop an application that adds two numbers:
1 + 1 = 2
This is the result everyone expects, but you make some change in the code in order to make it faster and of course you introduce a new bug. This bug is discovered by a tester in your testing department and his report goes like that:
Steps
- Run application
- Enter 1 for the first number
- Enter 1 for the second number
- Press button “Add them”
Result
0
Expected
2
Bypass
None
Information
I think the last work on that area was done during the night by programmer Mr. “Haven’t slept for two days”, and maybe it is total crap.
Nowadays it is quite cool for your application to be able to gather most of the information automatically and also include a lot more technical low level data that can help debugging it, and then automatically send the data using the Internet to your bug tracking application. This is fine if your scenario permits it, but for the rest of the applications that don’t always get the chance to be near the Internet, you can consider the old fashioned way of reporting a bug.