April 9, 2012
Boost Acceptance Testing With Pair Testing
Acceptance tests are one the most important things for end-users to be able to sign off their approval of a system, yet often these tests are handled with less structure. End- users and business specialists will conduct the tests but quite often they get no help to learn a little testing knowledge, and that makes the work unstructured, boring and ineffective.
On some occasions, acceptance tests are done by a test specialist who is good at testing but doesn’t know very much about the business. This approach is flawed from another level.
What is the best thing to do in this case? Combining testing knowledge and business knowledge. You can achieve that goal; by working with pair testing to boost the acceptance tests.
Having to perform tests without having the right support and experience can be really frustrating to the user. If the system being tested is also delivered late or is of too low quality, there might be both delays and frustration. Users know their business and testers know their test methodology. It is only when they work together that the best of both worlds is utilized.
The solution is pair testing and means simply that a tester and a user work together. Pair testing is used in other contexts, not just acceptance testing. The most common usage is when a tester works together with another tester, as in exploratory testing where one tester conducts tests and the second tester documents outcome. In test automation, it is also common to use pair testing, with a tester and a developer working together to create automated tests.
In pair testing at the acceptance test level the couple can consists of a tester who is a specialist in testing and a user who is a specialist in the business.
How To Do Pair Testing?
Plan pair tests in shifts of 1-2 hours, which is called session-based testing. During the session the tester and the user will work together.
The user’s task is to run the tests and propose concrete new test cases based on their experiences. Ideally, the user should bring common examples from their operations to the tests.
The tester’s job is writing bug reports and suggesting alternative test cases based on their testing skills.
Select users to represent different areas of expertise. Each pair will focus on different parts of the system. The test cases do not need to be complete as it will more than likely suffice if you start with test ideas or checklists.
On the administrative side of testing, the test leader directs and plans the work. If there is no appointed acceptance test leader the system test leader can do the planning, but it is best if it can be a specific acceptance test leader. The test leader should also schedule the pair test shifts in a scheme to make it clear to all involved.
The Advantages of Pair Testing!
To the tester, pair testing is an advantage since they will quickly learn the system. The user, on the other hand, will help to analyze things from a business perspective, and this is of great help to the tester.
To the user, pair testing is a very time efficient practice because they will not need to spend as much time on testing when compared to other techniques of testing. The user will quickly become familiar with large parts of the system and it can mean that user training might not be needed. Furthermore, there are a number of ‘soft’ advantages, such as that the users will like the system, feel more important and central to the process as well as getting an opportunity to make a difference.
There are also benefits which are common to both users and testers. Both roles will be transferring their thoughts about testing to one another. The work becomes more challenging when you work together instead of working by yourself, but both parties will gain a precious understanding of the complexity at hand when the two worlds meet.
The Challenges of Pair Testing
When working with pair testing you will usually execute tests during the pair session. Only when the session is over will you write bug reports. The advantage here is that there will be a good flow during the session, however, the bug reporting can become time consuming and tedious when done afterwards.
Additionally, as with exploratory testing, it is not easy to show management exactly what proportion of the tests have been performed. Sure, we have tested for five days, but we have carried out 10% or 50% of the planned tests? However, do remember that if you manage to convince management that paired acceptance tests are one of the best ways to gauge satisfaction with a product early on as well as the possibility of skipping training almost entirely, you stand a better chance of being left in peace to finish the tests and get those valuable conclusions.