Does your project count this data? (2) How much should be tested (1) -- how much should be tested as much as possible (2) -- Do not let the details go

Have we talked about statistical data for your project? Here we will add some content.

1. Bug cause category

There is only one reason for a bug, that isCodeThere is no absurd Analysis of writing errors, such as design errors or requirement errors. What will happen to the far-fetched category,ProgramIn order to reduce their responsibilities, the problem should be summarized as follows:

Inadequate design-Unclear design requirements-Requirements Analysis
Insufficient test cases-Administrator problems-he didn't give me enough time to test.

However, none of these are the real causes of the problem. There is only one reason for the bug: code writing errors.
For example, the famous bug in the binary search:

Mid = (left + right)/2; will cause a negative number when left + Right> integer. Max, leading to array out-of-bounds.

What would you do if you were asked to classify them?
-Design error-unfamiliar with basic APIs
-Insufficient Test Cases
Is three common classification methods. However, what is the significance of such classification?
If a design error occurs, will it be possible to avoid design errors in the future?
If you are not familiar with the API, will you be able to deepen your understanding of the API in the future?
If the test is inadequate, will the test be sufficient in the future?

The answer is no, because
The reason for the design error is that the time is insufficient, so the review is insufficient.
In fact, the author may know the >>> usage, but does not take into account the cross-border situation. If he is given enough time (it is said that the bug has been used for 12 years)
The reason for inadequate testing is still the lack of time.

Therefore, a code bug is a code bug and should not be attributed to other reasons. This is just an excuse for programmers to reduce their responsibilities.

2. Bug generation Phase Classification

This analysis aims to improve the quality from the upper layer. However, as long as the software engineering is divided into stages, it violates the goal of improving the quality earlier. This article will be detailed in the absurd process.

Therefore, instead of classifying the bug generation phase, consider how to remove the phase.

What's more, the data collected by each project is always similar, that is, the analysis has not been improved. What is the need for analysis?

3. Working hours distribution of each stage

Similar to the above problems, separating software development in stages violates the goal of improving quality in the early stage. Therefore, it is not necessary to count the man-hours distribution in each stage. Moreover, it is also necessary to count the man-hours. This is also an activity that deviates from the goal and behavior.

4. undiscovered causes of bugs

There is only one reason for the bug not found, that is, the test is inadequate. The purpose of statistical data is to perform classification analysis based on the causes not found in the bug, so as to improve the quality and reduce the number of bugs submitted to the customer. However, this statistic cannot achieve this goal, but it is just a waste of work hours.
Please refer to "How much should be tested (1) -- try to be comprehensive" and "how much should be tested (2) -- don't let the details go ".ArticleTo check the number of omissions in the test. In addition, the impact analysis is used in regression testing. The lazy thinking of selective tests also leads to inadequate testing.

Therefore, to minimize the number of bugs missed to customers, we should start from the following aspects:

A. Add Test Cases
B. Improve testing means-introduce automatic testing to reduce regression testing costs
C. Improve the test process-all tests are required at any time

Otherwise, the analysis of no reason for a bug is just a consolation.

5. Review problem categories

The review may be divided into several types of problems, such as style issues, logic issues, normative issues, and requirements matching. However, the significance of this classification is only to prove that many machines have done what they should do.

This point will be elaborated in the "Code Review of the flowers without looking at the horse.

There should be only one review problem: High Coupling

Style issues and specification issues are part of the work of machines, and the Requirements matching degree should not be found during review. However, logic problems are unlikely to be discovered through review. Only coupling problems can be easily found in review, and should also be found in review.

6. Document pages

This document should not be written to have certain questions, let alone to count the number of pages. In addition, the number of pages is a very unreliable concept. The font size, spacing, and frequency of line breaks may affect the number of pages in the document. More importantly, the number of pages in the statistical document is not helpful for software quality improvement or process improvement.