Defect Management — Process Instead of Tracking

As software development continues to evolve, we need to reconsider how we manage defects. In the past, defect management focused merely on documentation and fixing the issues discovered. Today that is simply not enough, with modern Agile and highly integrated toolchains rendering the process ineffective.

Now we need to establish a process that tracks defects over the entire tool stack and use all possible information to improve the software development lifecycle. To achieve this, the process should have the following main goals:

• Prevent defects (main goal)
• Process should be risk driven
• Measurement should be integrated into the development process and used by the whole team to improve process
• Capture and analysis of the information should be automated as much as possible
• Many defects are caused by an imperfect process — the process should be customizable based on the conclusions of the collected information

To reach these goals, one can take the following steps:

Defect Prevention — Standard processes and methodology help to reduce the risks of defects

Deliverable Baseline — Milestones should be defined where deliverable parts will be completed and ready for future work. Errors in a deliverable are not a defect until the deliverable is baselined

Defect Discovery — Every identified defect must be reported. A defect is only discovered when the development team has accepted the reported issue and it has been documented

Defect Resolution — The development team prioritizes, schedules and fixes the defect based on the risk and business impact of the issue. This step also includes the documentation and verification of the resolution

Process Improvement — Based on the collected information the processes should be identified and analyzed where this defect resulted to improve the process and prevent future similar defects.

Management Reporting — For all steps, it should be possible to use all collected information to allow reporting to assist with project management, process improvement and risk management.

When creating a defect management process that is right for your organization, it is also important to consider the stakeholders and the type of assets and artifacts involved.

Stakeholders

The defect management process involves many different stakeholders and they must be taken into consideration when developing an effective defect management system. Let’s consider the flow of information.

The author creates or reports the defect to the development team. Based on where the defect was identified, the authors could be developers, testers or members of the support team.

These people could also be consumers of the defect. Developers must verify, fix and document the resolution for the identified defect. Testers use the information to create new test definition based on the found defect and verify if the resolution solves the problem. The support team can use the information to deliver possible workarounds and clarify the reported issue if they are already reported as defects.

In smaller teams the developer could also be a contributor. In larger teams, the developer manager holds this role to prioritize, schedule and assign the defects that have been created. Another consumer could be the executives or management as they use the information for reports to gain insight and improve the development processes.

Artifacts and Assets

The main assets for the defect management are error reports with a description of the problem which should include detailed information to reproduce the issue. To reproduce the issue, screenshots or screen capture videos can help with this process. Log files, especially with detailed tracing and stack traces, are an important source for the development team to identify the defect. In the most agile or application lifecycle management systems, a defect can tracked and documented as artifact (such as an issue, defect, problem or bug).

How Tasktop can improve your defect management

In today’s integrated software development lifecycle, stakeholders use different types tools to fit their needs and defects need to be created and tracked in each of these systems. To prevent a lag in communication and loss of information, it’s possible to integrate the different tools with Tasktop and have an automated information flow across the whole tool stack.

Some common integration patterns are:

Developer-Tester Alignment — Defects can be synchronized into testing tools for creating tests based on the defect. Additionally, testers can create defects in their favorite tool and can synchronize back in the developer tool for quick and easy resolution

Help Desk Integration — Support can create a defect which is synchronized based on a reported problem, allowing support to track the status of the defect. Furthermore, it is possible to use the information from existing defects to create a knowledgebase with known issues and workarounds

Security Issue Tracking — Security violations discovered by an application security tool are synchronized as defect for resolution

Supply Chain Integration –Defects can be synchronized in the quality assurance process to a contractor or 3rd party supplier for quick resolution

Consolidated Reporting — All defect information can be aggregated and consolidated to create reports for optimization of the defect management process

For further information on defect management and how Tasktop can help by integrating your software value stream, please visit our website and contact us today.

Written By: Christoph Thiele

Originally published at www.tasktop.com on March 7, 2017.