Overview・Four criteria for release judgment
- 1. Release is judged by four factors: test quality, residual bugs, product quality, and process quality.
- 2. Test quality is determined by the implementation and bug situation the amount and type of test to
- 3.
- 4. Residual bugs are judged from the degree of impact on service provision in the market
- 5. For product quality, see the quality of the design document and source code.
- 6. Process quality is judged by looking at the development process and management process
- 7. See individual articles for a little more detail
Release is judged by four factors: test quality, residual bugs, product quality, and process quality.
Release to the quality of the software either it is good or bad, how do judgment Will is good to. For nearly 20 years, Gutara’s father has made software release judgments (shipment judgments) as part of software quality assurance work. After a lot of trial and error, Father Gutara finally judged the quality of the software based on the following four ideas , and approved the release of the software that was judged to be not so bad that the quality was below the standard. I have made a release judgment by the method of doing. These four criteria will be explained in order from the next page.
- Judgment of test quality (Is the test performed in sufficient quantity and quality?)
- Judgment of residual bugs (If residual bugs remain, does it cause a problem in actual operation?)
- Judgment of product quality (Is the quality of development products including design documents and source code good?)
- Judgment of process quality (Is the process used for development good?)
In addition, please refer to another article for the judgment mechanism for implementing software release judgment .
Test quality is determined by the implementation and bug situation the amount and type of test to
First of all, the quality of the test seems to be easy to understand at first glance, but it is quite difficult to decide what to measure to judge the quality of the test. I couldn’t find anything like the theory of the test that this was the correct answer, so Father Gutara looked at the quality of the test from four perspectives .
The first is the amount of testing . Determine whether the amount of tests was sufficient from the two perspectives of planning and actual results: how much test was planned and whether the test was actually carried out as planned.
The second type of test is not only the function confirmation of the software , but also the test from the viewpoint of whether the test is performed in terms of performance, stability, robustness, conformity with documents, abnormal recovery, availability, etc. Check the type of. To do this, check the types of tests, including how to classify the purpose of the test, what kind of test is to be performed according to the purpose, the environment for the test, and the management of bugs found in the test. I will continue.
The third is the test implementation status . It is good if the test goes according to the work plan, but in reality, the test often stops and does not go according to the plan. Why does the test stop? A common situation is that there is a serious bug that prevents you from proceeding with the test.
Such bugs were called test blockers . If you have one or two test blockers, you can adjust the test work plan so that it will not be delayed by rearranging the order of the test work. However, if a test blocker is found here or there, there will be no more tests that can be performed, and the tests will not proceed there. As a result, test work is delayed. On the contrary, if the test work seems to be far behind the plan, it is very likely that there were many test blockers and the software was not of good quality.
The fourth is the status of the bugs found in the test . See the test results from various perspectives , such as how many bugs were found in the test, what purpose the test found many bugs, whether the bugs have already been found, whether the found bugs have been fixed, etc. By doing so, it will give you useful information to judge the quality of the software.
Residual bugs are judged from the degree of impact on service provision in the market
Next is the status of residual bugs . Of course, it’s ideal to have zero residual bugs, but unless you have very small software, zero bugs is impractical. The existence of latent bugs that have not been found in the test is estimated from the bug convergence curve, but unfortunately there are residual bugs that have already been found in the test but have not been fixed in time by the time of shipment (release).
Is it okay to release the software with residual bugs ? That being said, it shouldn’t be released in the ideal theory, but if you say that, you can’t release it forever with large-scale software. The fact that is, software that there is a residual bug to, whether good to release? The reality is that you have to judge in some way .
What should I do? Father Gutara has estimated whether the remaining bugs are likely to interfere with the provision of services in the market, and if it is low, it is okay to release it. To put it a little more extreme , the idea is that even if there are residual bugs , if the function is not used at all in the service provision in the market , it will not cause any problems in the market .
The specific content of the judgment of residual bugs in the release judgment is described in the article titled [Criteria] Judgment of residual bugs in this article of the classification of release judgment .
For product quality, see the quality of the design document and source code.
Product quality is the quality of design documents and source code created as a product (output) of software development . There are various ways of thinking about software development, but if you look at software development with a focus on development work, a requirement specification that states that you should develop such software goes to development work. It becomes the input of. Software intermediate products that describe the software configuration and internal functions that satisfy the required specifications in a natural language that can be understood by people such as Japanese and English are design documents of various levels .
The source code written in the computer language according to the design document and the execution code created by building the source code are the final products of software development. Ultimately, the quality of the executable code is important, but as long as there are no bugs in the compiler, it is not a big mistake to think that the quality of the source code = the quality of the executable code. Therefore, in general, we consider the source code as the output of development work and aim for good quality of the source code.
Product quality means the quality of design documents and source code , which are the deliverables (outputs) of this software development work .
There are also various ways to judge whether the quality of the design document and source code is good or bad. But the most intuitive and easy-to-understand thing is whether there are many or few mistakes . Mistakes in the design document appear as points to be pointed out in the review of the design document . Mistake of source code, code review in the findings and test found in the bug will appear as. You can judge whether the product quality is good or bad by looking at these reviews and the status of bugs .
The specific content of the product quality judgment in the release judgment is described in the article titled [Judgment Criteria] Product Quality Judgment in this article in the category of Release Judgment . As for product quality itself, there are many items to consider in various ways, so we will set up another classification and explain it in more detail.
Process quality is judged by looking at the development process and management process
Process quality is the quality of the software development process (development procedure). Unlike product quality, it may be a little unfamiliar, but if you think about it for a moment, you will notice that the development process also has good and bad quality. When considering the quality of this development process, it is easy to understand if the process is divided into two types.
The first is the process for developing the software itself, such as software design, implementation, and testing . You might call it a direct process . How to design, implement, implement, test design, test execution, how and how often to review each intermediate product design document, if not approved, proceed to the next work What kind of process should be adopted as a bad gate process is a direct process.
The second is the process of managing software development so that it goes according to plan . By the way, what is management? It’s a word I often use, but isn’t it a little confusing when asked to explain what it means? Management ,, and plan to make a, whether the proceeding according to plan, monitor and, such as close to the planned value when I deviated from the plan, take the measures is a series of work called. In fact, the three things other than the well-known Plan, Do, Check, Action, and Do (implementation) are management.
Making a plan means setting goals and writing down specific ways to achieve them, so it’s a schedule goal, a development cost goal, a performance goal, a quality goal. And there are various goals. No matter what your goals, it usually doesn’t go according to plan without a management process of planning, monitoring performance and correcting deviations from the plan . So management is a fairly important process.
Process quality is the quality of these two processes, the direct process of software development and the management process . It is possible to judge whether the process quality is good or bad from the viewpoint of what kind of process is adopted, whether the adopted process is steadily implemented, and whether the process implementation result is good.
See individual articles for a little more detail
There are various methods for determining the release. Depending on the product, the market, and the corporate culture, the requirements such as the definition and purpose of release judgment will change. What is written here is just one example, but I hope it will be helpful when you think about release judgment.
If you would like to know more about the software release judgment criteria, please return to the release judgment top page displayed by the release judgment link at the top of the article and see each article. You can also follow the individual articles about the criteria in order from the links below, so even if you read from here, you will reach the same article.