By Julien Desmulier, Test Manager at q-leap
Anyone who has led a testing project knows the importance of the defect reports’ quality. Defect reports are assets to be adequately used and processed during testing to bring benefits to the software development life cycle.
Hence, a strategy is needed. The defect management strategy is particularly important for organisations which want to work with a number of different testing partners and/or developing projects. So, in particular, what should your strategy include and why?
What the users and testers shall report and record
Information about defects must be as exhaustive as possible; modern tools implement both standard fields and free-text entry options and add additional possibilities for obtaining screenshots, debug traces, or entire system images with minimal user intervention. Define what values you want to see and when a defect report is “sufficiently complete”.
Defining “priority” and “severity” values
Defect prioritization (e.g. “low”, “medium”, “high”) is meant to ensure that the most important defects will be treated first according to some management criterium: business risk, blocking of other activities, importance to customers. Defect severity indicates the potential effect on the product’s users and the product’s usability in general. These are two different dimensions.
The defect workflow
One has to define the “activity diagram” or “state diagram” of a reported defect. The defect will pass through several states: “new”, “confirmed”, “worked on”, “fixed”, “signed off by management” etc. For each “state” that the defect may assume, certain people will intervene: reporters, testers, developers, managers. The workflow clearly delineates how the production chain of defect management works. In large organizations it can be rather complex but defect management tools help to automate it.
The tool must be responsive, easy to install, maintain, upgrade and configure as well as allow integration with other tools. Importantly, it should follow security requirements and be able to manage access control. But, over all, it has to fit with the defined strategy and the related processes in place.
Define the “when”, “how” and “who”
Meetings where defects are reviewed and triaged are important for the project stakeholders (project managers, test managers, defect managers …) in order to decide the order of treatment of defects.
As a result, testing of critical paths is completed earlier which increases the expected level of your software quality.
Defect management must be part of the development process, and involves developers and testers. It is mandatory to ensure software quality and all the raised defects during development phases are corrected and/or justified. Based on the author´s experience, organisations which consider defects as part of the process seem to be able to deliver high quality software faster than organisations which consider defects negative.
So, regarding your defects as assets and using them to guide your efforts should be an important part of your process improvement strategy with the aim of saving time and money!