Bug reports are actually easy to write, yet so many times they are written without the important information. If you check those 9 points and provide the information where it makes sense, you help the person trying to fix the bug a lot.

Note that I am leaving out the reporter and date here, since that is usually implicitly given in any digital reporting format. This makes the following checklist also a bit smaller.

  1. Time of occurrence: The more precise the time is specified the better. Be clear also on the time zone.
  2. How to reproduce: Describe the steps to reproduce the bug or what steps lead to the bug.
  3. Expected behavior: What behavior did you expect from the system?
  4. Actual behavior: What behavior did you observe with the system instead?
  5. Component: What product or service was failing?
  6. Version: What version was failing?
  7. Frequency: How often does the defect appear or is expected to appear?
  8. Repercussions: What ripple effects does the defect have to the user base?
  9. Logs: Stored evidence of the system state when the issue was misbehaving.