Test type・Is the test for debugging or for quality assurance?　

16/10/202021/10/2021Test qualityy

Whether to find bugs in the test or guarantee that there are no bugs

Software testing can be broadly divided into two types: testing for debugging software and testing for guaranteeing the quality of software . Both are the same test, and the main purpose of the test changes depending on the time of execution, but if the main purpose changes, the focus on the design and execution of the test will also change.

In the test for debugging, we will improve the quality of the software by finding out the latent bugs by that means and removing the found bugs from the source code by debugging work . In the quality assurance test, we perform tests from various points of view, and since no bugs are found no matter how much we test, we guarantee the quality of the software by assuming that there are no latent bugs left in this software. To do.

The tests for debugging and the tests for quality assurance are the same tests, so if you don’t organize them well, your thoughts will be confused. In this article, I will introduce how to organize these two tests and points to note that Father Gutara was doing.

The first half of the test is for debugging and the last half of the test is for quality assurance

From the point of view of test execution time, the test for debugging is executed from the time when the unit test is started to the middle of the system test, and the test for quality assurance is executed toward the end of the system test . From the perspective of who will perform the test, the test for debugging is often performed by the software engineer who designed and implemented the software, but the test for quality assurance belongs to a team specializing in testing. It is often done by engineers .

Both the test for debugging and the test for quality assurance are software tests, so there is no difference in the test process such as test design and test execution. However, since the main purpose of the test is different, the points to be noted differ slightly depending on the content of the test design .

Testing for debugging focuses on efficient detection of bugs

In testing for debugging, it is important to run the debug cycle efficiently . You need to plan your testing process so that you can find many potential bugs as early as possible and preferentially debug the most important bugs . However, the number of potential bugs decreases as the debug cycle progresses, and finding new bugs becomes increasingly difficult. Therefore, it is a good idea to change the way you proceed with the test as the debug cycle progresses from the first half to the middle and the end.

In the first half of debugging, the normal system and the quasi-normal system are comprehensively covered.

There are still a lot of potential bugs in the first half of the debug cycle, so testing will find them tattered and buggy. In some cases, a bug can cause a test blocking situation, such as a bug that prevents you from proceeding to the subsequent testing process . Therefore, at this time, it is important to comprehensively test normal and quasi-normal systems , find bugs that are easily found, and remove them by debugging. The reality is that you can only test in the middle of the game or later by fixing bugs that are easy to find and ensuring a certain level of software quality that can withstand the test.

From the middle of debugging, increase the detection rate by exploratory test and combined operation test

Most of the bugs that can be easily found in the middle of debugging are exhausted. This is the most important time of testing to identify potential bugs that can significantly affect software quality, such as stability and robustness .

At this time, bugs that occur depending on the timing of various processes and bugs that occur when various conditions are combined remain as potential bugs. If you try to cover a combination of timing and conditions, the number of tests will explode, which will result in a huge number of tests, so it is not possible to perform an exhaustive test.

Therefore, during this time, use exploratory tests and combined operation tests to find bugs that depend on a combination of timing and conditions as efficiently as possible.

What are exploratory tests and compound behavior tests?

Exploratory testing is simply a test method in which a test engineer searches for a bug by considering the operation timing and execution conditions that are likely to cause a bug in light of past experience while proceeding with the test. .. Software bugs are often hidden in places where internal processing switches the way something is processed. A skilled test engineer uses experience and intuition based on the movement of the device and the movement of the display to sniff out the timing and conditions for switching some processing inside the software, and identify bugs.

The combined operation test is a method of finding potential bugs by executing two or three processes that are likely to be related at the same time . For example, if there is a process to read the state of XXX and a process to rewrite it, these two are executed at the same time. Since the combined operation test is a combination test depending on which process is selected, if the number of combined processes is increased to three or four, the number of tests will increase to the extent that the combination of conditions cannot be covered immediately. Therefore, it is necessary to narrow down to a combination of processes that are likely to be actual operations and to limit the number of tests to a realistic number.

Whether it’s an exploratory test or a shed operation test, it 's difficult to set a criterion for the end of the test. At the time of considering a test plan, I think it is better to deal with it by a man-hour-based plan, such as how many man-hours the test engineer’s man-hours should be allocated.