Bug Reporting Software Quality Assurance

🔍 Finding a bug is one thing, but documenting it is just as important.

Good bug reporting is needed to help the developer easier to understand our bugs report, so that will make our work quick and save much time for both Engineer and QA.

🍳 Preparations

Collect all required data

Have access to design file

Mastering the Product Requirement Document (PRD)

Know root cause of the bugs

Know your main and support team

🎯 Bugs Priority and Severity

Bugs priority

Priority is how quickly a bug should be fixed and eradicated from the website. Bug priority indicates the sense of urgency in dealing with a bug on our website.

P0 - "Must-now" aka "Critical"

P1 – "Must-have" aka "Major"

P2 – "Important to have" aka "Minor"

P3 – "Nice to have" aka "Low"

Bugs severity

Bug severity defines how serious a bug is and how badly it affects functionality.

Critical

Major

Minor

Low

Notes:

Development bug: If QA found a critical bug, it should be set as [P0] on the bug development ticket.

Production bug: Immediately raise on the related channel and mention stakeholder, please provide the isolated case and proof (log, video, etc) and create a Production bug ticket.

🎼 Bug title

It must be very detailed and intuitive, so the developer can have an idea of what the bug is just by reading the title – usually, the title is a short summary of the bug's description and reflected the bug itself.

📝 Bug descriptions

The bug's description must have the following structure:

Steps to reproduce the bug

Actual result

Expected result

🌲 Environment

If your ticket management product have an "Environment" placeholder, QA should write down the following information:

Device

Operating System (OS)

Firmware

Account used and password

Testing environment

Testing app version

Connection type (if applicable)

🍿 Bug evidence

Bug evidence in software quality assurance is information gathered about a bug or defect in software during testing. It helps identify the cause of the bug and determine a solution for fixing it, in order to improve the quality of the software.

Any pertinent screenshots, videos, or log files should be attached.

Bug reports usually require both a video and a screenshot, depending on the nature of the issue.

If the issue requires steps to trigger the bug, then a video is required.

If the bug is, say, a minor UI issue that is always present, then a screenshot will suffice.

Logs are also required no matter the issue.

For application crashes, it requires both system logs and crashes log dumps, otherwise, developers are left searching for a needle in a haystack, and this saves them valuable time.

Make sure you give the right attachment. Not every bug need video, sometimes it's better to put it as an image.

🎉 Conclusion

Mandatory information QA needs to include:

Where: The location of the bug.

When & How: Specify the condition, how to make the bug easily reproduced.

What: The bug, itself. What happened to the AUT. (Application under test).

Reproduce rate: How many tries you did/how many tries the bug actually happen?.

Consequence: If the bug happen, what is the impact to the AUT & User’s experience?.

Workaround: Any way for the bug, so it will not happen? Or if the bug happen, can it be restored to the normal condition?.

Version: Occurs in version or Fix in version.

Linked issues: if any

I hope this repository is helpful for you! If you have any other questions, feel free to open an issue or submit a pull request.