Every project in the world has decisions that need to be made. Whether it’s a software bug or a business decision involving multiple departments, teams need to make decisions and a way to ensure those decisions are correct and easily accessible once they start writing code. Issue tracking helps make this easier by adding a touch of structure to the process.

Requirements rarely lie on the surface. Normally, they're buried beneath layers of assumptions, misconceptions, and politics.Steve McConnell ¹

Issue tracking is frequently referred to as “bug tracking,” but this doesn’t do it justice. The phrase “bug tracking” tends to imply that bugs can only exist in code, but this view is flawed. It’s just as easy to have bugs in requirements, design, or even specifications. Issue tracking is designed to help uncover or prevent these types of bugs the same as coding bugs. This keeps everything on the same playing field and provides a structured opportunity to address these kinds of bugs when they’re the cheapest to fix: Before any code has been written.

How does issue tracking work?

The phrase “issue tracking” may sound a little dramatic, but it’s really just a specialized todo list. At its core, issue tracking adds an extra layer to your team todo list by supporting a review process. So instead of a single “complete” state, you have at least one more state to indicate that the finished work has been reviewed and approved. 1 This helps prevent problems from slipping through the cracks by ensuring that there are at least two sets of eyes on every resolution.

Issue trackers also differentiate open from reopened. If something has been marked as resolved but turned out not to be resolved, the fact that it had to be reopened is a key piece of information. Nobody likes to have to ask twice, and if an issue has to be reopened, it’s a sign that there was likely a misunderstanding or some miscommunication that needs to be addressed prior to any additional attempts to resolve the issue.

This workflow is what makes issue tracking different from todo lists. On the surface, it requires an extra step and more work, but below the surface, it’s providing an extra layer of review to ensure that problems don’t slip through the cracks.

Software is only half the battle, though. The other half of issue tracking is about good habits and discipline. The software is only a tool to encourage and support those habits. And like any tool, it’s important that you choose the right one for your situation. Too complex, and it can actively interfere with your process. Too simple, and it won’t do the trick. Don’t worry, though, we’ll walk through those considerations in a later lesson.

Goals of Issue Tracking

While the workflow and process can vary from one team or project to the next, the goals and high-level approach are the same for every team. Each of these steps or processes may be broken down or handled differently between teams, but every team’s testing process will include the following components:

Capturing

Where should I report this? Who should I tell? If issues aren't captured, they can't be resolved. An issue tracker provides that central place to capture and handle bugs, questions, tasks, ideas, issues, and more so that they don't slip through the cracks. That way no one ever has to wonder where to log something.

Recording

What did we decide? When did we decide that? Who decided that? Frequently, after a decision is made, the team needs to review it either to execute on the decision or to doublecheck that they made the right decision in light of new information.

Accountability

Who's responsible? Who said what? When did they say it? The best way to ensure that things get done is a focus on accountability. This both helps encourage forward progress and reduce miscommunication.

Prioritization

What's next? What's most important? The team needs to know what's most important. Having a database of 100 problems isn't any good if nobody knows which problems need attention first. Issue tracking helps create a central place to prioritize bugs against new features and vendor choices over implementation to make sure things get done in the right order.

Resolving

What was the solution? How did we fix that? Things need to get done. So an issue tracker helps focus on forward progress. Inactive or lingering issues are bad and treated as such. For this, discipline is just as important as the tools, but the tools can certainly help reinforce this.

Reviewing

Is it fixed correctly? Is it fixed as I intended? This is the quality assurance layer. It enables the review process to ensure that the outcome matches the expectation. Otherwise, simple misunderstandings can turn into bugs slipping through the cracks.

Issue tracking is really just a team todo list with a heavy focus on accountability and progress. Unlike a todo list, however, issue tracking not only helps ensure that work gets done, but that it gets done correctly.

Why use issue tracking?

You want to ship software as quickly as possible with the fewest issues possible. By themselves, these two concepts are at odds with each other. In order to prevent issues, you need to invest time. You can always ship faster by lowering quality. The key is finding the middle ground that works for your team. So let’s see how issue tracking helps you balance the two to save time and money.

1. Catch issues earlier

It’s a simple fact that the earlier you catch a problem, the less time and money will be required to address it. ² If you uncover an issue before writing any code, the cost is almost zero, but if that same issue makes it all of the way to production and affects customers, the cost is significantly higher. At that point, it requires developer time, support team time, and customer frustration.

While other complementary processes can catch issues before they even make it to testing, Issue tracking in conjunction with a formal quality assurance phase can serve as the last line of defense in finding and fixing issues before the costs increase dramatically. 1 Once something is live, the developers have moved onto the next thing, and it’s going to take them longer to switch gears and fix the problem. In the meantime, that issue lingers in production, and more customers are affected. The issue is creating more problems for customers. Those customers are creating more support requests.

2. Find more issues

While the various forms of automated tools play key roles in discovering bugs, the human brain and associated senses are number one testing tool. ³ In addition to finding issues before they reach production, a manual QA process helps catch certain types of problems that other forms of automated testing or code analysis may miss. ⁴

By using a testing phase to complement your automated processes, you enable team members to catch more subtle or subjective problems that a developer may not even be aware of. There is certainly some overlap in potential defects discovered between multiple testing techniques, but for the highest discovery rate, complementing automated processes with human processes generates the best results.

Non-technical Team Member Involvement

One of the biggest benefits of a formal issue tracking and quality assurance process is that your non-technical team members can help test before releasing to the public. Often, your non-technical team members are the business experts and the only people versed enough in the business requirements to catch the subtle bugs in business logic. Ideally, you’ll have a formal acceptance testing phase where your clients or stakeholders can review the product in a staging or other pre-production environment to approve the end result before shipping.

A Second Set of Eyes

Another commonly overlooked benefit of formal testing is ensuring that developers don’t test their own modules. And developers should avoid doing quality assurance for their own work. ⁵ For example, let’s say a developer’s understanding of the requirements is wrong. In that scenario, any tests or code they write will also be wrong, and no amount of testing by that developer will be able to catch the problem.

Just like an author shouldn't rely entirely on spell checking software and not hire an editor, you probably don't want to ship software with having a second set of eyes reviewing the results.

With a dedicated manual testing phase, you’re able to have people cross-test each others modules to ensure that subtle mistakes like that don’t slip through. Moreover, even if the developer fully understands the requirements, they’re often too close to notice problems with their own code. So having a second set of eyes involved is important to help find as many problems as possible.

Just like an author shouldn’t rely entirely on spell checking software and not hire an editor, you probably don’t want to ship software with having a second set of eyes reviewing the results.

Building vs. Breaking Mindsets

Even if you do have developers testing their own modules, having a period of time dedicated to finding defects rather than writing new code can make a huge difference in their discovery rate. There’s a huge gap between creation and destruction mindsets. When developers write code, their brain is in a creation mindset. They aren’t actively looking for loopholes or thinking about edge cases and unusual scenarios. ^{6 7} A formal testing phase however enables the team to think more destructively and focus on uncovering problems rather than just writing new code. This is the reason that we encourage teams to slow down and break things.

There’s a huge gap between creation and destruction mindsets. When developers write code, their brain is in a creation mindset. They aren’t actively looking for loopholes or thinking about edge cases and unusual scenarios.

Browser/Platform/Device Testing

Finally, developers are also more likely to miss cross-platform issues during development. Whether it’s testing against different operating systems, devices, or browsers, developers spend the majority of their time in their work environment. Even if they do set aside significant time testing in other environments, it will only ever be a fraction of the time spent developing in their primary environment.

As a result, your team likely isn’t testing enough across different platforms, operating systems, or browsers. A formal testing phase is the ideal place to do this testing and have different people use their primary environments to do the testing. That is, if you develop on Macs, you’ll want to ensure that you have a few Windows users testing from their own computers.

3. Get it right the first time

The primary difference between formal issue tracking and a todo list is the review process. Without the review, or retesting, process, you will invariably run into cases where bugs are fixed incorrectly. In some cases, the “fix” may not work at all. Keep in mind that every time new code is written, that new code is introducing the opportunity for additional bugs to sneak in. If your team isn’t retesting resolved bugs, then they’re only doing the job halfway.

Similarly, unless your developers also happen to be the domain experts, it’s likely that they don’t have the knowledge to determine whether their solution is entirely correct. Or, they could simply misunderstand the problem. That’s where issue tracking’s review process really helps. Whenever someone reports an issue, they’re the best person to officially green light a resolution. Otherwise, a developer may think something is fixed but implement the a solution incorrectly due to a misunderstanding of either the business logic or the details of the bug report.

Equally important with the review process is the discussion process. Issues aren’t as simple as todos because they usually involve discussion, debate, and, ultimately, agreement. Instead of a team member going rogue and just “fixing” something, key team members are able to offer their input so that the right decision is made. What’s even better is that a month down the road when you’re second-guessing a decision, you have a written record of how the decision was made—saving even more time because you don’t have the same discussion all over again.

4. Work on the right things

With any software project, it’s challenging to choose the right things to work on, and it’s often even tougher for team members to know what they’re expected to work on next. Prioritization involves a mix of both objective and subjective variables. Are there dependent issues? Is it a show-stopper? Is there a workaround? How many customers does it impact? Is there a fixed due date? How much time/money/materials is available to fix this? How much time/money/materials would be required to fix it? As a result, boiling issues down to their true priorities is a task best suited to project managers, clients, or stakeholders as they have the best high level view of the answers to these questions.

Working on new features without first fixing the bugs in existing features is a recipe for disaster.

A centralized issue tracker in conjunction with a process for handling prioritization helps minimize developer confusion by freeing them from worrying about priority and letting them focus exclusively on what’s next for them. Instead of having developers swim through varying, potentially competing, data points that affect priority, they’re left with a simple priority and no room for confusion.

Similarly, by handling bugs, issues, questions, ideas, enhancements, and everything in a centralized tool, you’re able to prioritize everything against each other. If your feature roadmap is separate from your bug database, it’s nearly impossible to know what’s most important. Separating your new development work from your bug fixing work also has the side effect of relegating bugs to second-class citizens. As a result, it’s easier for the defects to be ignored, and that’s dangerous. Working on new features without first fixing the bugs in existing features is a recipe for disaster. Centralizing everything makes you more efficient when prioritizing work and your team more efficient because they don’t have to wonder what they should do next.

5. Create happier customers

The biggest benefit of a good issue tracking process is happier customers. Fewer bugs means lower support costs, but not having to deal with bugs at all makes customers more efficient and happier with your software. In addition to happiness, your customers will see your software as more reliable. They’ll be more comfortable trusting it, and thus, recommending it.

You’re not only saving your team time dealing with production issues, but you’re also saving your customer time because they don’t have to report the issues. Of course, don’t overlook the fact that your customers are going to be a whole lot less likely to report issues than your in-house quality assurance team. So for every bug report you get, another 5-10 customers have problem encountered the same problem. Or, in some cases, your customers may just overlook a bug that’s not serious but silently increase their lack of faith in your software.

What’s next?

Manual testing and issue tracking can help. They're only one component of a good holistic QA process, but they're a key component for finding an entire class of issues that are unlikely to be discovered with any other method. Now that we have a high level overview of how the various tools and processes fit together, we can see how they fit into a basic project timeline. Let's move on to the process of software development.

1. Steve McConnell, Code Complete, Second Edition (Microsoft Press, 2009), 202. ↩
2. Forrest Shull, et. al., “What We Have Learned About Fighting Defects” (2002), 9. ↩
3. Gerald Weinberg, Perfect Software And Other Illusions About Testing (Dorset House Pub., 2011), 149. ↩
4. Glenford J. Myers. The Art of Software Testing, Second Edition (John Wiley & Sons, 2004), 22. ↩
5. Myers, The Art of Software Testing, 17 ↩
6. McConnell, Code Complete, Second Edition, 504 ↩
7. Myers, The Art of Software Testing, 17 ↩