Defect Management: Build better products with better bug reporting
Perseverance, consistency and clear expectations are essential requirements for a defect manager and an effective software testing team.
Defect management is a simple yet key activity of application development. If an application has too many bugs to function properly, it simply won’t be used. While defects inevitably appear during and even after development, a reliable defect manager can minimise their impact on a project’s cost and delivery. Defect management clearly plays a crucial role within any programme.
To start, all project stakeholders must sign off on a clearly defined defect management process (or workflow) during the early stages of the project. This document manages expectations and ensures project buy-in, which strengthens teamwork and ensures success.
When the testing team finds a bug, they need to examine it further in order to ensure its authenticity and prioritise it. Once the team has confirmed and prioritised the bug, they assign it to a developer to investigate and resolve. Once the developer has deployed their fix, the project test team must re-test the application and verify the fix. A build manager must then ensure the release of the fix to a planned build. A customer may even perform user acceptance of the issue and verify the fix. Finally, the team closes the bug report after fix confirmation.
A properly implemented workflow ensures accountability. Developers receive a list of assigned defects that they need to fix; they also provide the test team with a list of fixes that are pending testing and verification. This informs project members of everyone’s activities, and accountability, at any given time.
Experience has proven that when the defect management workflow is optional we risk development inconsistencies. The use of best practices helps optimize product development and quality assurance. The mandatory fields of root cause, priority and severity are vital to the success of a project. These fields enable the defect manager to report on the quality of the code and produce accurate statistics. They help them determine, for example, whether an issue is due to the quality of the code or ambiguous requirements?
Input definition is another important part of bug reporting; each field needs to be clearly defined and should capture the most relevant information. Fields that do not help developers track and fix defects, or help them understand the nature of a problem, can be removed or made optional.
Developers and testers can end up giving an improperly classified defect more attention than it deserves, wasting valuable time and resources. Alternatively, they could overlook a critical defect because the severity was set too low. Software bugs often have a visual component that cannot be properly described. Screenshots of failures can help eliminate ambiguity and/or confusion; they can be especially useful to international teams facing cultural and/or language barriers. To prevent, or at least minimise, duplicate bug reports, team members should query their database to see if the bug has already been reported.
When creating statistical reports about the health of a project, the simplicity of bug reporting often gets overlooked. The number of reported defects, severity, SLA turnaround rate and defect trends can all be incredibly useful. An interactive, easy-to-use bug reporting tool will encourage team participation in the reporting process. It will also help capture the most relevant information about development issues. Project managers can use the tool to allocate and adjust resources based on defect trends. Undertaking best practices helps organisations increase productivity while they maintain and maximise high-quality product development.
Software defects are expensive – the cost of finding and fixing defects is one of the most expensive development activities. Investing in this process can generate significant programme returns.
Written by Claire Cox, Senior Consultant at Piccadilly Group