Release judgment criteria・Check the development management process by the design, implementation, and test plan

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

Next to development planning is design, implementation and test planning, which is the core of development practice.

In the previous article, we introduced how to judge the quality of the development plan among the six important development management processes for judging the quality of the development management process by the release judgment, so this article continues the design. And introduce the implementation and test plan.

2. See Managing Reviews for Software Design and Implementation

If you’re happy with the development planning process, the next step is to review the design and implementation management process. The design and implementation process is the core of the software development business, but in reality, there are not many items that can be confirmed from the perspective of confirming process quality. There is only one management aspect: review planning and performance .

Software development is the work of writing out what the person in charge (that is, a human being) thinks in his or her mind , whether it is design or implementation, in natural language or computer language . Since it is something that humans think, it is possible that there are mistakes, and that the writing is bad and the meaning is misrepresented . To find such a mistake modification to the, design reviews and code review is. I don’t think the importance of this review needs to be reiterated, but the quality of this review is very important in terms of design and implementation process quality .

It is important that the planned review was carried out

For design reviews and code reviews, the review target (which design document or source code to review) and the review density (how many times to review) are planned at the beginning of development. The plan for this review target and review density may be decided according to some rules, or it may be decided based on the experience and intuition of the development leader.

It doesn’t matter how you decide, the result of the decision is the technical ability that the software development organization can develop for this development project.　What is important from the perspective of the software development process is that the originally planned design reviews and code reviews were properly implemented as the development project progressed, and the results were used effectively . That is the point.

To be more specific, is there any problem with design review and code review in the following points?

• Was the review conducted on the originally planned design document or source code?
• Was the review initially planned and involved by development leaders and experienced developers?
• Is the matter pointed out in the review recorded in any way?
• Are all the points pointed out in the review finished?

The first and second are to make sure that the planned review has been carried out properly . If the process is delayed due to the end of development and the delivery date is approaching, the review may be postponed or omitted due to process recovery.

Often, the reviews that we initially thought were necessary were those that were really necessary, that is, reviews that were prone to mistakes in design and implementation. At the end of development, the lack of these reviews due to deadlines increases the risk of potential bugs being overlooked and quality degradation as a result. Failure to implement the original plan increases software quality risks.

The next important thing is whether the points of the review are dealt with to the end

The third and fourth are to make sure that the items pointed out in the review have been dealt with without omission / forgetting . The purpose of the review is not to carry out, but to deal with the findings and eliminate potential bugs. If you point out in the review but forget about the subsequent response, the time and man-hours spent on the review will be wasted.

To prevent this from happening , it is very important to keep a good record of the points pointed out in the review, respond to each pointed out item after the review, and confirm that all the measures have been completed . .. It’s okay if some of the responses include a response that was pointed out in the review but that you can conclude that there was no problem when you revisit it. In short, all if out is some kind of conclusion to the findings of hand So it is good.

3. 3. Next to design and implementation is test planning

After designing and implementing, check the contents of the test plan. Here, we will check from the perspective of whether the necessary things are properly written in the test plan as well as the development plan .　

It is assumed that there is a test plan, but even if the project does not have a test plan, as long as the test is being carried out , look at the list of some test items or the test procedure manual. , It is possible to make the same judgment. However, it is better to have a test plan, so please make a test plan.

By the way, there are various ways to write the test plan, but the following items are indispensable items in most test plans, so check from the perspective that these are written concretely without omission. increase.

• Test target and environment
• Test category and purpose
• How to record and trace test results

Is it clear what to test first?

First of all, the test target and environment , but if this is not clearly set, the result cannot be used even if the test is performed. For example, if you test using Ver2.3 to release Ver.2.5, you cannot use it to judge whether the quality of Ver.2.5 is good or bad.　First and foremost, it is necessary that the name and version number of the software to be tested are specified. Also, for example, even if you run the software used on Windows 10 on Windows 7 and test it, it is difficult to judge how much you can trust the result. In order to make the test results valid , it is important that the test environment of the test equipment to be used is clarified in addition to the operating hardware and OS .

It is quite natural, and when conducting tests, it is unlikely that you will make a mistake in the version of the target software or in the test environment. It seems that you don’t have to bother to check it.

However, it is the first item that needs to be decided at the test planning stage . The test policy changes depending on whether it is a major version upgrade release or a minor version upgrade release. The content and duration of the test will vary depending on the test environment that can be used. If this is not clearly stated in the test plan, the test plan itself will be unreliable.

Next, is the purpose of the test appropriate and is there any omission?

Next is the test category and the purpose of the test . The word test category may be unfamiliar to some people, but in Japanese it is the type of test . Specifically, it is a term that refers to the type of test, the classification of tests, or something like that, which is named by classifying tests according to purpose, such as functional tests, high-load tests, and large-scale tests.　

In other words, a test category can be called a test classification name created according to the purpose of the test . For example, the test category called high load test is a classification name of tests aimed at confirming that the product operates normally even when a high load is applied. Therefore, checking the test category and checking the test purpose are almost the same thing.

And in the test plan confirmation, what test category (that is, the purpose of the test) is the test planned? We will confirm the test contents from the viewpoint of. There are various categories of test categories, but among the following test categories, it is necessary to check whether the tests of the category required for the product are planned.

Does the test category include such types?

• Functional test: Confirm that the function described in the specification is realized.
• Performance test: Confirm that the performance described in the specifications is obtained.
• Large-scale test: Confirm that the function works with the maximum configuration described in the specification.
• High load test: Confirm that the function is provided even when the product is under maximum load.
• Recovery test: Confirm that even if an abnormal condition occurs, it will return to its original state when the cause of the abnormality disappears.
• Stability test: Confirm that it continues to operate normally even after long-term use
• Maintainability test: Check the function of defect investigation and recovery
• Large-capacity test: Confirm that large-scale data is processed normally even if it is input.
• Document test: Confirm that it works as described in the instruction manual
• Compatibility test: Check compatibility with older versions (only when compatibility is required)
• Security test: Check for vulnerability and resistance to cyber attacks

Are test results properly recorded and managed?

Finally, how to record and trace test results . The results of the test will be recorded in some way, including pass / fail, and will eventually be compiled into a test report . What we need to check here is not this test report, but the recording and management of bugs found in the test.　

The purpose of the test is not to create a test report. Either find potential bugs and run the debug cycle, or guarantee quality with no bugs . Of particular importance to software development projects is the goal of finding potential bugs and launching debug cycles. To achieve this goal efficiently , you need to clarify in your test plan what to do when you find a bug .

How to run the debug cycle, such as what to record the bug, what kind of information to record, who to contact the recorded thing at what timing, who is in charge of checking the reproducibility of the bug, etc. Must be fixed.

At the same time, you need to know how to trace subsequent work on the bugs found . The cause of the found bug is investigated, the necessity of correction is determined, the source code of the bug that needs to be fixed is corrected, the fact that the bug has been fixed is confirmed by retesting, and the corrected content is correct. When is confirmed, it will be registered in the master tree of the source code, reflected in the next release, and finally the debug cycle will end .

This, the end of the debug cycle for the first time and arrived until, eye to find potential bugs in the test is achievement will be. If you can’t trace the progress of your work until you get there, the bugs you find can be overlooked without being fixed. To prevent this from happening, it is important that the test plan also describes how to trace the bugs found afterwards.