And here we have a example of a bug report form and my intentions for each area. It looks like a lot of stuff and maybe redundant but you just clip what you don’t have and give ‘er all you got.
Title of Your Bug Report Should Sum Up The Whole Thing
- This is where you expand your issue in more of a paragraph form.
Steps to reproduce
- you open the app
- you do a thing
- you log it
- you number these steps for clarity
- what you were hoping, wishing, dreaming and expecting so see as the result of your above numbered actions
- what you observed after the steps that was not in line with your expectations
This list should cover what you found when attempting to reproduce
This is the proposed severity based on your understanding of the issue, prepare to be overrode by your favorite Designer, Developer, Product Owner or Project Manager
- If this is a customer-facing issue, ensure support has a way around things. Being able to see a path around may help the bug report reviewer figure out the source and severity.
- Anything outside of the Expected section above that you feel would resolve the issue.
Documentation / External References
- This is where things like, the HIG, WikiPedia, Design Patterns, Specs or the like can be noted if you think it might be helpful to move the case forward.
Existing Cases / Internal References
- Tangentially related bugs you have already filed or documents and requirements from the client or whatever occurs to you.
- In your repro you may have checked a prior build or release, branch or commit, this can be enormously helpful to your resolver.
- Hardware – be explicit
- OS – be explicit, harder
- Build Info – down to the SHA or Jenkins link or whathaveyou
- Pertinent Settings – network issues, proxies, OS settings, etc
- Sample files, mock data, test accounts, the build, screenshots, videos or whatever source you have to reproduce the issue
- The personal appeal, confessions of known biases, love notes and curious musings.