#JiraHeroes January '22 Spotlight: Soumen Deb
At Atlassian, we take great pride in the software we ship, and even greater pride in the success our customers achieve when they use our products. #JiraHeroes is our new monthly spotlight series where we ask customers to share their success stories with Jira Software. We hope that customers will find inspiration on how to overcome their own challenges by hearing how our #JiraHeroes overcame theirs.
This month, we’re featuring @Soumen Deb, a Quality Engineering and Assurance Specialist at Cognizant Technology Solutions, who helped a client redesign a bug workflow in Jira Software to improve reporting capabilities, increase visibility, and streamline the development pipeline.
Please introduce yourself! Tell us about where you work, your role, and the team you’re on.
Hello Community! My name is Soumen Deb, and I’m a Quality Engineering and Assurance Specialist at Cognizant Technology Solutions, a leading multinational insurance and financial service provider. My team and I are based out of Singapore, and my team supports clients with Quality Engineering (QE) and Quality Assurance (QA) practices for regional programs across the Asia-Pacific.
What challenges were your client facing and how did that inform the way you thought about designing an integrated bug workflow?
I was working with an insurance and financial service provider that had several agile teams, each with their own unique bug workflow in Jira Software. This caused a variety of different problems such as:
-
Monitoring, evaluating, and maintaining the health of the instance was difficult. Since bugs from different phases of tests had different workflows, transitions, and statuses, having an integrated view of the overall health of the program was almost impossible. The only workaround was to connect with each agile team individually, but this created a disjointed and siloed view of the overall system.
-
Creating reports and consolidating information was time-consuming. Since each team had their own bug workflow, reports had to be manually exported and consolidated outside of Jira Software. This left a large margin for human error.
-
Managing the volume of requests became more challenging. Irrespective of which team raised the bug request, they all needed to pass through the quality toll gates from lower environment to higher environment (quality assurance --> system integration testing (SIT) --> user acceptance testing (UAT) → pre-production). As the program got larger with more complex releases, tracking, fixing, and deploying bugs individually in the development pipeline became more challenging.
What we needed was an integrated bug workflow that was 1) compliant with industry best QA practices and 2) had a clear, distinct view of bug statuses across each phase of tests (InSprintQA, SIT & UAT). That is, every bug needed to traverse the same flow so that statues and transitions are aligned across all the stakeholders.
Since we already had Jira Software in our ecosystem, we knew adopting a customized workflow would be an easy and robust solution. However, there were a few things I needed to keep in mind during this process:
-
This new bug workflow will be implemented with new projects only. Implementing a new workflow with inflight projects could have serious and negative impacts to existing data sets.
-
This new bug workflow will be reusable and easily adaptable across all the phases of tests (InSprintQA, SIT, UAT).
-
This new bug workflow will give program teams the ability to choose the critical path of the bug life cycle. That is, if a bug is raised in UAT, the bug needs to be fixed and deployed to QA env., followed by SIT env., and then to UAT env. to have integrity of the build across all the environments. This is the usual best practice followed. On the other hand, they will have the flexibility to deploy bug fixes directly into UAT in case InSprint & SIT env. are decommissioned.
How did you design the integrated bug workflow in Jira to meet the unique needs of your client’s organization?
Unified vision of downstream work
Before creating a new bug workflow, I met with leaders of the agile teams to learn more and understand the rationale behind the existing workflows. These conversations were very informative, but one learning was the most insightful: each team had the same goal of fixing and deploying bugs for retesting in the next phase, but there was no vision beyond their respective scrum teams. The teams needed an understanding of how their work flows downstream in order for the entire organization to run smoothly. I kept this learning top of mind as I designed the new bug workflow.
Agile iteration of our workflow
Once this initial analysis was done, I drafted a new workflow in the sandbox version of Jira Software. This was where I made regular changes to the workflow based on the feedback I received from the scrum masters of each agile team. I held recurring, weekly meetings with all scrum masters so that we could establish a common vision and increase transparency of the redesign process.
Pilot and implementation
Once we were settled on a new workflow, I created a dummy project and associated this with the bug issue type. Then, I handed the workflow over to the quality assurance team who ran several tests over the next 2 days to check all necessary use cases. Once certified “OK”, our tools admin team rolled out the workflow to a couple of projects during a “Pilot Phase”, where all aspects of this workflow were highly leveraged. After making a few changes to the workflow based on feedback from the Pilot Phase, the new workflow was ready to be rolled out to new agile projects across all teams.
The implementation of the new bug workflow was a huge success. Having a streamlined bug workflow enabled our client to create better reports using Jira Dashboards. The client’s management and executive teams were able to assess the program’s health by looking at the number of bugs (By Severity, By Priority) in each phase of tests under a single view. The client could also generate heat maps for each test phase on defect prone Components and its RCAs.
Thinking back, what are some best practices you share to help others as they think through creating their own bug workflows?
-
The bug workflow should be easily adaptable by all agile teams. The state transitions and statues need to be understood by all the teams (e.g. Development, Business Analyst, Quality Assurance, Program Management, Executives).
-
The workflow should cover all critical QA paths. The workflow should ensure that the bug passes through all quality toll gates and can then be pushed into the next phase.
-
Introduce mandatory input fields so that the workflow is tightly aligned with QA processes. This is done so defect dumps can be used in analytics and retros.
In general, what is one pro-tip you could give to someone who’s a new Jira admin?
Always try new workflows in the sandbox version. Do proper tests of all use cases (which should be done by independent testers, not the one who are involved in creating the workflow) before rolling out for pilot usage. Always keep a roll back plan ready in case you need to revert back.
Thank you so much for sharing your insights, Soumen! 🎊 Please feel free to connect with Soumen on LinkedIn!
#JiraHeroes have extensive knowledge of Jira, and share their thoughtful and tactical content with the Community! Are you inspired by Soumen’s story, or have a story of your own to share? Check out our call for submissions, and let us know you’re interested in the comments below to be featured and also receive our coveted Jira Hero Community badge! 🙌🏻
Was this helpful?
Thanks!
Rachel Tang
1 comment