The common problem that testers face in their day-to-day life is getting consent on the bug report.
Let’s see how to handle bugs with advocacy!
Advocating for anything is not a one-way process. It’s a two-way process.
The testers who identify the bugs in a product are the ones who need to advocate the same. They must take a stand and voice their opinion. This is where a tester’s communication skill plays a major role. So It’s always preferable for Test engineers to be good at communication, both verbal and written.
“Any quality gap we identify is a bug“
Bug advocacy is not about pointing fingers or criticizing mistakes. Moreover, it’s reporting the bug in a sound way to ensure that the readers can understand the full impact of the reported issue. It’s not the responsibility of the testers to make sure all reported bugs are fixed.
The Reputation of a tester depends on the quality of bugs they report. It depends on how effectively a tester explains the software has failed to meet the requirements.
In general, a developer depends on the tester’s bug report to understand the product defect. So a tester must take time to compile the bug reports soundly to make his/her bug bring value to the organization’s needs.
“How well the tester research and writes the report will often decide the probability that the bug will be fixed.”
An effective sales tool for bug reporting:
Design a bug report in such a way to convince organizations to provide valuable resources for the improvement in product quality after the bug’s fix to resolve the occurring issue which would in turn contribute to the quality of the organisation’s software.
Testers may not be involved in all the discussions that happen regarding the issue at hand. So whenever a bug is reported, there is a particular amount of effort that the development teams have to invest in getting it fixed. So the primary instrument is the bug report which would persuade the developers to fix the same irrespective of the presence of the tester.
Make it valuable
Design your bug reports with Video recordings, Screenshots, Device Logs and Actual and Expected results, and distinctly explain how it impacts the end-users.
Because the bug reports serve many people, it doesn’t stop with just the developers who fix it. So have the product managers/client success team in a loop for all the open issues/limitations of the system to provide post-deployment support for the end-users after a major release.
|Bug ID||Summary||Bug Description||Steps to reproduce||Actual Result||Expected Result||Environment|
Treat it confidential
Anyone who is not convinced about the quality of the product must be able to report the bugs. As testers, we must not stand in the way of communication of the bugs reported by the stakeholders, but we must facilitate it. So the primary objective of reporting bugs is to improve the quality of the product. Also, the bugs tracking data we maintain should be confidential(within the organization) as to how we treat our source code.
Never judge the bug
- There is consent among the management team that the product is stable when there is no issue in the initial phase of testing. Therefore, Understand the risk of reporting bugs late.
- Never assume all functionality bugs are reported. Add observations to the existing bugs report to strengthen it.
- Discover the corner cases, by efficiently testing with extreme values, because if our system can survive those extreme values, obviously it can survive lesser values.
Don’t underestimate the bug!
- Small typo
- UI inconsistencies
- Error messages which are not user friendly
All those things will impact the reputation of the product.
Customer satisfaction decreases when bugs count increases, no matter what the priority is.
“ Stop tolerating the minor bugs, when we start tolerating the minor bugs, there lies the product failure.”
Do follow-up testing,
- To find more serious symptoms, which will make for a more detailed report.
- To demonstrate that the problem will affect most of the customers.
Making use of user action recording tools which will help in identifying the exact steps performed for reproducing sporadic issues.
Create separate bug tickets for each bugs, don’t add multiple bugs in one bug report. Because adding multiple bugs in same report will mislead during development /re-verification phase.
“Bug count doesn’t matter“
Here are few effective ways to design a better bug report:
- Describe the issue clearly.
- Don’t skip any of the steps, do record all the steps we need to perform to reproduce the issue.
- Don’t complicate the steps, keep it precise.
- Always have the actual result and expected result.
- Mention the version /platform/ module where the issue occurs.
- Mention the priority of the bugs.
- Add all the screenshots/ recording /system logs to strengthen the report.
To learn more about Quality Engineering topics visit – https://engineering.rently.com/quality-engineering/
Get to know about Rently at https://use.rently.com/
For more blogs refer to Rently Quality Engineering Blogs