Posted on

Effective Defect Management With Issue Tracking Tools

A bug is a problem that disrupts the design, specification, or coding of an application. It is, therefore, necessary to track all bugs that disrupt the software development process during the software development lifecycle. This is done to ensure software quality. A product full of bugs is prone to fail. In order to remove these bugs effectively, software testers use issue tracking tools. These tools aid in easily tracking these bugs and remediating them as well. The bug reports help to bring the application at par with international standards and best practices. Moreover, with these tools, testers are easily able to streamline and organize any defects with ease and comfort.

There are many advantages that these issue tracking tools provide. However, the main reason that software testers use these tools is to ensure that they manage and eradicate defects properly. With these tools project managers, software testers, and QA members are able to ensure quality without compromising on any other factors. using these tools is to ensure effective defect management. This ensures that software quality is maintained without compromising on any other factor.

Posted on

Measure Time to Detect Defects

When I was young I read a study by TRW done in the '60s that measured the cost of fixing a defect that was detected at different points in the development cycle. If the developer who wrote the defect found it immediately after writing it then we can assign one unit of effort for resolving that defect. If that's true, then it takes something like seven units of effort to resolve the defect during the testing phase, 15 units of effort to resolve the defect just before release, and a whopping 67 units of effort to resolve the defect if it makes it into the hands of the customer. In other words, the cost of fixing defects grows exponentially with the amount of time it took from when the defect was created to when the defect was resolved.

It's always cheaper to fix defects sooner. This is because the longer we wait from when a defect was created, the less we are familiar with it. The vast majority of time and effort in debugging isn't involved in fixing the defect. Some defects do require a significant amount of reengineering but most defects are small problems that can be quickly and easily fixed. What can't be done quickly and easily often is finding the defect in the first place. Much of the time, finding a defect is where we spend most of our effort and once we locate the defect it's usually trivial to fix.