All software produced will have bugs, it just a fact of
development, software, life. An identifier of quality software is how few bugs it ships with, an identifier of the quality of the software vendor is how quickly those bugs can be patched.
Whilst automated tests should absolutely be a part of every build pipeline, bugs can and will slip through the net.
When they do, reporting the bug with clarity, uniformity and detail is critical if the product team are to replicate and patch the issue in a timely manner.
The following I have found to be particularly useful as (a) template (s) when performing manual QA. To my mind, the contents fall into two separate camps: mandatory & detailed. The reason for the split comes down to personal preference, what makes sense in the testing environment, and the bug reporting platform that will provide some of the detail.
As an example, when reporting a bug in a more rapid moving, lean-on-resource environment reporting in JIRA, I would complete the mandatory template. If I were working for a public service broadcaster in a well resourced team and custom reporting platform, I would complete both the mandatory & detailed templates.
- Steps to Reproduce
- Expected Result
- Actual Result
- Screenshot (if applicable)
- Bug ID
- Bug Name
- Submit Date
- Operating System