In the teams I work in, I expect the follwing when it comes to bug reporting:
- Clear description of the bug
- Clear, defined steps to reproduce
- Relevant url, browser and related info which could be, but not limited to entry details, screenshots, categories of user, brand or configuration which has impact.
What I will provide once I have investigated the bug:
- Brief description of replication steps and process.
- Relevant findings and further information for future reference. (Or confirmation if something is not clear)
- Description of resolution or next steps.
- Once complete, a resolution/confirmation of closure.
The above should all be commented on or provided on the bug report, be it in ALM or Jira, so that:
- Anyone who wants to know the status can see what has been done, what has been found and what state the bug is in.
- Anyone should be able to pick up where you left and retrace your steps/line of thinking.
- You are sharing your knowledge - several days, weeks or months down the line, you cannot rely on yourself (or anyone else) to accurately remember exactly what happened when and how. The detail does not need to be exhaustive but it must be descriptive enough to ignite your recollection or to orient someone else.
Much like documentation, good bug history and knowledge needs to be built up over time. DRY (Don't repeat yourself) does not only apply to the code you write, but also to your personal as well as your team's collective knowledge and memory of what has gone wrong, what mistakes were made on how these can be improved upon in future.