Micro Focus is now part of OpenText. Learn more >

You are here

You are here

The pros and cons of defect tracking

Yvette Francino Agile Consultant

Defect tracking has long been used to measure software quality, with an emphasis on finding as many bugs as possible early in the development cycle. While finding bugs early is still an accepted goal in development circles, many agile teams have moved away from the idea of defect tracking, claiming that the process creates unnecessary overhead and prevents testers and developers from communicating effectively. There's some truth in that, but there are ways to get the benefits from defect tracking without the drawbacks.

Advantages of defect tracking

There's no shortage of tools when it comes to defect tracking. You can find tools to track non-technical issues, customer-facing tools for production-related defects, and internal tools the development team can use to track defects. In fact, even if you're just using sticky notes, email, spreadsheets, or a log on a wiki to track customer issues, you'll need defect tracking of some sort. It's just a matter of figuring out the right tools and processes for the team.

Defect tracking helps you ensure that bugs found in the system actually get fixed. Sure, it's great for testers and developers to have a conversation and to recreate the problem together. If the problem gets fixed immediately, great! Maybe it doesn't need to be logged. But if it just gets put down somewhere on a mental to-do list, there's a good chance it'll slip through the cracks.

Defect tracking tools not only provide a way to ensure follow-through but also provide valuable metrics. Depending on the tool being used, the team can tie defects to changed code, tests, or other data that will allow for traceability or analysis on defect trends. If a certain module is riddled with defects, it may be time to review and rewrite that module.

Defect tracking tools allow for a repository of documentation that will provide value for troubleshooters or for support personnel later on if there's a workaround for an issue. Having a tool in place also sends notifications to the right people when a bug needs to be fixed, tested, or marked as resolved.

Disadvantages of defect tracking

Many of the disadvantages of defect tracking have more to do with the overhead of the processes and tools than the idea of defect tracking itself. Some organizations use multiple tools to track defects of different types, and those tools often don't integrate well with one another. The team ends up with the same defect documented in multiple places with slightly different descriptions—perhaps first from a user's perspective—and then from a technical perspective in the internal bug-tracking system.

Complications can arise out of confusion over descriptions, lack of information, tools that are overly cumbersome and require mandatory fields for which the user doesn't have the answers, and difficulty in reporting. Sometimes the process overhead required to open a bug is more time-consuming than simply fixing the bug.

If every low-priority defect is tracked, the defect report will include many bugs that will never be fixed because fixing them doesn't provide a high enough ROI. However, keeping them in a defect report as "open" will require constant reanalysis and may imply poor quality, when in fact these defects aren't issues customers care about.

Though defect-tracking tools help in storing documentation, they may actually hinder communication if they prevent team members from talking and collaborating. If code is thrown "over the wall" from development to test and the bugs are thrown back to development, when the only communication about defects is done through a tool, there are bound to be misunderstandings. This results in the classic line from developers, "it works on my machine," along with closure of a "user error." That leads to a reopened bug and an under-the-breath expletive from the tester.

The best solution for the team

Though agile development promotes "individuals and interactions over processes and tools," processes and tools are still important. However, it's important for teams to avoid replacing strong communication with poor processes and cumbersome tools.

Some agile teams document their defects by creating user stories. Itay Ben-Yehuda recommends against this, claiming that these defect-related stories will get lost in the backlog and take a backseat to new feature work.

Other agile teams may take the approach that bugs must be fixed immediately and thus don't need to be tracked. "If the defect is important enough to fix, then fix it. Storing it only prolongs the pain and possibility of repercussion later," says Amy Reichert.

Many agile teams take the approach that if a bug is found and fixed in code being developed during the current sprint, they don't need to track it. Otherwise, it needs to be tracked.

Clearly, the usability of your defect-tracking tool is a big factor in how successful your team will be in using the tool to its advantage. Often, the team doesn't have a choice in the tools they use or the standards set by the governance team. How much flexibility they have depends on the organization. However, if a tool has been selected, it would be advantageous for someone on the team to become a super-user and take advantage of configuring the tool to make it as user friendly for the team as possible, perhaps by adding templates or canned reports.

Teams need to work together to decide when defects will be tracked, as well as discuss any related processes or guidelines, such as how much information must be tracked for each ticket. Optimize these processes for communication, flow, and quality. Continually evaluate during retrospectives and adapt your processes over time.

Every software development team needs to have a process for how to handle defects. Whether your tools are as simple as sticky notes or as complex as an integrated application lifecycle management tool suite, decide as a team how to use the tools and create the processes that will work best for you.

Keep learning

Read more articles about: App Dev & TestingTesting