What exactly is the role of a tester? I recently had a discussion with my team and we came up with several answers:
- Should conduct tests
- Should conduct thorough tests
- Should not overlook any bugs
- Should have a comprehensive understanding of the application
- Should attempt to break the application
However, I believe there is one quality that sets apart a truly exceptional tester. Everyone was curious to know “how.”
Recommended IPTV Service Providers
- IPTVGREAT – Rating 4.8/5 ( 600+ Reviews )
- IPTVRESALE – Rating 5/5 ( 200+ Reviews )
- IPTVGANG – Rating 4.7/5 ( 1200+ Reviews )
- IPTVUNLOCK – Rating 5/5 ( 65 Reviews )
- IPTVFOLLOW -Rating 5/5 ( 48 Reviews )
- IPTVTOPS – Rating 5/5 ( 43 Reviews )
What happens when you report a bug? I presented another thought for discussion.
- The developer resolves it
- Sometimes the developer does not resolve it
- Sometimes the developer delays fixing the issue
- Sometimes the issue is marked as “Not Reproducible”
Also read => Complete defect life cycle
Good, but why does the developer choose not to resolve or delay fixing, or even mark the issue as “Not Reproducible?”
After a pause, the most interesting phase of our brainstorming session began – the discussion.
Here are some excerpts from our discussion:
As testers, our primary responsibility is to test the application or product and report any issues. But our responsibility does not end there. In fact, that’s when our real duty begins. It’s crucial to understand why your bugs get rejected or marked as “not reproducible,” and how you react to it.
Bug reporting and tracking is a skill, an intricate skill that can elevate the product’s quality and earn the client’s trust. Regardless of your position in the hierarchy, if you are involved in software testing, it is essential to master the art of bug reporting. Bug reporting is not just a document; it is a summary report that highlights what is going wrong, how it is going wrong, and where it is going wrong. The bug report is a representation of issues within an application, and how you present it can determine the future of that bug.
You may be familiar with the necessary information that should be included in a bug report, but what about the overall bug report? Even if you include all the necessary fields, you may still struggle to create a good bug report.
Based on my experience, I have compiled a list of points to consider when reporting a bug. I have provided an example for each point to enhance understanding.
Example:
Let’s consider an e-commerce website that sells car parts and accessories. Below, I have described some relevant issues along with the corresponding “should not be” and “should be” columns for each point.
Take a look:
#1. Review the bug you reported and ask yourself – is it understandable?
Not understandable | Understandable |
---|---|
Title: Application is very slow | Title: Performance of the application is poor on specific pages. |
Steps to Reproduce: Whenever the user tries to make a purchase, the response is slow and sometimes the required action cannot be completed. | Steps to Reproduce: Some specific pages of the application, such as Car models, new arrivals, and accessories, take more than 15 seconds to load. |
#2. Provide proximity of reproducibility to save time and effort
Should not be | Should be |
---|---|
Title: Application crashes on payment page | Title: Application consistently crashes on the payment page for a specific selection |
Steps to Reproduce: Whenever the user selects a payment option, the application crashes | Steps to Reproduce: Whenever the user selects the XYZ bank credit card as the payment option, the application crashes. |
#3. Understand that bugs are project-related, not personal
Should not be | Should be |
---|---|
Title: Application not working properly | Title: Application does not respond when the user selects a specific inventory to add to the cart. |
Steps to Reproduce: As I have already mentioned and shown, the application is not working on many pages and displays error pages. Please resolve this issue as soon as possible. | Steps to Reproduce: When the user selects a specific part to add to the shopping cart, the application does not respond. This issue hinders the testing of the application flow. Please consider it a top priority. |
#4. Stick to one bug, one issue:
Should not be | Should be |
---|---|
Title: Certain parts are not selectable and the application crashes if certain other parts are selected | Title 1: Certain parts on the Car Accessories page are not selectable |
Steps to Reproduce: On the Car Accessories page, the following parts are not selectable: Mobile holder Car backseat pockets Car perfumes |
|
Steps to Reproduce: On the Car Accessories page, some parts are not selectable. Additionally, when the user selects grey seat covers or rich brown seat covers, the application crashes. | Title 2: The application crashes when selecting specific types of seat covers on the Car Accessories page |
Steps to Reproduce: On the Car Accessories page, the application crashes when the following parts are selected: Grey seat covers Rich brown seat covers |
#5. Provide a possible reason, if known:
Should not be | Should be |
---|---|
Title: After canceling the purchase of an accessory from the cart, if selected again, the price to be paid shows double the original price | Title: After canceling the purchase of an accessory from the cart, if selected again, the price to be paid shows double the original price |
Steps to Reproduce: On the Car Accessories page, select any item and add it to the cart. Now delete it from the cart and reselect it and add it to the cart. | Steps to Reproduce: On the Car Accessories page, select any item and add it to the cart. Now delete it from the cart and reselect it and add it to the cart.
Note: Upon inspecting the database, I found that when a user deletes an item from the cart, the specific entry is not deleted from the database. As a result, when the user selects the same item again, the price appears as double the original price. This may be the possible reason for the issue. |
I hope the above examples clarify the points I wanted to convey. Feel free to share your views and opinions on this post.
About the Author: This post was written by Bhumika Mehta, a member of the STH team. She is a project lead with over 10 years of experience in software testing. She values good ideas, innovation, and taking risks, but she dislikes monotonous work, people, and environments.
Happy testing, as always. 🙂