Test type・Unit tests, integration test and system test　

02/09/202020/10/2021Test qualityy

ページの概要

System test is a test to find the condition that the software does not work

All functions are built into the software, and when the unit test and integration test are completed, the system test is performed at the end. If the software scale is small, the integration test may be omitted, but the system test will not be omitted. In the case of software that has only small-scale bug fixes, it may be sufficient to confirm the correction and the basic function confirmation test (sometimes called sanity test), but in the case of new development or additional function development, it may be sufficient. , System testing is mandatory.

Since system testing requires man-hours and large-scale test technology required for test environment preparation and testing, it is often conducted by a test team that specializes in testing separately from the software design and implementation team. If the quality assurance department has a function to guarantee the quality of software, the test team may belong to the quality assurance department, and if the quality assurance department only looks at manufacturing quality, the software Since the quality of the product is guaranteed by the design department, the test team will also belong to the design department.

There are various ways of thinking about the purpose of system testing, but if the purpose is to find out when software does not work with embedded software, it will be easier to design and execute system tests. What it means to find a case where the software does not work is in the production environment where the software is actually used , such as some input value , input timing , operating environment , load conditions, and cooperation with other systems. Assuming various situations that are expected to occur, the situation where the software does not operate normally = finding potential bugs.

We conducted a system test aimed at finding out when the software did not work, and if some bugs were found, it was that we found a latent bug that could not be found in the previous unit test or integration test environment or test method. If no bugs are found in the system test, it means that there were no bugs in the test assuming the production environment, so the quality of the software is guaranteed.

Test management using a test plan is important for system testing

Since the scale of a system test also increases, it is important to make a solid test implementation plan and proceed with the test work while managing the test . In the system test Who , when , what equipment and how the test environment or to carry out any test using a test that the schedule adjustment of resources and not firmly, here and there in the practice waiting for the test will happening. Also, if system testing starts with insufficient software quality, the test will not proceed due to a bug, and a mass of tests will not be touched until a bug-fixed version of the software is released. There will also be delays in processes that are not planned . Therefore, in system testing, it is important to manage the progress by constantly checking the actual progress of the test while looking at the test implementation plan and reviewing the implementation plan if necessary .

In the test design of system test, it is designed with the idea that necessary design is done according to various test purposes and the test is carried out without omission. ( Sometimes called a descriptive test as a companion word to an explosive test .) However, if you proceed with test design for the purpose of finding out when software does not work, you will need to consider various combinations of environments and conditions. Then, the test case will explode immediately .　

In the test design to identify the test cases, the work of discarding less necessary combinations is also carried out so that the test cases do not explode, so there remains a risk that the test cases will not be comprehensive . In such cases, you can reduce the risk as much as possible by incorporating an exploratory test into the area of concern . Therefore, it is a good idea to include exploratory tests at a certain rate in system tests.

The result of the system test is the discovery of latent bugs and the absence of bugs.

Since the purpose of system testing is to find out when software does not work, the result of system testing is the discovery of potential bugs . However, since system testing is also the final stage of design verification testing, it often serves as a proof that there are no potential bugs left , in other words, as a basis for quality assurance .　

In this case, multiple system tests are performed. In the first system test , latent bugs are found, and the found bugs are fed back to the design department to complete the debug cycle to remove the bugs . After running the debug cycle several times and fixing the bugs sufficiently, the system test is performed again at the end to confirm that no bugs are detected , and the software quality is guaranteed and the release review is carried out. We may also perform a two-step system test. Of course, in the case of a development project where it is not possible to spend time and man-hours on systematic testing, only the bug-fixed version of the software is checked for corrections and secondary bugs, and the software is released. Sometimes we use the method of proceeding to the judgment.

The actual system test is in the death march

So far, we’ve written about ideal system testing . However, in an actual development project, it is not often possible to carry out such an ideal system test. In such an ideal scene almost no Unfortunately, in Gutara father of experience, in most of the software development storm of the specification change suffered, but still the original does not change the delivery time of the design and implementation in Tae process down behind become At the beginning of the system test, all the functions have just been implemented and the integration test has not been completed yet, but the delivery date is near, so it is often in the middle of the death march that the system test must be started from now on. It is.

Therefore, in the first half of the system test, a lot of bugs in the normal system test and bugs in the simple conditions of the quasi-normal system and the abnormal system were found, and a large number of bugs were fed back to the design department and the bugs were fixed. The situation is that the system test is repeated at. In this situation, it is correct to say that it is actually a system test , but it supports the debugging work in the previous stage from the aspect of testing, but in the project that entered the death march, there is no time to say such a thing, and everyone The only way to go is to fight the bugs as a whole.

Well, even in the Death March project, if you repeat the bug fixing cycle several times, the quality of the software will gradually improve. Then, in the second half of the system test finally, a bug that occurs in the combination of complex conditions and, bug that occurs only at the time of the high load and, bugs happen to be moving for a long time in the noise environment , such as corresponds to the case where the software does not work Bugs start to appear here and there. At this point, we’re at the stage of repeating bug fixes and system testing as time permits to improve quality for release, and we’ll see the long death march exit.

So far, I’ve written about the names of tests that are in line with the development phase. In the next article, we will introduce normal system test, abnormal system test, and normal system test.