Bug reporting
Briefing
After finding a bug, you will most likely need to report it. Perhaps this reporting is no more than talking to a developer, but it’s also possible you’ll need to add it to a bug tracker. Whatever form the reporting takes, the basics of a good report remain the same.
One way to remember these basics is Michael Bolton’s PEW heuristic:
- Problem - describe the problem. The problem is the summary or title of the bug, so be concise, but specific.
- Example - provide an example that shows the problem: what did you do and observe? The example connects your problem description to observable behavior of the application. Without it, reproduction and/or debugging will become extremely difficult.
- Why - why is this a problem? Based on what do you consider this problem a bug? The why is the evaluation of the problem and example description. Why is what you described a bug or problem? Based on what are you saying that the behaviour you described is not as it should be?
Exercise
- Read the following blog post about an old bug in Google Calendar: http://shkspr.mobi/blog/2014/01/another-google-privacy-flaw/
- Using the heuristic write down the Problem, Example and Why of this bug.
Evaluation
Immediately after doing exercise:
- How does separating Problem, Example and Why help in writing a clear and easily understandable bug report?
- Compare the blog post with your own bug report. Which one does better on which of the three aspects?
After a few hours or days:
- Read the bug report you wrote. Focusing only on the bug report evaluate it on
- understandability
- clarity of the example
- communicating why this bug is a bug