Bug tracking is an important part of the software development process, whether you’re building a new solution or improving one that’s already on the market. If you don’t track and address bugs in an organized manner, your product will suffer and end users will be dissatisfied.
That’s where a bug tracking template comes in. You can use one of several robust solutions, but most small development teams opt for a simple bug tracking sheet in a program like Excel. Whether you have one sheet owner or have the whole team keep up with it, what exactly should be included in your bug tracking template? Keep reading to learn the answer.
8 key elements for your bug tracking sheet
The summary is a brief description of the bug. It gives the reviewer a snapshot of important details about the issue:
- What happened?
- Where did it take place?
- When did it occur?
“A well-written summary encapsulates the key points of the bug so someone reviewing it can quickly identify what type of bug they’re dealing with,” says Anna Serguts, QA engineer at Orangesoft.
“The description should go into a lot more detail than the summary,” says Serguts. Whereas the summary is meant to quickly help someone determine the kind of bug in question, the description should help your team determine the severity and priority level. You can include information such as the steps required to reproduce the bug, expected versus actual results, and other identifying attributes of the bug.
Oftentimes, simply describing the bug may not be enough for a developer to properly assess and fix it. In addition, the person reporting the bug may not be knowledgeable enough to describe the bug’s characteristics accurately.
“Screenshots and video can provide more and clearer information than even the most detailed text description,” Serguts explains. “For example, a video can show the behavior of a defect in context that may be difficult to describe in writing.”
Flynn Zaiger, a digital strategist at Online Optimism, says a key part of a bug tracking template is identifying the software environment where the bug was found — development, staging, or production.
When handling bugs, it can be frustrating to believe you’ve finally solved the issue, only to realize that the bug persists or evolves in a different environment. “Being able to match the environment to the one in which the bug was first encountered will ensure that you’re solving the right issue,” Zaiger says.
“It’s also important to note who identified the bug on the bug tracking template,” adds Zaiger. It may be an end user, tester, developer, or administrator — and there’s a massive difference in technical knowledge between these people.
In addition, within the development staff, it can be useful to know the seniority level of the person who identified the bug. For example, the experience gap between a junior and senior developer could result in a bug being miscategorized.
“By understanding the user behind the issue, you’ll be in a better position to identify appropriate next steps for addressing the bug,” says Zaiger.
All bugs are not created equal. Some can render software unusable while others may only be a minor inconvenience. It’s important to determine the severity of each bug to help prioritize it. Abhiraj Tulsyan, former technology lead at Stockarea, says determining severity also helps developers figure out how much time they need to devote to the issue.
“For example, if the bug is related to a login or authentication mechanism, the developer will likely make it a top priority and spend a significant amount of time on it,” Tulsyan says. “If the issue is an email sending with a garbled subject line, the developer will likely consider it a lower priority by comparison.”
While severity plays a big part in determining priority, it’s the combination of all the above sections that will help you ultimately designate the priority level of a bug on your tracking sheet. For example, you may have a bug with a high severity level that impacts only a small portion of your user base. This could make the issue a lower priority than one that affects the entire user base.
No bug tracking sheet is complete without determining who on your team will actually fix an issue. Naming an assignee will help your team manage its workflow, as you may have one developer handling multiple small bugs while another developer handles a single large issue.
Depending on your software development approach and industry, you may need to add more details to your bug tracking template, but the above sections will provide a strong foundation for you to build on.