For up to £250 Bonus for sports, use our exclusive bet365 Bonus Claim your bonus and start betting at bet365 now.
PM Essence

Testing Technique in Agile – Pair Testing


By - Mrs.Rama Komarabathini, PMP, PMI-ACP
Software projects, especially the product development teams, today are fast moving away from the traditional development methodology and adopting Agile for obvious advantages. However, advantages are accompanied by a number of challenges especially to the testing team.
Agile projects introduce time-boxed development – hence clearly time is the most important constraint. 
Agile brings in faster pace of development hence squeezing the QA team's ability to develop and maintain test cases.
With Agile's principle of “welcome changing requirements even late in development cycle”, the test scripts need to be kept updated with changing requirement.
Development spill overs - The development team over commits thereby squeezing the time available for the testers.
New features developed in sprints, churn out code to such an extent that it increases the risk of regression.
In short, time available for testing is limited; use whatever is available efficiently and effectively.
The power of two
It's not for nothing that people from time immemorial have talked about the power of two people working together. The wellknown proverb in English states it all – “Two heads is better than one”.
This notion is also expressed in the New International Version (NIV) of the Bible. The two verses 9 & 10 of the Chapter 4 from the book Ecclesiastes (Ecclesiastes 4:9-10) quote,
9. Two are better than one, because they have a good return for their work
10. If one falls down, his friend can help him up. But pity the man who falls and has no one to help him up!
Wondering what has Bible got to do with Agile testing techniques? Read on…
The other day, I overheard a conversation of two college going girls. Apparently they had to walk quite a distance to go to the nearest bus stop. One was saying to the other – “You know, when I walk alone to the bus stop, it so boring and appears to take eternity to reach there. But when we walk together time flies so fast and it appears that we have covered the same distance in a jiffy”. So what's happening here? In a nutshell, the work (of walking to the bus stop) is getting done efficiently when two people are involved.
This got me wondering – Can I not apply the same concept to testing? I was determined to start Pair Testing in my project. Whilst pair testing is not a new concept, it is surprising that not many testers use or know about it.
So what is Pair Testing? It is a technique in which two people test an application at the same computer by continuously exchanging ideas.
The pilot, who is in charge of the keyboard and mouse, is responsible to perform the actual testing tasks, whilst the co-pilot analyses, reviews and guides the pilot. The two members involved could take turns to be pilot and co-pilot at alternative instances.
How to apply Pair Testing? Don’t over complicate. Keep the process simple, straightforward, flexible and easy to use. The following steps have been very effective for me in implementing Pair testing,
Determine the duration of testing – Working in pairs, sometimes deprives the members of thinking individually. It also leads to one being over dependent on the other. So work in short bursts – 60 to 90 minutes per session is ideal.
Identify scope of testing – Decide what should be tested in a session.
Establish a goal – My goal, “No software is bug free, let's find at least one”.
Determine the pilot and the co-pilot – and rotate the responsibilities.
Execute the tests – Book a room for yourselves for the duration of the session.
Stick to the scope – Do not deviate from it.
Applicability of Pair Testing Pair Testing need NOT limited to “test case execution”. It can be applied almost all QA activities. This includes functional analysis, test case designs, exploratory testing and bug reporting. However, introduce the concept by starting with test case execution.
Advantages of Pair Testing Pair testing brings in efficiency thereby reducing time due to following reasons,
Better knowledge - Lower chance of functional misunderstanding. Hence time taken to redo the test cases is avoided.
Inherent test case reviews – Test case reviews not required since they already have been written by two people.
High creativity – Brainstorming between the two members leads to better creativity and test coverage.
Increased productivity – Limits interruptions leading to better focus, high productivity and better testing.
Improved testing methodology – Sharing of past experiences leading to improved testing and hence reduced time for test cycle. 
Time saving – Use of pilot-copilot mode resulting in sharing of tasks and responsibilities.
Better bug reporting – Reduces time spent in discussing bugs with developers.
Effective training technique – Hence, reduces the time for a separate functional training session.
Better coordination – Generates positive energy and increased coordination.
Better reproduction of bugs – It becomes easier to reproduce tricky bugs because you start seeing patterns when working in pairs.
Factors for successful implementation You may start thinking that Pair Testing is probably the next best thing after sliced bread. However, as always there are challenges. You will need to put appropriate steps in place.
Time, practice and adaptation – Don't expect the process to work the first time. Adopt and adapt processes continuously to suit your project.
Social inclination – Allow the member to spend as much time as possible with each other.
No Jealousy/ego factor – The members involved should be open to criticism. Pair members with care.
Team work – The members should work as a team with a combined goal.
Don't measure individual performance– change the pairs to find the best combination.
Conclusion Having practically used it, I have shared my experiences of Pair Testing. However, it is not a magic wand for all your testing problems. It is complementary to the other testing techniques. Use it wisely and carefully.