This is an interesting debate – whether or not to enforce your customers to write their own test plans to validate the product you deliver to them. There are strong points to be made to support the furnishing of test plans or scripts to your customer however there are stronger arguments to be made against it.
Leading Your Customer
I’ve worked with organizations that will supply customers with a set of test scripts that spell out exactly what the customer is to do in order to test the system that has been delivered to them. While this makes for a typically smaller UAT engagement it also can tend to spiral in the direction of ‘leading’ your customer. By telling them what to test and exactly how to test it, all you’re doing is essentially telling your customer to do the same mouse clicks and keyboard strokes that your team has already performed. Customers are harnessed (if they choose to follow the scripts to the letter) and only test the system for the specific cases that the project team has documented. This can lead to issues down the road when customers encounter situations that force them to use the system in ways that may not have been thoroughly tested during the implementation, which can lead to unexpected results and very unhappy customers.
Unaccounted For Business Scenarios
Nobody knows the business better than the customer. The business analyst will come close but at the end of the day, the customer is the one knowing their business better than anyone. By not narrowing the field of vision for acceptance testing by providing canned scripts, the project team is effectively forcing the customer to apply real-world scenarios against the software and ensure that it’s going to meet the needs of the business. Business analysts will evaluate and account for as many business scenarios as elicited during the requirements phase (and the system should be built to withstand and support these identified scenarios) but during testing, which can occur months after the initial requirements were defined, there may be particular scenarios that the system needs to support (which may or may not require a change order to implement) that were not uncovered during the requirements gathering phase of the project.
Training, Practice and Knowledge Support
Giving your customer a set of verbose and explicit steps needed to test the software may seem like a win to them however it’s kind of like giving someone the answer key to an exam. By making the customer determine how they should test (with appropriate training of course), we are effectively forcing the customer’s hand in coming up with all the different ways of testing the system and a very valuable by-product of this approach is a much deeper knowledge of the system which can pay off massive dividends when it comes time for go-live and the follow-on change management process for adopting a new system. Your customer testers become intimately more familiar with the product, they feel more comfortable and confident with it as the testing progresses and, provided testing and issues are managed well, they are more likely to become evangelists for the product and your project team.
Providing test scripts to your customers seems like the logical thing to do sometimes – your team has the knowledge – why not share it with others. That works to an extent however it is somewhat cheating the customer out of really sinking their own teeth into the system to stretch it out and make sure it works for their own flavor of testing. This can be trickier from a scope management perspective as there may be situations that are explored that are beyond the framework of your project but if done effectively, having your customers create their own methods for testing your software will pay off much more in the end.
Want to learn how our Digital Experience service can help you and your team? Let's talk!