After the staged testing is complete, have you performed defect analysis?

In recent years, everyone has been talking about retests, and of course testing needs to be retested.

Mumu recommends to do a defect analysis after the phased test work is completed, and use objective data to analyze the existing problems during the review. It is no longer to express subjective feelings, but to let "data speak", therebypropose improvement plans.

The following content will take last year's annual defect analysis report as an example to share several dimensions of my defect analysis.

Product line as dimension

Statistical analysis of defect data

If we need to participate in the testing of multiple product lines during the testing process, we can use the product line as the dimension to count the defect data, and through the comparison statistics between the product lines, we can take corresponding improvement measures in the later testing process.

Example:

Product lines with poor self-test conditions can ask R&D personnel to strengthen self-test;

Product lines with a large number of defects can increase investment in testing resources;

Product lines with high change rate can be fed back to the person in charge of the corresponding product line to strengthen change management control.

The following screenshot shows the defect analysis list:

Subsystem or submodule as dimension

Statistical analysis of defect data

We can also use the subsystems or sub-modules of a single product line as a dimension to count defect data, as shown in the following screenshot:

dimensioned by defect level

Statistical analysis of defect data

Analyze the defect level as the dimension, which can reflect the product's self-test status and the quality of the test, as shown in the following screenshot:

dimensioned by defect type

Statistical analysis of defect data

Analyzing the defect type as the dimension can reflect the main defect types of the product, as shown in the following screenshot:

dimensioned by defective keywords

Statistical analysis of defect data

Analysis with defect keywords as the dimension can reflect the high-frequency defect types of products, as shown in the following screenshot:

Of course, there is also a very important dimension to count the defect data in the human dimension:

For example, product personnel can count their demand change rate, number of design defects, number of delayed defects, etc.;

R&D personnel can count the total number of solved defects, secondary defect rate, defect activation rate, etc.;

Testers can count indicators such as the effective number of defects, the effective rate of defects, and the removal rate of defects.

Data can only be used as a reference to objectively reflect existing problems, and it is not recommended to directly use it as an evaluation indicator for personnel performance.

Because the number of defects reported by different products and different testers varies greatly.The main purpose of defect analysis is to reflect the actual problems with objective data, and to put forward suggestions for improvement on the deficiencies. Only with continuous improvement can product quality be improved.

Now I invite you to join our software testing learning exchange group: [746506216], note "join the group", everyone can join togetherDiscuss and communicate software testing, learn software testing techniques, interviews and other aspects of software testing together. There will also be free live classes to gain more testing skills. Let's advance Python automated testing/test development together and move towards a high salaryroad.

Friends who like software testing, if my blog is helpful to you, if you like my blog content, please "Like", "Comment" and "Favorite" with one click!