Effective Bug Reporting

21 / Jun / 2016 by Ubaid Ahmed 0 comments

Effective Bug Reporting is a skill that every tester should possess because it is as important as finding bugs. If developers cannot reproduce the bugs reported by testers, then how are they going to fix it?
Anyone can report a bug, but not everyone can do bug reporting effectively. A high-quality bug report is made up of following ingredients:

1. Bug Title : A descriptive title is a MUST. Bug title should be such that it gives a sense of understanding what the bug is and should not be vague or generic. Instead of “Application is crashing”, “Application is crashing while updating profile” is more meaningful. To make it more explanatory, “Android | QA – Application is crashing while updating profile”. Now one can easily understand that this bug is related to Android environment, QA release and is occurring when a user tries to update the profile.

BugTitle

2. Priority : Priority of the bug means what business impact that particular bug is having. A bug might be a trivial one from a functional perspective but might have a major impact on the business. The company logo is missing, website text is so small that it is not readable, different font type or size within the same paragraph on the homepage, etc. are some of the examples of bugs that do not have any impact on the functionality but might leave a scar on organisation’s reputation if not fixed.

Priority

3. Component/Module : Different teams follow different processes. Ideally, when a tester finds a bug, then it is assigned to a testing SPOC (usually a Test Lead). It is further assigned to a development SPOC (usually a Development Lead), and then it is further assigned to the concerned developer for fixing. Mentioning about the module or component will help the person further assign the bug to the correct person.

Component

4. Assignee : Sometimes testers log the bug in a hurry and misses to assign it to the concerned person. ‘Missing Assignee’ may lead to loss of that bug since no one will have the knowledge of that bug being raised.

Assignee

5. Platform : Different teams will be working on Android, iOS, Windows, and Mac version of your application. Mentioning about the platform will help the testing SPOC to assign the bug to the correct team.

Platform

6. Description : Describe the bug in detail. Try to explain what exactly is happening. Don’t make it a long description, but also don’t miss to provide any crucial information. It should be clear and crisp, and apart from description it should also consist of the following:
  – Steps to reproduce : There might be certain bugs where this can be skipped, but apart from that it is a must to mention steps to reproduce. If developers are not able to reproduce the bug, then it will be very difficult for them to fix it.
  – System information : Usually there is a to-and-fro communication between developers and testers because things work perfectly well on developer’s machine and they mark it as invalid whereas all hell breaks loose on the tester’s machine and they again reopen it. To avoid this situation, provide system information in your bug report such as OS (Windows, Linux, Mac, Android, iOS), Browser along with the version (Mozilla, IE, Chrome, Safari, Opera), etc.
  – Expected result : This is the result or the outcome of following the steps mentioned in the description.
  – Actual result : This is the result because of which the bug was logged. It is something which is not matching with the expected behaviour.
  – User credentials : If needed, provide the credentials.

Description

7. Screenshot : A best practice would be to take a screenshot as and when something unexpected happens. Certain bugs are non-frequent in nature. You cannot reproduce such issues every time. They seem just to appear out of nowhere. In such a situation, screenshots will come to rescue.

Screenshot

8. Severity : Severity of the bug means what impact the bug is having from the functionality point of view. If a user is not able to log in, or the user is not able to unlike a post that they liked more than three years ago are two different issues that have different severity. Not able to log in is a blocker because a user cannot proceed without login. However if a user is not able to unlike a post which they liked more than three years ago, then it is something which will be placed at the bottom of the list for fixing.

Severity

A good quality bug report will increase the productivity of the entire team as it will help developers in understanding the bug in a better manner and do their analysis and fixing accordingly. Keep logging more bugs! And effectively!

FOUND THIS USEFUL? SHARE IT

Leave a Reply

Your email address will not be published. Required fields are marked *