Follow these 6 bug report enhancements and see the change!

Improve engineer‘s productivity with 6 simple steps.

A quality engineer typically spends around 10–15% of the day’s effort in raising new bugs. But this is just the beginning! An extra 15% effort is then spent in several back-and-forth communication with the developers involving information exchange about the same bug. This extra share of effort takes a big chunk out of our time & energy thereby directly affecting our productivity.

The symptoms to this problem can be seen in the form of repeated & redundant communication, re-iterations of test scenarios time & again, and several context-switching instances thereby delaying the current set of assigned tasks and engineer’s burnout!

The need for this to-and-fro bug-related communication mostly arises from the lack of information about some important aspects of the bug in the initial bug report!

T o your surprise, most of these redundant efforts can be easily avoided thereby saving hours of engineer’s time.

Let’s look at some simple improvements in the bug reporting template that can save a major chunk of your & developer’s effort thus contributing to overall engineering productivity.

Bug occurrence frequency :

This is a critical piece of information and is often missed by most test engineers while reporting bugs which leads to wrong assumptions at the developer’s end & false triaging of the bug. A bug can have an occurrence frequency of Once (if it has occurred only once in the entire test cycle), Sometimes (x%) i.e the bug appears x times out of a total of 100 trials of scenario run, Always (100%) i.e the bug appears 100/100 times when the scenario runs.

The criticality & severity of any issue changes drastically depending on its occurrence frequency and hence become a very important metric to be added in every bug report.

2. Reason for a specific priority/severity :

It is very important to add a few details related to the priority of the bug and reasoning to back this priority & severity level ! This reasoning can be related to hampered user experience, revenue-affecting scenarios, app crashes having higher frequency probability with production scale, new user journey, and user retention, legal action possibilities, etc.

A strong reason here with the correct logic and advocacy can even make a mere spell check to be regarded as a release blocker. (Example — The Welcome signup screen has a spell check bug leading to a hampered user experience for all new users which can lead to dropping in new users at this part of the acquisition funnel. Further adding marketing and product members for detailed triaging.)

3. Initial debugging details / RCA :

Randomly assigning bugs to developers lead to increased TAT, miscommunication & a possible project delay with unnecessary re-assignments of the bug. The quality engineer is expected to preform a basic log analysis and debugging to assign the bug to correct developer/team with details about the findings of this debugging.

The debugging can be done with the help of application logs (adb/Xcode), server logs (pm2/docker), proxy logs (charles/fiddler/etc), and knowledge to read and analyze the above logs. This improvement can save hours of developer’s time and effort thereby leading to higher engineering productivity and faster project release.

4. App Version, environment details, test data (userId / sessionId):

A bug report can not be complete without mentioning the details of app build version, server / VM / stage environment details & test data used while reproducing the reported bug. All this information will help the developer in quick debugging & possible resolution of the bug.

5. Keep all updates in the bug’s comments section :

It is always a best practice to keep adding all updates in the bug’s comments section. This will help in reliable future references, bring transparency in leadership review for project blockers, keep all agile teams updated for communication, and avoid redundant queries. This practice is extremely useful to take the product/BA/client team’s point of view when deprioritizing a bug based on the developer’s comment.

6. Create a common bug template: Last but not the least, it is advisable to create a bug template that is followed across all agile pods thereby bringing a sense of uniformity and ensuring all necessary details are added for every bug report as a regular practice.

The key to saving everyone’s effort from redundant queries around reported bugs is in understanding the importance of the above fields in a bug report & sharing exhaustive information while writing a bug story.

Apart from improving overall engineering productivity, a complete bug report helps quality engineering teams in various ways -:

This helps in bug advocacy with facts and information.Keeping the bug reports updated leads to reliable future references.Depicts your debugging skills and technical aspects of the reported bug.Shows your skill of understanding the user experience & able to map a suitable priority to the bug accordingly.Ease of understanding the context of the bug by leadership, product ,CRM & marketing teams in case of a project review / bug audit or random reference check.

On the downside, however, a lengthy bug report can also lead to possible reluctance from test engineers to report bugs and prioritize the execution of current pending tasks. Hence it is advisable to collaborate with development teams and create an optimized bug template that can carry maximum information in minimum fields thus taking no more than ~3–5 minutes of an engineer’s time to create a new bug.

So next time you are onto the task of improving your team’s productivity, you already now know the low-hanging fruit right in front of you in the form of bug reports and associated details with that report.

Connect with me at https://topmate.io/sahil_puri for mock interviews, 1–1 mentoring sessions, SDET role career guidance, or a casual chat on testing!

See you next time
Sahil Puri
(Youtube channel , Linkedin)