Defect logging — There’s always a better way…
Defect logging is one of the main tasks of a Test Analyst. We have so many tools in the industry for logging defects or QA bugs. One such tool as we all know is JIRA which is easier for creating bugs or stories. However, in this blog, I would like to share my thoughts on how we could better this process of defect logging by simply linking a shared Google Doc to a JIRA QA ticket or any other defect logging tools.
Cluttering the JIRA dashboard
When testing a bigger feature, it is natural to expect a bigger count of bugs. So, let’s say if we are testing a feature with 5 story points on Jira, there could be around 30 to 40 bugs based on the sensitivity and the impact it has on the system.
A Jira bug ticket for each QA bug would definitely clutter the JIRA dashboard and in my opinion, the developer working on these bugs will be overwhelmed by their numbers. Tracking these tickets until closure/done not only demotivates the developer but also the tester and causes distraction.
Confusion in handling the QA tickets
Obviously, the more the QA tickets, the more the headache and confusion on part of the developer and the tester while fixing the issues.
The existing and the standard method of the tester logging individual tickets for each bug and the developer picking it one by one, fixing the bug, marking the bugs as fixed, the tester then retesting the bug and closing the ticket or reopening the ticket based on the outcome, has so much process within it that the developer or the tester would be led to confusion and frustration. This also results in the blame game when the count of the tickets increases and the majority of the time is spent just in creating and handling these tickets rather than focusing on the quality of the ticket.
Slowing down the Sprint velocity
A ticket is done only when all the QA bugs are closed and signed off by the Product Owner for the feature to be ready to release. So, with so many QA tickets being handled individually until closure, it would slow down the velocity of each ticket and thereby Sprint velocity.
A Solution that I came up with…
This is where I thought of an idea to use Google Doc (or any equivalent platform) that could be accessed (view/edit or commented) by the assigned people in addition to JIRA. My steps as follows:
- Create a Google Doc with the title “Feature name — Issues”
- In the doc, start adding the issues with respective description, screenshots, and URLs
- Create a QA bug on JIRA
- Link it to the feature ticket (is blocked by QA bug)
- In the description of the QA bug, add the shared link of the Google Doc where all the stakeholders could access it at the same time
- The developers working on the fix could go through the doc for the issues as and when it is raised
- This document becomes a live document where it is viewed or updated by the developers and testers at the same time
- The developers could add Comments in the doc for each issue if they fix or give reasons if they do not fix
- The tester can then mark those Comments as resolved
- Once all the issues in the doc are resolved, the QA bug then could be closed, followed by the Feature ticket to Done.
This approach keeps both the developers and testers to stay focussed as all issues raised for the tested feature are within the same doc. So here, we will have 1 QA ticket and 1 doc within the ticket with all the issues.
This worked for me. I hope this works for the readers.
