Release judgment criteria・The reliability growth curve is reasonably usableThe reliability growth curve is reasonably usable
Is the reliability growth curve estimate reliable?
If the current software has 6 potential bugs estimated by the reliability growth curve, is this value reliable ? I don’t know the answer ! is. This confidence growth curve is just a line of mathematical functions applied to the red achievements . I don’t have the wonderful ability to predict the future, such as finding a number of more bugs in the future .
Furthermore, there is no clear evidence that bug detection follows Gomberts or logistic functions . However, considering many cases in the past, there is only the rule of thumb of the ancestors that the growth curve of bugs often overlapped with the Gombeltz curve and logistic curve . In addition, if the number of bug detections and test man-hours used for input fluctuate, the shape of the growth curve applied to the actual value will also change.
Can you trust such a thing?
How about? Do you trust the reliability growth curve or the estimation of potential bugs by the bug growth curve ? Do you think it’s like Bagua’s eyebrows? Father Gutara relied quite a bit on the estimation results of this reliability growth curve and used it as one of the important information when deciding the release of software .
Judgment of nearly 100 software releases per year There is no basis for making this reliability growth curve, but the quality of the software at the time of release, that is, the rate at which bugs are found in the production operation of the market after shipment, and the reliability You can get a feeling that there seems to be a sufficient correlation with the estimated status of latent bugs shown by the growth curve .
In addition, the amount of quality and testing of the test, where found, such as the status of bug number and bug fixes, was determined from the lot of the collected information source code quality with the situation of, indicated by the reliability growth curve estimation of potential bugs and , It often fits sensuously .
In the first place, the situation at the time of release judgment is that we want to somehow estimate the future situation where no one knows what is essentially correct, the number of potential bugs that may be discovered in the market . Therefore, the reliability growth curve, which estimates the number of potential bugs that have not been found yet in a graph, is a very nice tool.
And the future indicated by the reliability growth curve estimation, was collected in a different way deduced from the fact that it has been found up to now is the quality of the source code situation and of matching split that often can be convincing as their own If you have a lot of experience, there is no reason not to use it as one piece of information for release judgment.
It looks great when you decide to use it
Well, what did Gutara’s father do when deciding the release is that the reliability growth curve is in the same line as other information, and it is positioned as one of the important information to judge whether it can be released . In particular, the release judgment was not made with the reliability curve as the most important information.
However, when creating materials that explain the good quality of software released to customers and internal management, we use this reliability growth curve graph first.
There are various other information and I will make a table, but the appealing power of this graph is outstanding. Of course, the reliability growth curve used at that time is such a graph showing the situation where bugs have been detected sufficiently and there are almost no remaining bugs.
The appealing power to explain that the quality of software is good
It is quite convincing to show this graph and say that it has reached a quality that can be estimated that there are no new bugs left after thorough testing .
From a different point of view, if bug detection has not converged to this level, there is a risk of potential bugs at the time of release . In that case, it is necessary to carefully judge the release including other information, considering that there is a high risk that the quality of the source code is inadequate.
This is not the correct answer
How was it? It is the quality of the source code, which is the most important factor that determines the quality of software, so it is necessary to collect various information and make a multifaceted judgment. Of course, we also need to look at it from a greater perspective than Father Gutara did.
The above is just an example . You can draw an ideal form, but in the scene of release judgment that is conscious of the market principle of work efficiency and release timing as a company’s business, various choices are required, and the judgment standard depends on the maturity of the organization and the market. It will change .
Therefore, there is no right answer that applies in any case . Judgment criteria must be decided by each company and the person in charge of judgment. I hope that the experience of Father Gutara will be helpful when you can make your own judgment criteria.
By the way, what if there are any remaining bugs?
So far, we’ve been thinking about the bugs we found in our tests. By the way, are all the bugs found in the test fixed at the time of release? Have you ever missed a fix and still have bugs when the next release comes?
Ideally, it would be nice if we could release the software after all the bugs were fixed, but it’s normal for a big valley to lie between the ideal and the reality.
I have to release it, but there are still bugs, so let’s introduce in the next article what my father Gutara was doing when he decided to release it.