The Apple theory of cross-testing

The first part: Apple theory

Early in the morning to open the refrigerator ready to take out the milk to eat breakfast, suddenly found that the refrigerator has accumulated four bottles of fresh milk, which does not include the room outside the milk box today's new two bottles. How to solve? This reminds me of the famous Apple theory, which has similar problems. Bought a bag of apples, a few days later, some Apple freshness has begun to change, and began to rot. The traditional idea seems to be this: the right thing to do is to always pick the apples that are not spoiled, and the result is that some of the apples that are not spoiled are eaten by you, while the other part is completely broken; the wrong thing is to always pick the apple that starts to spoil, and the result is that you eat a rotten apple all the time. Both of these practices are unscientific, the former cost too high, some apples are completely destroyed and thrown away, while the latter is harmful to the body. Is there a way to minimize the cost and avoid harm to the body as much as possible? Think about it, maybe the compromise is a good choice. Make an ascending and descending order of the deterioration of apples, and choose from the middle part of the queue each time.

Figure 1 Apple

　Part II: The Application of cross-testing in Apple theory

　　Is there a similar problem in software testing ? The answer is yes. There are several testers in a test group, each of which is responsible for testing different modules. After several versions of the regression test, the team members of the hands of the module from the whole to the details have a very deep grasp, but this also brings people in nature, fatigue, that is, the crew slowly began to test the hands of the module began to show tiredness and lack of interest, as in Figure 1, the right side of the apple you see the same feeling, The defects found are also beginning to decline, as shown in 2.

Figure 2 Finding the relationship between the number of defects and the number of regressions

Is there a way to solve this problem? Yes, the module between the members can be exchanged for testing, because for the testers themselves, the other hand of the module is more attractive, as shown in Figure 1, the left side of the Apple, also has more unknown areas, so also can find more defects. This is the legendary cross-testing method. Is that a module that has been switched in the hands of testers after several rounds of reunification? No, that cost is too high, because in this way, it takes a long time for the testers to fully understand the new modules in their hands, which increases the cost of time. If you tell the project manager that the time it takes to test our current version (as compared to the version we just started testing with no additional modules and function points) is the same as when the system was just beginning to test, the project manager would be amazed because the Test team has tested multiple regression versions, from business processes to feature points , must be familiar with a lot, the correct result should be the test cycle time will slowly reduce AH. If you tell the project manager that we're using cross-testing to find more flaws, maybe the project manager will feel acceptable when the project is not at a very tight schedule, and that might be a tough one when the schedule is tight.

How to effectively implement cross-testing within a limited project schedule? I propose three-stage implementation law:

• Pre-project testing phase:

At this stage, all the testers in the group have no more profound knowledge of the system's functions and business processes, and the different testers are responsible for testing the different modules. The allocation of function points and business process test tasks is done through test cases.

• Mid-term testing phase of the project:

Test tasks such as a function point test, such as appearance, a single button, or a control function, are progressively crossed through test case assignments, allowing cross-testing to begin gradually. This process can be progressively crossed by prioritization in the test case, from low to high level.

• Project post-Test phase:

Introduce cross-testing of business processes. Considering the familiarity and understanding of business processes is somewhat difficult compared to functional point testing, especially for the financial industry. With the second phase of functional point familiarity and understanding, business process Understanding also has a certain foundation to prepare, so put in the project's post-test phase to cross more appropriate.

Part III: summary

If you are currently on the project that has started to implement such a method, then this article just want to use a real life example to elicit such a number of steps, so that the experience more profound. If your project has not yet begun to implement such a method, perhaps you can try it. If your project has a better approach than this, please let me know, thank you.

Reprint: http://www.51testing.com/html/81/n-210181.html

The Apple theory of cross-testing