Manage Learn to apply best practices and optimize your operations.

Tracking bugs effectively in continuous development


The continuous development practice is meant to be quick, reduce waste and produce a higher quality product with...

fewer distractions such as deadlines and schedule pressures. Going continuous smooths the workflow -- at least until a software bug is discovered. In some teams, the appearance of a defect interrupts the flow of work like a swarm of bees at a picnic. Deep down everyone knows a defect will be found but for whatever reason when defects are found it's a surprise. Tracking software bugs -- the process of detecting defects and reporting them for repair -- falls on project managers and testers.

However, as an Agile practice, the team remains responsible for the overall quality of the released product. In the excitement of moving to Agile, often the tedious task of deciding if, when and how to manage software bugs is skipped. A business needs to consider methods for tracking bugs when they are reported in a continuous development system.

Rather than investing in a separate tool, many teams opt to manage bug reporting with user stories, bug boards or other tasks. In this article, we'll discuss the advantages and disadvantages of tracking bugs in a continuous development system and offer alternatives that align with the continuous flow.

Formally tracking bugs provides advantages

One advantage of formally tracking bugs is meeting regulatory requirements. A business may need to track defect evidence and keep formal logs in case of audit. In this case, a business may still consider alternatives to using a formal tool, but additional work may be involved to track and manage defects in a manner that meets regulatory requirements.

Another advantage of formally tracking bugs is that defect reports store knowledge of the code. By reading defect reports and analyzing report data, a tester can determine where the fragile code exists. Additionally, defect reports may be used as a type of regression test to ensure old problems do not recur. Both testers and developers tend to make notes in defect reports that may not be recorded otherwise.

Finally, visibility into the application is a positive byproduct of formal bug tracking. Visibility means not only developer and tester knowledge of the code, but additional visibility into the code for customers. For example, if a software application is reaching out to new markets, defect reports or lists may assist them in developing credibility. Many software companies release formal bug reports as a means of proving quality to customers. Of course, if the application has a large number of defects, it may defeat the purpose. However, improving visibility by being transparent and reporting problems without any scrubbing or hiding builds trust and may serve to improve customer relationships.

Tracking bugs can increase expense and duplicate work

The disadvantages of formally tracking bugs include the financial expense involved in purchasing defect tracking software or a service, the possibility of duplicating work, and the growth of, and need to manage, technical debt. Bug tracking software comes in a variety of forms: traditional software applications, software as a service, cloud applications or Web versions. It's prudent to review the software used for code management in case it includes a companion defect tool that can be utilized. Before purchasing defect tracking software, determine if it will cause more harm than good and if the money may be better spent elsewhere.

Duplication of work is a feature of bug tracking. First testers enter the defect in a formal fashion; the defect is then typically reviewed by product management or via a meeting of peers to determine if the bug is going to be fixed or saved to fix another time. From there, the tester usually has to defend the defect, update it and provide additional information to development or product management. Nearly every role touches the bug and repeats a review, an effort to reproduce or a discussion of where to assign or store the bug.

If the defect is important enough to fix, then fix it.
Amy Reichert

Finally, a business should consider whether the technical debt associated with tracking bugs is worth the effort. Defects not deemed worthy of fixing immediately are saved indefinitely in many cases, even though in reality, a fix will never be done for them. This produces technical debt that will never be paid down. Basically, technical debt takes up space and time in managing a mass of stored defects. Technical debt may consume server resources if it's large, and it will need to be managed routinely. Technical debt becomes a massive monster that is never satisfied.

Alternatives to formal bug tracking

Before trooping down the well-worn path of formal defect reporting, consider alternatives that work better in a continuous development system. Consider the business need for tracking defects and decide if it's worth the extra space, time and effort to manage it indefinitely.

One option is to stop tracking bugs. If the defect is important enough to fix, then fix it. Storing it only prolongs the pain and possibility of repercussion later. Unless a defect forces a complete design change, it should be fixed immediately rather than be stored, reviewed, updated and ignored. In extreme cases, it may be worthwhile to store a bug or two in a temporary backlog.

Another alternative is to have testers discuss bugs directly with development and product management. In a typical continuous development environment, either a Kanban or other task tracking method is used. Defect tracking can be as simple as adding a story on fixing the bug. It may be in a standup or other existing meeting. Defects worth fixing are then written into stories and added to the backlog. In this manner, the business has a record of the defect in the story. There's no need for an additional tool or for testers to duplicate work by adding a story and then also adding it to a defect reporting tool.

Consider creating a knowledge repository (like a wiki) rather than tracking defects. A knowledge repository can be useful for developer research, testers' use and for support and implementation personnel. Setup or configuration issues that are simply misunderstandings or training issues can be stored for later use rather than written up and managed as defects. All stories are available for review if needed, and in a single location.

As a continuous software development business it's imperative to plan how defects will be tracked when they are found. Planning will keep the continuous flow of work moving smoothly when the team understands how tracking bugs works. Consider alternatives that don't involve long-term defect storage and management if it works for the business needs and requirements. Select a process that keeps the work continuous without creating duplicate work or feeding the technical debt beast to the detriment of the business, team productivity or workflow.

Next Steps

Get more tips on reducing technical debt

Read up on reasons to fail fast

Spur on continuous process improvement with APM data          

Track progress better with cloud-based project management

This was last published in April 2015

Dig Deeper on Software ROI and Business Analysis




Join the conversation


Send me notifications when other members comment.


Please create a username to comment.

i'm surprised that you don't say anything about Test Driven Development as an alternative. That way, the bugs are taken care of up front as they occur.
if we are testing hardware and firmware, standard unit testing is not enough. an automation framework / test harness and associated electronic test fixture be interfaced.
In my company, we fortunately don't have any kind of requirement to track bugs, and so we don't. If a bug is found at any point before release, it simply gets fixed. Luckily, our developers are really good at fixing any bugs quickly and efficiently. If at all possible, we'll add an automated test (either unit test or acceptance test, or both, whatever is appropriate) to cover the missed case.

If a bug is found after release, it is tracked like any other user story.

This process works pretty well for us and seems very efficient.

The technical debt is there, the act of recording it has no impact on the absence or presence of debt. A tree falling in the woods makes a sound, regardless if someone is around to formally document it.