Implementation of Pair Programming and Pair Programming

Implementation of Pair Programming and Pair Programming
Over the past few days, I have been exploring Pair programming knowledge. As for the basic theory of pairing, I have already elaborated on it in my previous blog. This article mainly summarizes how to implement Pair Programming in projects and unit tests.
In the project:

1. Both parties are bound to the same project team;

2. The pilot and implementer should be able to see the screen clearly before sitting on the same fast and high-configuration machine, especially the pilot (you can consider connecting to a display screen );

3. Two people must communicate at least once every minute;

4. We recommend that you use an experienced "veteran" with "Novice" or a combination of "Novice" to avoid the experience of both of them, "veteran" or "Novice" should explain the work they are doing to the other party before starting their work;

5. Two developers should first develop a set of design schemes, but most of them should be completed by implementers;

6. Perform unit tests after the code is complete;

7. The Code review team should review the Code;

8. Implement a pair rotation mechanism, including:

(1) The roles of the pilot and implementer are exchanged within a certain period of time (for example, one hour, the two parties can coordinate according to the actual situation)

(2) personnel rotation is performed after each small module is completed, that is, the pairing object is changed (because one of the original goals of pairing is that everyone needs to understand the needs of the entire project, therefore, there is almost no "cooperative thinking interruption ).

 

In unit test:

1. Before the two partners start writing the first line of code, they should first write the first automated unit test case. Programmers must strictly follow the rules of "create several test cases first and write some product code" to develop them cyclically. That is to say, when writing code-oriented code, programmers must write unit tests for every method they intend to implement.

2. 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.

3. In the practice of paired tests, we use documented test cases, but not limited to 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 discover more defects with greater initiative and creativity. At the same time, because of the 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 an appropriate pairing 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 leads and the other assists. Note that testing scenarios and problems need to be discussed continuously during the testing process;

(5) evaluation of the Peer test results: Evaluation of the discovered problems, evaluation of the efficiency and effectiveness of the Peer test, the unsolved problems, the plan for the next session, etc.

Unsolved problems:

In Pair programming, there is also a "ping-pong Pair programming": the implementer writes failed test cases, the pilot modifies the code to use this case, the implementer writes new unit test cases, and so on. This loop continues until the observer cannot write a failed test case. The relationship between it and the pair unit test has not been clearly analyzed, and further exploration is needed.

Conclusion: In theory, Pair programming has many advantages, but in general, it is still rare to do well in practice. Human-time pairing can get twice the result with half the effort. Therefore, it is inevitable to find out what kinds of problems to solve during the pairing process, and focusing on analyzing and solving these problems is the most valuable experience.