Imagine, if you will, working in a software company.
Now, imagine you work in the customer support team, and it’s your job to take customer feedback, log bugs for the dev team and communicate with the customer once things are fixed. Let’s also imagine you’re using a task management app that supports “binary” (open/closed) ticket states. That could be asana, Github issues, or one of a thousand other traditional bug trackers out there.
One day a customer emails in and says, “Hey I’m trying to reset my password, but the page just gives me an error”. As a support agent, the first thing you do is try it out for yourself to see if there is a problem. Yes, the page breaks for you as well so there’s clearly a problem. Now you create a ticket in the bug tracker and you let the customer know that it will be fixed soon.
The bug reporting tool says it’s fixed. But is it?
Fast forward a day or two, and you look to check the status of the bug and it’s now marked as “done”. If you’re lucky, your bug tracker software has some sort of source control integration that might let you know that some code has been written to address the problem. But is it out? Is it released? You can see that it’s “done” as far as the developer is concerned, but what exactly does “done” mean?
This is a common problem with many bug trackers. What is done for one person does not mean done for another.
Done for the customer support agent means the fix is in production and the customer knows about it. But for the developer who fixed the issue, as soon as they’ve committed a fix, they’re done! Depending on your team’s deployment process, the fix could already be in production, or the fix could still be days or weeks away.
There’s usually no way for someone outside of the dev team to know. If you’re in the support team, for example, it means constantly hounding the dev team to find out the actual status of a bug, because the bug tracker is often of no help.
The fundamental problem is that for most teams, the bug tracker is actually used by a lot of people for a lot of things, yet the concept of “done” is usually owned by the dev team. A fix may have to go through several sets of hands before it eventually makes it to production. As a result, bug trackers that only support one type of “done” make managing that process a little bit of a nightmare.
Fortunately, there are a few ways to handle this.
A better Bug Tracking template
Customisable workflow:
If your application supports multiple states (or columns if you’re using a kanban board), you can create a workflow that makes it clear exactly what stage a particular bug is at. Instead of being “done”, a bug might be “awaiting testing” or “on staging” and then finally, “shipped”. This means that anyone in the team can quickly and easily see exactly where a bug is at, and what’s left to be done before the fix makes it to production.
We’re pleased to say that BugHerd has fully customisable columns that suit this type of state change.
Adding sub-tasks and checklists:
If, on the other hand, your process involves several types of fixes before it even gets to testing, sub-tasks may be a better way. If this reset password fix requires some UX attention, a back-end fix and a front end fix, these could be added to a task as sub-tasks or a checklist (assuming your preferred bug tracker supports them). This again lets people outside of the dev team understand exactly what is involved in getting the bug fixed, and saves a whole lot of questions being asked.
Bug tracking tags or labels:
Finally, if your bug tracker doesn’t support custom workflow or states, and can’t handle checklists, you may be able to get away with the use of tags or labels (assuming it even handles those!). Before closing a task, a developer can tag the bug with a short descriptor to explain what state the bug is in. Subsequent developers can update the tag to describe what stage the bug fix is up to before eventually closing the bug once it hits production.
Like all things, you don’t want to overdo the process. Too much process means no one will use it (unless you force them, but that’s never a great solution). A good process assists developers in getting shit done but doesn’t get in their way. Just remember, it’s also not all about the developer, there are other people in your team and your bug tracker should be a source of knowledge for everyone, not just the devs.
.jpg)
