Release judgment criteria・Bug is considered separately to potential bugs and obvious bug

20/11/202020/10/2021Release Judgment

In the release judgment, consider the actual bugs found in the test and the latent bugs not found in the test.

Of the four criteria used when determining software release ( test quality , residual bugs , product quality , process quality ), this article will consider how to determine whether the test quality is good or bad. Gutara father is the quality of the test amount of testing and individual types of tests and test the implementation of the bug situation was watching from four perspectives of. In this article, I will introduce the situation of the fourth bug .　

By the way I found already in the test is to bug obvious bug and have not found yet potential bugs There are two types of. If you don’t distinguish between these two types of bugs when determining test quality, you’ll be confused. Then, let’s think in order about what kind of information should be used to judge the test quality of these actual bugs and latent bugs.

Where are the obvious bugs found in the test biased?

What is the status of overt bugs ? When judging the quality of the test, what kind of information should be collected and judged as the situation of the bug is written down a little more concretely as follows.

• • Are the causes of many bugs design mistakes or implementation mistakes ?
  • Is the bug concentrated on a specific function ?
  • Is the bug concentrated in the source code of a specific coder ?
  • Are there any important bugs that are taking a long time to fix ?

I hope I can always use this information, but …

It would be nice if this information could be used in all release decisions, but the reality is that this is not the case. For example , in order to know whether the cause of many first bugs is a design error or an implementation error, it is necessary to determine whether each bug is a design error or an implementation error and record it .

This is a software development management work that is different from the actual software development work . And it takes the designer and implementer’s work time to do this. This is called the software management cost . In the experience of Father Gutara, there are some software development projects for which sufficient management costs are not expected , in which case the designer or implementer only determines whether the found bug is a design error or an implementation error. There is not enough time for management work .

As a result, it becomes impossible to determine from outside the development project whether the project has many design mistakes or many implementation mistakes . People who are actually directly involved in development and testing in a development project may understand it intuitively, but people outside the project often do not understand it.

Is quality deterioration concentrated on a specific function?

The other three pieces of information may or may not be available, and this information may not always be available at the time of release decision. Therefore, if there is information that can be used among these information at the time of release judgment, it is the method that Gutara’s father has come to use as a reference when judging the quality of the source code.　

However, there are no clear procedures or methods. From these four pieces of information, the source code per which the lack of quality I wonder if there is a part that is? You can see the vague range . In the simplest example, if the bugs are concentrated in the second specific feature, that feature may be of poor quality compared to the other features. It can be estimated that .　

Then, if you can estimate that one of the features is of poor quality , check the status of the test plan for that feature, the content of the test, and the result of the test more carefully than the other features, and check the quality of the source code. Just be careful if there is a shortage.

Check if there are any bad points left in the release judgment

Checking the source code quality at the time of release judgment is basically checking whether the software to be released has any bad points, that is , whether there are any latent bugs that have not been fixed yet . As part of that work, we determine whether the quality of the resulting source code is good or bad. And, as can be said not only for source code quality but also for design quality, it is quite common in software development that problems occur frequently in specific functions and quality shortages occur.

For the first time or was a function to be mounted, internal workings are complex or was, a plurality of processing is cooperation or there needs to be, from the middle of the development added or was the specification that has been, but there are a variety of reasons and background, the specific function is It is quite common for quality to be inadequate.

Therefore, it is good to estimate, so it is rather important to estimate where the quality defect is occurring in the source code and carefully examine that part when judging the quality of the source code.

バグの確認で重要なのは潜在バグの状況

テストで見つかった顕在バグがどこに偏在してるいるのかも重要な情報ですが、ソフトのリリース判定で大切なのは、もうバグが残っていないかどうかという潜在バグの状況です。次の記事ではテストの実施結果から推定する潜在バグの状況について、グータラ親父の考を紹介していきます、興味のある方はご覧ください。