The collaborative tester: A paired testing approach

Big Thoughts

7 June 2016 • Written by Chloë Wood

User Acceptance Testing (UAT) plays an important role in the SDLC. It is during UAT that the product is plunged into real-world user scenarios and the rubber hits the road. During UAT, the tester is looking for any issues that get in the way of the end user of the product being able to use the product successfully and happily. UAT is in some ways similar to a cake tasting – all the ingredients have been combined to create a cake, but does it look and taste any good to the eater?

In my experience, UAT is either carried out by professional testers – with their testing skillset and a list of known solution requirements – or by business users – with their breadth of knowledge of how the solution should work day-to-day. Both parties have the ability to come at the task with their own strengths and have a good crack at testing the solution and finding important issues. However, there is plenty of benefit to be gained from involving both parties – and at the same time.

Paired testing may invoke ideas of two testers testing together – or perhaps a tester and a developer doing testing side-by-side. However, in this context, I’m talking about paired testing between a tester and a subject matter expert (SME) or end user of the product. I would suggest there’s much value to be gained in the collaborative tester engaging in paired testing with the business during UAT. But what does this look like practically? 

What is paired testing?

Paired testing is the process of two people testing in collaboration. It involves two brains looking at the same screen and evaluating the solution together. 

What2

Who is involved?

In this context, we’re talking about a tester and an SME or product end user – one person has experience in testing things and one person understands the ins and outs of how the solution (and end users) should behave.

Who

Where does it occur?

Ideally, paired testing takes place with both collaborators sitting side-by-side and looking at the same instance of the product – in an environment where they’re free to discuss their findings as they go. It can also be done via voice conference or with the use of screen sharing, but – in my experience – side-by-side testing enables easier interaction between the tester, the SME and the solution. 

Where

How is it done?

The execution of this technique is entirely up to you. However, the following may provide a helpful guide to get you started:

  • Identify people from the business who have a clear picture of existing business processes
  • Do a walkthrough of the new solution to identify what will change and how this will change the business processes
    • This can be done in the form of a warm-up paired session
    • A warm-up session can be helpful for setting expectations and breaking the ice
    • It can also be helpful to start generating and capturing test ideas in this warm-up session as questions are raised and solution weak points identified
  • Book out a two-hour test execution session and a space where you can both work in a focused environment
  • Before the session, the tester should prepare a high-level road map of what should be covered during the session
  • During the session – where possible – work through test scenarios that reflect real-life cases
  • Capture test coverage, findings, additional tests required and issues in whatever way is appropriate in the testing context
  • If required, book a follow-up testing session

Why bother?

‘What is the benefit of applying a paired testing approach for UAT?’, I hear you ask. There are multiple strengths to this approach, including the following: 

  • Knowledge transfer
    • Testers know about testing and business users know about the business. Paired testing is a great way of transferring knowledge between the two
    • Testers will gain a better understanding of the expected solution behaviour
    • Business users will have an understanding of how the new solution can be expected to behave – including its strengths and weaknesse
      • They will also be equipped with a testing toolkit that they can use when involved in future UAT
  • User acceptance and confidence building
    • At the end of the day, UAT is about working towards a product that is going to be acceptable to end users
    • If the end users are involved in UAT, this gives them a chance to interact with the solution early and highlight potential sore points before they get to production
    • When users are involved in UAT, they will also gain confidence in the solution
  • Two heads are better than one
    • With two sets of eyes and two brains, you’re more likely to pick up on issues or unexpected behaviour

Why

As a tester, this technique has so far been valuable in my experiences. It has helped me gain a better understanding of the business context I operate in and build positive relationships with business users. If you haven’t already had a go at applying this approach, I challenge you to use this as a starting point. Give it a go and adjust as required to meet your operating context. I’d love to hear how you get on!

Search the Assurity website (Hit ESC to cancel)