At Coda, we put a great deal of effort into making sure that new features we launch are polished and well-tested before they reach our users. One tactic that’s worked well for us over the years is to run a
, in which we get more stress testing on a featureーright after the engineers think it’s ready, but before it’s actually launched to users. A bug bash helps with testing different workflows in your software and allows your software development team to crowdsource bugs from the entire company.
What is a bug tracking template?
A bug tracking template allows your software development team to get reports on bugs on your software, triage the bugs, identify owners of the bug fixes, and finally see the progress of the bug fixes. Your company may already have an established process for bug and issue tracking. The bug tracking template should adapt to your existing processes.
When creating your bug tracking template, it's important to define the different statuses a bug can have. Statuses might include "in progress," "not reproducible," and "ready for next release." Once the statuses are defined, you should create a workflow of how a bug goes from one stage to the next. When a bug report comes in, you'll have a sort of flowchart to follow as the bug moves from being "open" to being "fixed."
How to use this bug tracking template
This bug tracking template is different from other tools like Excel or Google Sheets.As stated earlier, this bug tracker is meant to be used by your entire company (not just the software development team). The goal is to get everyone to test out the new feature and report bugs right then and there in this template. Once the bug bash is complete, the product manager or tech lead can manage the bugs like a regular project management tool.
Step 1: Set up details of the bug bash
page, you can write the instructions for how anyone in your company can start reporting bugs. List the different workflows and user journeys that should be stress tested. In the
page, list out the other software engineers or product managers who people can reach out to with questions.
Step 2: Everyone starts reporting bugs
Share this template with everyone in your company (or whoever should be participating in the bug bash). Your team members can start reporting bugs in the
page and see all the bugs being reported in
in real-time. Your team members can add a screenshot to their bug report. Once the bug-bash is over (usually an hour), you can give a shoutout to the person in your company who reported the most bugs by looking at the
Step 3: Triage the bugs
Now that all the bug reports are in, your software development and product management team can triage the bugs. In the
page, you can drag-and-drop bugs to different priority buckets. You can set the "Type" of each bug to indicate the bug's status like "No repro," "Won't fix," and "Duplicate." Finally, give an assignee to each bug you've prioritized so your team knows who is working on the bug fix.
Step 4: Monitor the bug fixes
As bugs are being worked on, the
page gives everyone a bird's-eye view of every bug. It's important for a bug tracking template to include functionality that removes the need to copy and paste bugs as it goes through each stage. This template utilizes views in Coda so that when an engineer edits the details of a bug in one page, the bug report changes everywhere else in the template.
👉 Get started with: bug tracking template
Take your bug reporting to the next level by using this template to manage your next bug bash. As you use the template, you may decide to visualize the
page as a
board instead of a table. For team members outside of the software development team, this template has project management functionality so that you can see the progress of bugs as they get worked on.
How to track bugs
When a user tester is testing a new feature on your product, they need a simple way to add bugs as they experience them. If your bug or issue tracker is difficult to use, it will prevent the tester from submitting thorough and complete bugs for your team to track. Whether you use Excel, Asana, or some other tool to track bugs, you should streamline the process of submitting bugs so that it's easy and simple for your team or user testers.
What info should be included in the ticket?
This bug tracking template includes different properties of the bug that should be tracked. You can customize the bug report template to capture more information. Common things to include in the ticket are:
Status or type (sometimes the bug is actually a feature request, not a bug)
Steps to reproduce the bug
Your bug tracking tool may have other properties to include. If your organization doesn't have a formal bug tracker, you can start simple with just 3-5 of these properties.
Ready to rock and roll?
, delete this page, update the instructions, and share this out doc out with the team!
Common FAQs about a bug tracking template
How do you track bugs?
The most important part of tracking bugs is ensuring the process of submitting bugs is easy and simple. Once bugs are captured, you can start prioritizing them, assigning them to engineers, or moving them to a backlog. Your bug tracker tool should allow you to see the full lifecycle of the bug as it goes from first being reported to being fixed.
What does a bug report look like?
A good bug report should contain one single bug, and not paragraphs and bullet points of issues with a feature. Many companies have internal bug report templates so that each bug report has a consistent format. This format may include ways to describe the issue, the environment the tester noticed the bug, and a ways to submit a screenshot of the bug. Either the bug reporter or the development team can assign a severity and priority to the bug report itself.
How do I write a good bug description?
The bug report title and bug description should allow an engineer to understand the problem and give them the steps to reproduce the bug. The bug title should be concise yet descriptive. In the description of the bug, you can write more context around the bug such as the environment you tested in and why the bug is a problem for the user. A good bug description should also include the step-by-step instructions you took to get to the bug. Finally, some more context around what the expected result is versus what actually happened in the product will help engineers understand why the bug is a problem.