Reporting Bugs Effectively in 2020
Now you caught a bug in the software and you need to report it effectively and professionally. There are a few things you need to consider as a guideline when reporting a bug.
You should always have the mindset of a good communicator, The clearer the communication result of an effective bug the easy understand and reproduced. The art of being precise will require an understanding to all important information that you need to include in your report.
There are many tools in the industry that could help you craft a great bug report, most of them are designed to allow you to track the life cycle of the bug from the creation phase to the verification.
A descriptive title is your start point, choosing a descriptive title not only help developers to understand the nature of the bug but it also help all the stockholders of the bug to search or filter it. The title should include the most important keywords.
The type of bug must be included somewhere in the body of your report, as a good practice i always include it prior to the title, this help a great deal when categorizing you set of bugs into different pockets. In addition, i would concatenate the project name to the title, this will provide more insight to the bug and make it easy to allocate by projects.
So, to summarize your mega title should eventually look like this:
[Project Name]:[Bug Type]:[Bug title]
Then you need to incorporate a summery of the bug to elaborate any details that could be essential to identify the problem. You should keep your precision and avoid any irrelevant information or verbiage, I can’t emphasize enough one the importance of articulating your summery in a clear way of communication.
After the summery you need to specify a section to define the expected result and compare it with the current behavior, most of the developer will use this section as a preview to your bug or to identify the scoop they need to work inside the project.
Then, you need to list all your configuration, such as:
Testing environments: The name of the internal testing environment .
Operating system: [name and version] for instance, iOS 13 or macOS Catalina, Safari v 00.0.0 (00000.00.0.0) or chrome 00.0.0000.00.
Built ID: The unique identifier that determine which built inside the built trains you are testing on.
Any other configurations or settings you think its necessary for reproducing the bug should be mentioned in this section.
Then you should list the step to reproduce, describing the path you need to take to get to place where the bug occurs, This very essential for all stages of the bug life cycle, it help developers reproduce the bug and investigate further more, and help you to verify the fix after it get implemented. You need to list any data used during the testing stage such as accounts, phone numbers, credit cards.
Congratulation, you just logged your first effective bug report, You may need to attached any files or screenshots that help visualizing the issue, Some companies have their own debugging track log that allow the developers to have a real time debugging log where they can get into the root cause of the bug more quickly.
The last step is to assign the bug the proper assignee, setting the state of the bug to be unfixed and you need to choose the proper project category.
If you work the Right to left design or languages, or you know someone who do, then buying my book will be great way to gain RTL end to end knowledge and support me to keep writing book at the same time.
https://www.amazon.com/RTL-Foundations-Sam-Shamsan/dp/1656300087
