Getting the Bugs Out of Our Bug Reporting System

[#1]

Like any software company, we want to keep our engineers focused on developing new functionality. But we know that some of their time will also need to be used to deal with bugs.  We eventually realized that we could use ProForma to help make our bug reporting process more efficient and keep our engineers focused on higher value work. Note that I am with ProForma. This article represents the results of our dog-fooding.

From Support Requests to Bug Reports

One of the processes we really wanted streamline was the handling bug reports. Our goals was to shift as much of the information gathering as possible to the Support Agent, so that the Support Engineer could focus on actual development and debugging.

A few of the challenges we wanted to address were:

• How to ensure we were getting complete information from the customer
• Refining the handoff between the Support Agent and the Support Engineer, so that the Engineer wouldn’t need to comb through a comment chain to find the relevant data
• Minimizing duplication of effort between the original information gathering from the customer and writing up a bug ticket for our development backlog
• Keeping information organized when the customer reports more then one bug on the same ticket, or reopens a closed ticket to report a second bug

Combining Apps to Get a Solution

We ended up with a solution that combines ProForma forms with another app - Deep Clone for Jira. Using these two tools, we developed a workflow that:

• Allows the Support Agent to gather all of the needed information (for example, steps to reproduce the bug) from the customer and communicate it to the Support Engineer
• Allows the Support Engineer to provide the appropriate fix/workaround instructions to the Support Agent to pass on to the customer
• Allows the Support Engineer to instantly raise an issue in the Development project, with all of the information needed, when the issue is identified as a bug
  
  
  

Here's how it works:

1. Customer submits Support Request form via the JSD portal. The request form collects information about the environment (Jira product and version, hosting, browser) as well as a description of the problem.
   
   
2. The Support Agent may suggest some standard solutions, may ask for support files or additional information, and will try to reproduce the problem. Once it’s determined that the customer has indeed found a bug, the Agent will transition the issue to SUPPORT TRIAGE.
   
   
3. A Bug Triage form is automatically added to the issue. This form has two sections. The first part is completed by the Support Agent. Along with a description of the problem and the environmental information carried over from the first form, it also collects information about the bug's impact, and the steps needed to reproduce the bug. While this form is designed for internal use, depending on the complexity of the situation the Agent may set the form to external, allowing the customer to confirm that information recorded accurately reflects the bug. 
   
   
4. When the Agent has completed their section of the form, they transitions the issue to ENGINEERING REVIEW.  The Engineer completes the second part of the form, providing the Agent with the information needed to explain the findings to the customer.
   
   
5. The Engineer then transitions the issue, either by providing a fix, or by raising a bug. 
   
   
6. The Agent uses the information Engineering added to the form to update the customer.
   
   
7. If the Engineer raises a bug, a post function is triggered which uses Deep Clone for Jira to clone the issue into the Development project. The newly created issue includes the Bug Triage form, providing all of the information needed about the bug.

What Works and What Doesn't

Along with gathering structured information that saves time for the dev team, the biggest advantage we've discovered is standardization – Using a form ensures that the Agent asks the customer all of the relevant questions.  Communication between all three parties (customer, Agent and Engineer) is organized around topics rather than just listed chronologically.  When we need to refine the process, we can easily add fields to the forms without making any configuration changes. 

While this solution works for clearly passing information between the customer, the Agent and the Engineer; and for converting a customer's bug report to an issue in our dev backlog, it does have its limitations.  In cases where the customer has reported multiple bugs on the same ticket, we can attach as many Bug Triage forms as needed. However, the forms do not have an identifier.  When viewing the issue you have to click into each form to see which bug it's associated with.

How Do You Handle Bugs?

Since managing bug reports is a challenge we all face, we'd love to hear from you. How do you handle communication, and division of labor between your Support Agents and your Support Engineer? What fields do you collect on bug reports? How does a bug go from a customer request to an issue in your development backlog?

[Taranjeet Singh]

Nice article @Jennifer Choban !