The concept of “bug tracking” may seem intimidating, but it’s little more than a specialized task list. At its core, issue tracking adds an extra layer to your todo list for reviewing completed tasks. So instead of only “complete” and “incomplete”, you also have a state to indicate that the finished work has been reviewed and/or approved. 1
This is a subtle but important distinction when developing and testing software. This final review step of the workflow for bug tracking is called “retesting.”
After developers fix the outstanding issues and mark them as resolved, the testers can go through the list of their reported issues that are now marked as resolved and verify that the fix is correct. If it is, then they close the issue, but if it’s not, they reopen it and send it back to the developer.
Retesting is an absolute requirement for shipping high quality software because mistakes are more likely to occur when fixing bugs than when writing the original code.1 That’s worth repeating. When a developer is fixing a reported bug, that developer is more likely to make a mistake fixing the bug than when originally writing the code.
That sounds crazy, right? How is this true?
The first reason is simple. Any time you write code, there’s a chance that code contains bugs. (Not in your code, of course, but, you know, other people’s code.) So any change in code has a non-trivial chance of introducing new bugs.
On top of that, when you initially write code for a given module, the subject matter is fully loaded in your brain, and you’re immersed in the task at hand. When fixing bugs, however, you’re context-switching in and out of different modules working your way down a list of other bugs. The original code isn’t as fresh in your mind, and you’re making changes that you likely didn’t plan for in your original code.
And that’s all assuming that you’re fixing bugs in your own code. If you’re fixing bugs in code written by others, the error rate increases further as you try to wrap your head around their code.
How does retesting help?
The seemingly simple step of retesting your software helps mitigate this problem in several ways. It requires a little more time, but it generates great results in terms of quality.
- Provides structure and reliability. A formal testing and retesting process gives you a reliable and reproducible way to verify work. Most importantly, the structure helps ensure that everything is reviewed and prevents issues from slipping through the cracks.
- Exposes miscommunication. When bugs are reported, it’s possible, likely even, that the developer is misunderstanding the expectations of the reporter or that the reporter didn’t clearly explain the problem. Reviewing solutions mitigates this by having the reporter review the fix.
- Involves the domain experts. Sometimes, the developer misunderstands the business requirements. When your business experts, who may not be technical, are involved in testing and retesting, they’re more likely to catch subtle bugs that developers miss.
- Provides a second set of eyes. Even if you’re business experts aren’t doing the testing and retesting, simply having a second set of eyes review work will do wonders for your quality.
- Provides accountability. When a developer has a dozen bugs to fix, it’s easy to get caught up in the quantity of bugs fixed. That’s just human nature. We feel like we’ve achieved more because the list is smaller. When you know something will be retested, and you don’t want to see it reopened, you’re a little more likely to focus and make sure that you fix it right the first time.
Despite the extra time, it’s saves time and money if you catch the bugs during retesting rather than after they’ve been released. Retesting is your absolute last chance to find and fix bugs before the cost of doing so begings to increase dramatically. 2 If it’s worth testing the software the first time that it’s written, it’s worth even more to test it after it’s been “fixed.”
But retesting is cumbersome!
The most frequent pushback with formal bug tracking and retesting is that it’s cumbersome. It’s faster to work from a simple todo list or text file. That’s true, but it’s even faster to not test at all. So where do we draw the line?
If you’re a team of one, todo lists will be faster and easier. They won’t lead to the same level of quality but the tradeoff in speed and efficiency can be worth it. Even the simplest bug tracker can’t compete with a todo list on simplicity and speed. If you’re both the developer and the tester, the deliberateness of a formal process and bug tracker may slow you down more than it helps. You can still benefit from dedicated time for testing your software, but the benefit isn’t as significant as it is for larger teams because as a solo developer, there’s no room for miscommunication.
Similarly, if you’re just beginning development or knocking out a quick prototype, formal bug tracking can impede your progress without offering any benefit. Some simple notes in a text file or a todo list will be enough. Logging bugs or issues is best when the issues need discussion or a formal testing and retesing process.
If you’re not already retesting, you’re leaving a huge hole for bugs to escape into production. With just a little extra time and discipline committed to retesting, you’ll see great results.