How to make the perfect bug report

QA is a pain. Can it just be perfect without review?! Developers, project managers, account managers, clients, everyone  all want it to be, but it’s best to acknowledge they will happen (how we reduce them, however, is a subject for a completely separate post). In Capellic’s value prop, a core value for us is to continuously learn. So, with as much gusto and panache as we can muster to deliver this guide and template for the perfect QA ticket, we highly recommend that you learn too. Also, there is a QA ticket template at the end of this blog because, who doesn’t love gifts.

This helps us help you. 

What’ s all the fuss about QA? Glad you asked! Capellic’s goal is to solve issues as quickly, efficiently, and thoroughly as possible to provide better outcomes.  Some challenges that we have observed that impact resolution times for QA tickets are:  too much information that is hard to decipher or the ticket is too succinct and needs further clarification.  QA tickets  that identify a problem that is replicable  but is without screenshots/links. If you nor I can locate the problem – Poof, did it really happen?

Let’s dive into the technical components of the ticket when performing QA.

What’s important to keep in mind when doing QA/Testing?

  • The feedback on QA tickets should  include instances of unclear direction and editor usability problems, in addition to front end functionality problems.  
  • When reviewing site admin functionality, use your Drupal login account.
  • To test the experience of a regular visitor, open a new incognito or private browser window.  Are you using Edge?  It’s okay, we understand the pain, will gladly help you there too.
  • After you have fully documented a bug that you can replicate, please clear cache and then try to replicate it again. After cache clear, can you still reproduce the issue? Does it present any differently? This is helpful for us to know when trying to replicate on our end. Note that opening a new incognito or private browser window during an active session in a different incognito window will generally not trigger a new session or clear cache. 
    1. What happens if the bug can not be replicated? Ughh those are the worst! Follow these steps to navigate this pain:
      1.  Document as much as you can with all the same information we’ve discussed.
      2. Explain  the context in which the issue showed up (e.g., when I added an item to my cart and clicked on submit)
      3. Be specific as possible about those things that made your experience unique. In the previous example, you would mention what product it was when you had trouble and/or what other items you had in your cart.

What do you need to QA perfectly every time?

A bookmark on your browser so that you can always find this  template, a gift from us to you. 

Perfect QA Ticket:

  • Summary: [Page] or [section]: [short description]
    1. Short description is intended to serve as a Title. Further description about the issue should be detailed below.
  • Description: You can use the following template if desired:
    1. Current behavior: 
      1. Describe what is currently happening and why it is an issue
      2. Maybe add steps to recreate the current issue.
    2. Expected behavior: 
      1. This is sometimes obvious since what you want to say is “get it to work”, but even if it seems obvious, it might be a good idea to add this in.  
    3. Link to pages or references: 
    4. Screenshot / Screen Recording: 
    5. Environment: browser + device
    6. Mode: Incognito
    7. Question(s): 

PS: While this is the right format for reporting bugs, it’s not the right format for feature requests. But there’s good news there too! We like the “User Story” format, which has been much discussed and thought through elsewhere. This example from Atlassian is a good one.

We look forward to seeing your new bug reports.