Bringing together Perspectives in Testing: Pair testing
Pair testing, also known as buddy testing is a latest trend in software testing. The idea is simple; it involves two supporters from different teams testing a project on the same device/computer. Typically, the pair is a tester and a developer, but the pair can also be combination of a tester, developer and an analyst.
What does the “pair” do?
The pair - Developer and tester, work in shifts of 1-2 hours, which is called session-based testing. During these sessions the pair brings individual skillsets and backgrounds to the table . Developer will run the tests & propose real new test cases from a technical perspective and the tester’s work is to write bug reports and suggest alternate test cases based on incumbent testing practices.
What does the practice of Pair testing deliver?
Pair Testing helps in closing the usual communication gap between testers and developers. It also acts as an agile form of exploratory testing (testing approach in which test design and execution takes place simultaneously), which paves the way for team members to learn from each other. A tester will be able to get an idea about how the software is built and on the other side a developer can understand how the software is perceived and used by a tester. The number of participants in testing are significantly less now and it helps in finding & analyzing the root cause of important bugs in a more easy way.
When to use and When not to?
Technically, if a problem is identified at an early stage, it is easier to set it right. Exploratory testing in the development phase with testers, developers and analysts helps to address issues related to functionality, usability, design etc. on time. After the release of the completed project, pair testing at post development stage will be the solution for finding the areas of improvement and supporting continuous development.
As Pair Testing complements automated testing, it serves as a best solution for startups/small organizations to save time. Yet it can’t be a replacement for total testing activities because of its unofficial and examining nature.
It may not be a wise choice to introduce the entire pair testing development life cycle in an existing process. However, this can be introduced as a practice in specific phases of the testing cycle.
It is not applicable for scripted testing, as all test cases are pre written and one need to run the scripts.
Get started with Pair Testing
To get started with choosing the suitable project for pair testing, team members needs to set an approach on how to handle and schedule time for each other’s work. It is advisable to choose a pair-tester and developer who have already worked together. Size of the project chosen is important - not too small or too large. After initial discussion & one or two sessions, get comments from the pair on what worked out and what didn’t and where pair testing fits in the development cycle.
Pair Testing has obvious plus points than the traditional one way testing approach. Learning and knowledge sharing - about testing & the SUT (software under test), training new team, break down blockades between team members and more importantly it is interactive & exciting.
Thus, if you are be able to convince your top management that paired tests are one of the best ways to scale satisfaction with a product/service early on as well as the likelihood of skipping training, you can stand a better chance of winning a situation of being left to finish the tests & get those worthy conclusions.
