This article will present the benefit of setting defect tracking procedure which centralizing and managing all defects. Recommendation for implementing this procedure is presented.

Suppose the current project phase is system test or UAT. Until now 150 defects were detected with four different severity categories, for six different applications. Part of those defect are under development investigation other part already fixed, but not re-tested and the rest are new or closed. In addition not all the defects are real bugs, some of them are new requirements, queries or testing errors.

This is a very normal and common situation that must be centralized, controlled and tracked, otherwise the following will happen:
Development will not be focused on the important defects. Meaning a defect with low or medium severity might get higher priority than high or critical.
The real software quality is never clear. A delivery of software to the customer is actually unknown.
More costs and efforts. It is difficult to perform parallel work and resource allocation plan for the short term.
Lesson learned activity for future improvements can not be done, because root cause analysis of each defect is not documented.

Well, defect tracking procedure that involving all groups simply doing the work for you. The implementation of this procedure is not difficult.

How to implement defect procedure?

Explain each defect severity and demand to report defects as defined. Severity of a defect is usually interpreted differently by developers, testers, managers, customers and consumers. The reason is mostly related to wrong understanding of the real defect impacts and also due to different constrains and interests of groups or persons.

For instance, a defect might look like critical one, but in production (real live) only 1 out of 500,000 consumers can really be affected. Another example, due to time table constant tester will report a non critical defect with critical severity in order to get an immediate support.

Ask to provide detailed defect information. Providing defect information is simply early the correction delivery. The details are: test scenario with input and expected results, environment of execution, error description, data profile, special used variables or business implementation etc.

Dont mix between severity and priority. There is confusion between Severity and Priority. I can explain what the meaning of each one of them is, but my recommendation is using only Severity as mandatory field to be populated. Severity answering all aspects related to software business impacts and technical impacts.

Critical defect is impacting both consumers and software, meaning the fix is vertical and complex. High defect is impacting consumers or software. There is a thin line between Critical and High defects. My suggestion is always to check the real volume of the test case and customers data profile in real live and then to decide if the severity should be high or critical. Medium defect can be a cosmetic change or optimization of operational activities. Both are not relate to consumers or any kind or revenue issue. Low defect is almost considered as nice to have functionality.

Adding Priority information to each defect will extremely complicated the process and actual slow it down.

Define a reasonable and workable defect life cycle.
From experience, defect life cycle flow should be simple one. The most basic defect flow is including the following ordered statuses:
New
Assigned
Fixed
Delivered
Testing
Verified
Closed

In case the defect is cancelled, due to testing error, the next status will be Cancelled. In case the defect verification will not passed successfully, the next status will be Assigned.

For each company and software there are special handlings, this basic flow need to be adapted accordingly.

Produce daily or weekly defect report.
Producing daily or weekly defect report is very useful for knowing the current system stability and quality, but also and even more important is to present to all groups a list of quantified high and critical severity defects to be corrected. It is actually providing a defect correction agenda.

Perform root cause analysis and present the results.
Defect root cause analysis activity should be done at the end of each version. This activity will focus on three to five main causes for the defects. The causes are defined according to the number of high and critical defects which were reported for each one of them. Action items list for improvements should be issued and assigned to the relevant groups or persons.

For example, many defects coming from specific software change need to be analyzed. It might be a reason of unclear business requirement or not performing a code review activity. Many testing errors can indicate that the tester is not familiar with the software or test cases were not reviewed.

Correction delivery dates.
Estimate as well as accurate correction delivery dates will assist all groups to plan better the next activities.

Use wisely Show-Stoppers severity.
Until now I did not mention Show-Stoppers defect severity. The reason for that is because this severity is a special one and need to be treated differently. My suggestion is to use it only when the following three accumulated things exist:
1. The problem is in production, meaning in real live software and not in any testing software (unit test, sub system test, system tests or UAT).
2. There is no work-around to mitigate this problem.
3. The defect is impacting highly business scenarios or the software correction is complex (vertical).