Use pair-testing for better acceptance testing

Acceptance testing is perhaps the most important of all test levels, as this is the time for users to let their voice be heard before deployment. Strangely, these tests are often not performed well enough.

A common problem is communication between testers and users. On some occasions testers are left on their own without the support of someone who knows their testing. A solution is to let test experts do the acceptance tests, but then again, they lack the end-user’s perspective.

A better way to solve this problem is to let testers and end-users do the tests together using pair-testing (which we explained in this blog post).

By letting end-users and testers work together, testing knowledge and business knowledge are combined and you boost the acceptance tests. The tester is a specialist in testing and the end-user is a specialist in the business.

Although pair testing is an extremely strong mechanism to evaluate a system from both sides of the spectrum, remember that there are no shortcuts or silver bullets.

There are a number of considerations to bear in mind before starting with pair testing in the acceptance phase, unless you have time and money to burn.

What should I look out for in pair testing?

Quality

The system must be of sufficient quality before pair testing begins. It is useless to ask end users to evaluate the system if they must navigate a command line, or if the interface is absolutely not even remotely close to what the end product aims to look like.

Similarly, if the cosmetic shell is finished but the inner workings are still in infancy stage and the end user can not use real world examples during testing, you risk wasting everyone’s time.

Previous tests

This type of testing is not intended to be the first time anyone has ever tested the system. You can not dispense with previous tests simply because you plan to carry out paired acceptance tests. That would be a very unwise choice indeed.

If the previous tests are not done at all or done carelessly it will cause much frustration during acceptance tests.

Inclusion

As many people as possible should be included in pair testing. Some argue that everyone who will ever touch the system should be involved, but in some cases this might not be practical.

The point of pairing the acceptance testing is to get as many different viewpoints as possible so you can not fault the logic behind including as many people as possible. You truly never know what kind of feedback might be forthcoming, and from whom. Listen to the impressions and comments and try to understand them from the user’s point of view before discounting them.

Be focused

When testers do not test alone, rather test with end users, there is the risk of straying away from structure.

Do not be too heavy handed and do try to follow the user’s logic, however, ensure that you steer back to the current task if the tests are straying away and venturing into random and useless territory.

Data

Ask users to bring their real-life data for the tests.

You will get no better opportunity to test these two variables, real users and real data, anywhere else.

Patience

Be patient and positive. Bear in mind you will be working with people who are schooled in testing as well as complete ignoramuses in the area.

This is in no way an offense, remember that it is your job as a tester to make sure that people who are ignorant of testing processes are as satisfied as you are with the final product, and the opportunity of hearing their thoughts straight from them is too precious to blow away because of a short temper.

Listen and ask intelligent questions and the insights you will get will be interesting, unexpected and valuable.

Communicate

Pair testing makes acceptance testing more fun and much more useful to everyone involved.

In order to further improve on the testing, you often need to set up clear communication channels with the supplier and agree on which components are to be delivered to testing and when.

And then?

Finally, in order to improve effectiveness in your collaboration with the supplier and write better bug reports, a testing tool such as ReQtest is needed.

A good tool like ReQtest puts everyone on the same proverbial playing field with a clear view of what the big picture is for all involved, and is a necessary weapon in your testing arsenal.

Contact our team to see how we can help you quickly integrate ReQtest into your tool box.