Release judgment criteria・Estimate the number of call center calls from the remaining bugs(3-rd)

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

Estimate how many call centers will be called in a month due to residual bugs

The previous two articles and this article show you how to estimate and calculate the number of phone calls to the support center due to residual bugs. This is the way of thinking of Gutara’s father that even if there is a residual bug at the time of software release judgment , the release of the software is approved with little influence on the service provision according to the purpose of the software. Now, let me introduce one more point to keep in mind when using the number of phone calls to the support center introduced in the previous article to determine whether or not to release.

If there are multiple remaining bugs, add up the number of phone declarations

It’s rare that there is only one bug left in the software to be released. If multiple bugs remain, perform an estimated calculation for each bug and add up the estimated number . Then, if the total estimated number exceeds a certain value, it should be judged that the release cannot be performed.

Is this all right? Do you feel like you have forgotten something a little important?

Here’s one more thing to keep in mind when using it.

Bugs also affect service delivery

You can use the formulas described so far to calculate the estimated number of filing calls to the support center per month. What am I missing? In such a case, it is easy to understand if you think about it with a concrete example. Let’s take software for online games as an example and sort out some problems that occur in the market.

(a) There are 300 calls in January stating that you cannot log in to the game.

(b) There are 300 calls a month reporting that the rock design in the background of the lower right corner of the screen is broken.

In both cases, the estimated number of filing calls per month is 300, but if the problem of (a) not being able to log in occurs in the market so much, stop releasing the software with this bug and complete the bug fix version. It seems better to wait. However, if the rock in the background of (b) has collapsed, it seems okay to release it. That’s right, it is necessary to decide whether or not to release it, taking into consideration the impact of problems caused by residual bugs.

It seems that it is good to decide the judgment value of release availability for each degree of influence

Again, significant / important / Normal / for the service provided that the minor was considered before a little degree of influence use the physician. The idea is to set an upper limit on the number of calls to the support center for each degree of impact, and determine that the release cannot be made if the upper limit is exceeded.

For example, make a table like this. As always, there are no useful theories or precedents. There is no choice but to make a quick decision in consideration of the natural quality required by the market.

Release judgment table based on the estimated number of reports to the support center for each degree of impact

 

Impact	Estimated number of filings that can be released	Estimated number of declarations that can be released by special recruitment	Estimated number of declarations that cannot be released
Serious	0 cases / month	0 cases / month	Number of cases exceeding 0 / month
important	0.2 cases / month	0.2 cases / month to 0.5 cases / month	0.5 cases / month exceeded
generally	Less than 1.0 cases / month	1.0 cases / month to 10.0 cases / month	10.0 cases / month exceeded
Minor	Less than 30 cases / month	30 cases / month-100 cases / month	Over 100 cases / month

The following is a bulleted list of how to determine the release due to residual bugs using this table .

• Classify residual bugs by impact　
• Calculate the estimated number of calls to the support center using a formula for each bug
• Add up the calculated estimated number of filing calls for each degree of impact
• Apply the total value to the above table to determine whether or not shipment is possible for each degree of impact.
• Of the judgments for each degree of influence, the strictest judgment (closer to the one who cannot release) is the judgment of whether or not to release.

Let’s consider a concrete example. Suppose the game software has the following number of remaining bugs.　

1. Impact = 0 serious residual bugs
2. Impact = 1 important remaining bug
3. Impact = 3 normal remaining bugs
4. Impact = 12 minor residual bugs

Let’s assume that the estimated number of reported calls due to each remaining bug is calculated, and the total value for each degree of impact is as follows.

• Impact = Estimated number of reported calls due to serious residual bugs (total value) 0
• Impact = Estimated number of reported calls due to important remaining bugs (total value) 0.001 / month
• Impact = Estimated number of reported calls due to normal remaining bugs (total value) 1.3 / month
• Impact = Estimated number of reported calls due to minor residual bugs (total value) 8.5 / month

In this case, the estimated number of residual bugs with heavy impact and usually minor impact is within the range that can be shipped, but the estimated number of residual bugs with important impact is within the range that can be shipped by special adoption. Therefore, it is judged that this software can be released if it is specially adopted. In addition, special adoption by “software release for, so we described in another article, there also visit.

What do you think? This is the method that Gutara’s father used to judge whether or not to release due to a residual bug . It’s been a long time, but the people who have read this far have really had a hard time. I hope it helps you think about residual bugs when deciding on a release.

Next : Release judgment criteria ・To check the product quality, first check the design quality