Pair testing strategy in an Agile environment

Pair testing is a testing strategy where two individuals work together at one workstation to test the software application. The approach is derived from pair programming, a practice used in Agile methodologies where two programmers work together at one workstation. Pair testing can help you complete your testing tasks faster and with higher quality. But who can do pair testing, and when should it be done? And what form of pair testing is best for your circumstance? Check out this blog for more information on how to conduct pair testing to optimize its benefits.

What is Pair Testing?

Pair testing is an important software testing approach that includes two individuals or team members working on a single workstation/keyboard to evaluate various parts of a software system. This sort of testing is classified as ad-hoc testing since it involves pairing two people to work on the same software product and the same device. During pair testing, both persons are responsible for separate tasks that check the software’s quality and functionality. While one is in charge of testing, the other is in charge of analyzing and reviewing the process. As a result, with the help of this approach, one may quickly undertake rigorous software testing while saving time and money.

What are the Advantages of Pair Testing?

While pair testing may not be appropriate for every team, it has various advantages:

Aids in developing new perceptions and approaches, which leads to improved effectiveness.

Working with people who have varied skill sets allows testers to look at software from a new and distinct perspective. It also aids in the comprehensive comprehension of the program. People who have been working on the same program for a long time are familiar with the functionality and may not have the correct set of eyes for an end-user perspective. A new set of eyes may see something that was previously missed.

Aids in increasing the effectiveness of testing

Defects may go undetected when a tester has been working on the same system for a long time. As a consequence, when they pair with someone new, those new eyes may detect such flaws and ensure that they are not exposed to customers.

It aids in breaking down silos and creating better teamwork

Because of the nature of their work, developers and testers typically operate in silos. Pair testing helps to break down silos and improves collaboration among team members with varying job titles. It also promotes information exchange and provides an understanding of each other’s duties. Aside from that, it aids in the development of intern-team partnerships.

It promotes knowledge sharing

Learning from real-world examples in software testing can be more successful than learning from manuals. A walkthrough in which questions and answers are instantaneous might be extremely useful to both partners. Pair Testing is a good approach for individuals, particularly novices, to learn from their peers by seeing what they doing.

Think About Moving Beyond

Individually, our thinking might be limited, and we may continue to do things in our accustomed ways, but working together encourages us to think beyond. Pair testing necessitates two individuals sitting together, discussing, and working together. The same feature or narrative is studied from a different angle, which serves to broaden the reference user base.

Problems are resolved more quickly

When two individuals collaborate, things happen faster since pair testing eliminates back-and-forth reporting, allowing any found faults to be resolved more immediately during the investigation. A developer and tester team can help quickly replicate issues, identify root causes, and solve them. A tester and business analyst team assists the tester in better understanding the feature need and achieving larger test coverage. A tester and tester combination facilitates the use of cross-functional expertise and the avoidance of dependency delays.

Who Can Do Pair Testing?

Pair testing with a developer or another tester is common, but remember that these are not the only disciplines that can accomplish it. A documentation writer can contact a tester to find out what will be included in the future release of the program. The tester will then walk the documentation writer through the new features and produce the documentation that is required for the next release. A customer may raise a problem that must be examined. The tester will replicate the error situation with the customer to see what is occurring.

A business analyst or solution designer can also pay the tester a visit to go through the feature. They may ask, “What happens if you do this?” while doing particular tests at a specific time. A rigorous exploratory test begins here, and the tester may discover some defects. My employees use pair testing as an essential element of their development process. They are doing it in various combinations, such as testers working with developers to evaluate new code before merging, testers working with other testers to test particular flows, testers working with product managers to validate requirements, and so on.

You can pair test with practically anyone. I was once discussing a matter with my project coordinator regarding an issue with the application. I saw the problem as well, but I couldn’t figure it out. While assessing the scenario and conducting some pair testing with the project coordinator, it seemed to me that a feature I was working on appeared to conflict, under certain situations, in that area of the program. This proved to be a critical defect, necessitating a quick remedy for a back-end system. I could have solved the problem on my own, but partnering aided us in finding it faster.

Boundaries and Challenges of Pair Testing

Even though pair testing is a very useful testing approach, the team still faces a few challenges when carrying out its procedures. These challenges are:

After-session defect reportingOpposition to the new change

By nature, most organizations oppose a significant shift. Managers may expect testers to complete more work by working on many projects concurrently. They may also be concerned about cutting productivity and delaying time-to-market. Two testers will need considerably less time to test than one tester alone. When done correctly, pair testing saves time and speeds up releases. Assume you’re doing pair testing with someone from another team. You hire someone to test your product for a time constraint. Furthermore, this can assist testers from various teams to form stronger ties and support one another in their releases. Obtain agreement from your management and stakeholders. Explain your goal and the potential effect of the new program, as well as the benefits of pair testing, and address their concerns.

Avoid typical mistakes

Mentoring may be necessary for non-testers who do not have testing expertise. Testers must keep the pair-testing session focused and on track. Be open to opposing perspectives and respect other people’s ideas and beliefs. Furthermore, pair testing is not a method for having someone on the team perform test cases while training and monitoring them. Finally, when pair testing, the pair may decide on the sorts of testing they wish to undertake based on the context of their project. Pair testing, on the other hand, is neither a replacement for nor justification for skipping any form of testing.

My 2 Cents: Pair testing is a great complement to regression and automated testing, and it may save time for smaller teams. Of course, it is not a substitute for other sorts of critical testing activities. Pair testing may be challenging to integrate into an existing development process in certain bigger firms. Waiting for a phase transition or the start of a new project is a smart way to implement pair testing in a specific area.

When to Do Pair Testing?

I frequently hold brief pair testing sessions with members of my Group. These occur throughout the software development lifecycle, either in a single sprint or over multiple sprints. You may also utilize pair testing as a learning opportunity, such as bringing a new colleague or a junior tester up to speed on the application by testing together.

Support for or from other professions might also result in a pair-testing session. While reviewing some documentation, you may ask a designer some questions about how a feature would operate, and before you know it, you’re working together on a whiteboard, discussing possible situations connected to the product. From another perspective, the business analyst may approach you and ask how the feature is functioning, and you may wind up having a pair-testing session to determine whether the product can be improved.

When a problem has to be investigated, pair testing can also be used. You can seek help from another team member (either a tester or someone else), or you may be requested to investigate a client concern by a customer service person. These are all excellent possibilities for pair testing, but they can also occur without your knowledge. Regularly, I conduct pair testing with my business analyst. We test some feature tags together to see whether the analytics are functioning, and I run the test while the business analyst examines the results.

How to perform pair testing

If you want to actively begin performing some pair testing, partner up with a coworker you trust and who believes in the notion. You can decide on the emphasis and scope of the pair testing session together. Prepare your activities for your pair testing ahead of time. Set up an environment where you can test together without issues—this includes a desk, tools for working with the application, and a time frame when you can work together uninterrupted. You can accomplish this with management consent or on your own. Evaluate the outcome and convey it to your stakeholders.

Pair testing advantages are maximized when you use an appropriate process:

Pre-session activities

The key to pair testing success is preparation:

• Find a companion for your next round of pair testing. Share the invitation at least three days in advance.
• Create the necessary setup and share it with the invitee.
• Create and distribute a high-level strategy that includes domains to test and associated risks, devices, tools to use, objectives, anticipated session outcomes, and so on.
• Share the materials that the invitee must review and clear up any confusion. Requirements, user stories, designs, and other accessible documents are examples.

During the session

Pair testing sessions should last no more than 90 minutes. Experiment with different time divisions to find out what works best for you. For example, consider the following time split for a 90-minute session:

• 20 minutes – The inviter conveys the strategy, goals, and other necessary instructions to the invitee (a tester from another team/person accepts the invitation). Even though the pair is jointly accountable for the result of the pair testing session. The inviter is responsible for optimizing the output of the session.

You can also use the following checklist:

• Determine the test scenarios you wish to work on
• Determine who you want to collaborate with and what each person’s function will be.
• What do you hope to gain by working with this particular person?
• What do you hope to gain by working with this particular person? Will the equipment be operated by one person the entire time, or will you switch?
• Determine a goal for your pair-testing session. Do you wish to report issues or make suggestions for new features? Maybe you want to define which tests should be automated, or maybe you want to do all of the above.
• Determine who you will present your findings to if they deviate from your standard report.
• It should also be made clear if they can transfer responsibilities during the process.
• 50 minutes – Time for the pair to focus on exploring the system under testing. The session is led by one of the pair, while the other reviews, analyzes, and documents significant items. After ~25 minutes, the pair switches places. You can also change the mode based on a specific task.
• 20 minutes – If there are any issues, log them once the session has ended. Make comprehensive bug reports as well, including any unexpected disparities or abnormalities that may have arisen.

Pair Programming vs. Pair Testing

If a developer requests that you investigate a feature and see how it works, you may find yourself in a session where some code is rewritten or even new code is created. You are pair programming in this case. The result of the pair session is new or rewritten code, and the developer is in charge. When you ask a developer to check into an issue you’ve discovered in his code, you’re evaluating if it’s a test error or a real problem together. You are pair-testing in this case. The pair session yields information on whether the problem is a bug, and the tester is in command.

When you and a developer collaborate on automation, you are pair testing one minute and pair programming the next. You may not even notice the difference at times. Regularly, my teams are collaborating to develop code to assist our testing, such as unit tests, user interface tests, end-to-end tests, and regression testing. We both run these tests to check if they are successful. The developers code-review the automation tests I wrote to determine if they need to be improved, and we occasionally rework them directly during our pair sessions.

What can you anticipate from an efficient pair-testing session?

To make pair testing a success, you must give some sort of tangible outcome. There may be various deliverables:

1. Automated tests: A test designed and automated in collaboration with your developer will be included in the regression test suite. These new tests will free you from repetitive regression testing efforts and allow you to concentrate on real problems.
2. Session reports: When running tests in pairs, one person drives while the other takes notes. It’s a good idea to put these notes down so that the knowledge may be communicated to other members of the team.
3. Sharing Information: Information for stakeholders might be the test plan you wrote, the tests you performed based on your test hypotheses, or anything captured in your session results. Information can also include bugs that you discovered, reported, and retested. All of this information is useful to stakeholders since it informs them on how to progress.
4. Test documentation: You will create documentation when preparing for tests. This will result in two major documents: a test plan and a set of test thoughts to help your execution.
5. Defect reports: While investigating an incident with a developer or a customer, you may discover that it is caused by a bug. Your bug report will get it addressed.
6. shared knowledge: While shared knowledge is not acknowledged as a concrete product, I believe it is vital to emphasize it as a result. Pairing signifies those two experts on the subject collaborated on a test, removing the possibility of a single point of failure and increasing trust in your tests.

Conclusion

Pair testing necessitates fewer pre-testing actions than normal. Although it may appear simple, the outcome of the entire procedure depends on the team members’ proactivity. The basic objective of pair testing is the phrase “two heads are better than one.” A review or walkthrough involving two individuals can increase trust in the developed system. Overall, it helps to accelerate testing and offer a higher-quality product with substantially less work or added expense.

David Tzemach

The founder and owner of the Agile Quality Made Easy blog (25K followers). A platform that he uses for teaching and coaching others, sharing knowledge with people, and guiding them towards success while giving them the inspiration and tools to discover their own path.

See author's profile