Test Management 012: pair testing-good test practices

Due to the lack of platform Resources in the project test, some pair testing attempts were introduced during the test. After two months of practice, the final effect was good. Therefore, this article briefly introduces the practice of pair testing.
Both developers and testers should be creative in their roles. Developers create software products, while testers can discover defects creatively, and each role can proceed in its own way. Developers can pair programming, and our testers can perform pair testing.
So what is a pair test? Different people may have different understandings of it. We define a pair test where two testers sit together (they can share a set of environments or use different environment platforms as needed ). One tester is mainly responsible for testing operations, and the other is mainly responsible for recording test results, test scenario discussions, and issue discussions. However, it should be noted that the two members of the pair test are equal. During the test, they need to put forward their own ideas, ideas, and questions about the test, avoid the fact that a Member is only a recorder. Therefore, it is important that two people make joint efforts to contribute to the entire test session.
In the practice of pair testing, we use documented test cases, but we do not stick to the test cases. We encourage more Exploratory tests throughout the process. The effective combination of documented test cases and Exploratory tests can better meet the script-based coverage requirements, and more defects can be found proactively and creatively. At the same time, due to the work experience, educational experience, problem-based perspectives, and different ways of thinking, different testers can learn from each other and complement each other when testing the same object, better detection of defects. The following are the steps to test the pair:

1. Select an appropriate peer testing partner;
2. Select and establish a suitable pair test environment;
3. The time span of the planned test, defining the test scope, test focus, test goal, and test output, similar to the test charter in the exploratory test;
4. Session for executing a pair test: One-person-dominated, and the other-assisted. Note that we need to constantly discuss test scenarios and test problems during the testing process.
5. Evaluation Result of the Peer test: Evaluation of the detected problems, evaluation of the efficiency and effectiveness of the Peer test, unresolved problems, and plan for the next session;

After two months of pairing testing, we found that not only did we better solve the problem of insufficient test resources, but also gained many advantages in other aspects:

1. Defect communication and sharing, which were reviewed by other testers before submitting defects;
2. Help testers familiarize themselves with more businesses: sharing knowledge, skills and experience;
3. Better cultivate new people;
4. Improve efficiency and effectiveness to avoid test fatigue;
5. It facilitates reasonable allocation of test workload;
6. Better resource sharing, reducing resource pressure and costs;
7. Better risk response: more testers are familiar with more testing object functions;

During the pairing test, note that everyone in the test team is not required to participate in the pairing test. The Voluntary Principles in the pairing test are very important. In addition, prior to the pairing test, the definition of the testing scope and focus between peer testing partners is also very important. Try to avoid passing through the definition deviation test content during the testing process.
As an example: we have not only obtained more detailed test points through discussion and practice during the data backup/recovery function of the test object, they can be used as an important input and reference for future tests. At the same time, some important problems are also found during the pairing test (part list ):

1. During the data backup process, the communication between the tested object and the FTP server is cut off, resulting in the system being in the unfinished state of data backup;
2. During the data recovery process, the communication between the tested object and the FTP server is cut off, resulting in the system being in the unfinished state of data recovery;
3. During the data backup/recovery process, the test object control module performs a master-slave switchover, which will cause the session to be unable to be reconnected to the FTP server;
4. Destroys the data structure that has been backed up and restores the data to the tested object. As a result, the system cannot run or switch to the normal mode;