Introduction
In this article, we studied Shortcuts to achieve “cost, delivery time, quality” by testing from the upstream process. However, in software development, the cost of quality improvement can be much higher than the development cost. For example, just before the release, many fatal defects were discovered, and it took a lot of effort and time to analyze and fix them, and so on. is. Or, the news that a large-scale system failure occurred and caused great damage is reported every day. The cost of fixing them and getting them up and running will not be expected by the development project.
To reduce the cost of improving the quality of deliverables, it is necessary to detect and correct defects in the upstream process, which is the initial stage of development, and reduce rework in the development process. This time, we will introduce the merits of detecting and fixing defects in the upstream process of software development, as well as the process rework and cost.
“Upstream process” is the key to software development
Here, let me explain the “upstream process” in the development process.
Generally speaking, the upstream process refers to the process performed in the initial stage of development in the flow of the software development process. The upstream process explained in this article is a development process that performs everything from software development requirement definition to detailed design. For details, see the column on V-shaped models and W-shaped models (link at the end).
Why is the upstream process so important?
In most software development settings, the upstream process is more important than the downstream process. Why is it so important? The reason is that if an error occurs in the upstream process, it will appear as a defect in the downstream process later, and the cost will increase due to the delay of the development schedule and the rework of the process. The Information-technology Promotion Agency (IPA), an independent administrative agency that supports the Japanese IT industry, has also communicated the importance of upstream processes through the publication of guidebooks and lectures at symposiums, but it was caused by upstream processes. The current situation is that project failures have not disappeared due to increased rework costs.
Development project failure case
From here, we will introduce examples of project failures caused by upstream processes. It was a project to develop a search system for companies. The system test went smoothly, but at the stage of the user test process, there was a specification change to add some search keys to the data search screen, so we extended the schedule and revised the program. After that, it was delivered safely, but after the actual operation, the user complained that the online response was too slow to be usable. As you can imagine, the cause of the poor response was a specification change in the user test process. At the system test stage, we conducted a performance test with a large amount of data and confirmed that there were no problems.
However, after the user test after that, we focused on checking the functionality, so we did not test using a large amount of data, and we could not detect the deterioration of the response due to the specification change. The root cause of this problem was “insufficient specifications created in the upstream process”.
In this way, if a “specification omission” occurs in the requirement definition at the initial stage of development, it will appear as a defect or specification change in a later process. As a result, unplanned correction work will be required and development costs will be incurred. In addition, the schedule will be delayed more than expected. In this case, a defect was discovered after the release, which led to a complaint. In some cases, it may lead to postponement/cancellation of the release of the deliverable or suspension of system operation.
Shortcut to achieve “cost, delivery time, quality” by testing from the upstream process
Relationship between “rework” and “cost”
Software development proceeds in the order of requirements definition, design, coding, and testing.
However, if you move to test and find a bug, you must go back to the required stage and fix the bug. The more such rework, the more correction work. As a result, development costs are high and enormous costs are incurred.
Prevent rework by early detection of “defects”
The test process is usually done after coding. However, by performing “testing” at the design stage, which is the upstream process of development, it is possible to prevent omissions in requirement definitions and design specifications. The “test” here is not a “dynamic test” that is performed by operating the software, but a viewpoint of whether it is possible to make a product that is useful to the user by reviewing the requirement definition document and design specifications. This is a “static test”, which is a review conducted in.
A careful review will result in a slight increase in man-hours, but finding leaks in software specifications in the upstream process can reduce process rework and reduce overall man-hours. In addition, since it is possible to prevent the occurrence of rework processes, it also leads to improving the quality of software from the early stages of development.
In addition, it is possible to prevent unexpected work from occurring in the downstream process and prevent “software release delay”.
In other words, conducting tests from the upstream process can be said to be a shortcut to achieving the “cost, quality, and delivery time” of software development.
Existence of a test engineer
Software testing is essential for software development.
Then, what is the existence of a test engineer who specializes in software testing? Here, I will introduce the existence of a test engineer while looking at the case of Project A.
In Project A, the test engineer created a test case for the integration test to be performed in the downstream process at the stage of basic design, which is the upstream process, and then implemented it.
Then, after the person in charge understands the matters to be verified, detailed design, programming, and unit test are performed, so defects can be identified very efficiently, and 90% or more of the defects to be detected in the integration test are designed and implemented. Detected before the phase. Since the defects were almost detected by the unit test, the cost of the correction expected in Project A was reduced and the quality was improved.
As you can see from these cases, it is important for test engineers who have specialized expertise in software testing to be involved in the upstream process of the project.
In particular, engineers with high test skills, such as specialized companies that perform “third-party verification” to evaluate software quality, are indispensable for improving software quality.
In conclusion
This time, I introduced that it is important to detect defects in the upstream process in software development.
Correcting defects in the upstream process of software development reduces work rework from the downstream process, resulting in cost and man-hour reduction. Therefore, the involvement of test engineers from the upstream process of software development seems to increase the man-hours, but when the entire project is carried out, it brings many benefits such as cost reduction and man-hour reduction.
Of course, not all defects found and fixed in the downstream process are eliminated.
However, the fact that many defects that should be detected in the upstream process are detected in the downstream process may be because the failure of the software development project is not eliminated. In software development, it can be said that many development sites are required to take measures against defects from the upstream process.
If you ever want to know about similar things, check out the Facebook page Maga Techs
