If you build software or data solutions you have probably encountered one or both of these situations:
- You’re trying to report a bug, but the developer doesn’t believe that there’s a problem.
- Someone is trying to report a bug to you, and you can’t tell what the problem is supposed to be.
The problem report has itself become a problem.
Fortunately, there’s a simple approach, and simple template, that can make reporting problems easier. This is the template I typically use when I’m reporting a problem and asking someone else to fix it:
Problem: Concise description of problem behavior
Steps to reproduce problem:
- First step
- Second step
- Third and subsequent steps, as necessary
Desired or expected behavior:
4. What I wanted to happen
4. What actually happened, including the full details of any error messages
That’s it – simple and easy.
It can also often be helpful to include screen shots, recordings, or other visual resources to supplement the text descriptions. If you use TechSmith Camtasia (commercial, paid) or ShareX (open source, free) or other screen recording software, it can be trivial to record and attach a video – but remember that the video does not replace the written problem report, it supplements it.
I should mention that if you’re a software developer working on a software development team, you probably have a heavier-weight process already. Follow that process. This approach is intended for more casual problem reporting – the sort of thing that you might send to someone in an email asking for help. The sort of email where if you don’t communicate clearly and effectively, the recipient ends up spending more time asking for information than he spends actually answering the question or solving the problem.
Yes, this is why I wrote this post. I hope I never need to link to it…
 Or work in a technical field, or use software…
 Because I never metaproblem I didn’t like. Yes, this sounded funnier in my head.
 If you search for “how to write good bugs” you’ll find a huge number of excellent resources that go into much more depth than this post.
3 thoughts on “Writing effective problem reports”
You are missing environment, app (if any), user data, timestamp…
Pingback: Lazy communication is theft – BI Polar