Make Sure Your Project Customer Does the Real Testing

Repeat after me.  You can't test for your project customer.  You can help them get through it, but you can't do it for them.  In the business world, conflicts of interest can be a very bad thing...and a very costly thing. Results can get thrown out, work can have to be redone, and customers or project clients can lose all confidence in your ability to be impartial or objective if a conflict of interest comes to light.

Why then, is it so incredibly common that our project clients seem unprepared, unwilling, or uninterested in putting much if any effort into thoroughly testing the solutions we provide to them?

Well, since I'm opinionated, I definitely have my own thoughts on this.  I believe it boils down to, primarily, one or more of three reasons:

  • Lack of subject matter knowledge
  • Lack of available staff and time
  • Lack of interest because they want us to do all the work and hand them a finished solution

All of these are valid responses and all are very wrong.  No matter how you look at it and no matter how hard we may try to test objectively based on the original project client requirements, if we do the testing it's unquestionably a conflict of interest. And this conflict of interest will come back to haunt us in a very bad way if we ultimately deliver an end solution that the project client deems unacceptable or that misses the mark for the target end users.

So, how do we get around these customer issues?  How do we get past their lack of interest, expertise, or availability?  How do we put the onus for testing back on them so that we can be confident at the end of the day when they sign off on the project that they’re happy with it and know what they’re signing off on?  How can we be sure that our neck is covered and they won’t come back pointing the finger at us for a signed off and tested system that they are frustrated with.

Four key steps are what it takes.  By incorporating the following four key steps or processes into the engagement we can better ensure that the customer WILL be involved in testing and our neck WILL be covered when they sign off on the system and pay us for our efforts.  There’s no guarantee of course – anyone can sue anyone, right?  But at least following these steps will show due diligence and put the responsibility for testing and approving the system solidly into your project client’s hands and not yours.

Get formal approval on the requirements. It all starts with proper requirements.  And if you can’t get great requirements out of the customer, at least get the best that you can and have them formally sign off on the requirements you jointly document so there’s a mutual understanding going forward of what you’re building – and also ultimately testing – against.  Make sure that the formal signoff task is part of your project schedule and track it well.

Make test cases and test scenarios a customer deliverable to you. Tell your customer at kickoff time that the creation of test cases and test scenarios is their responsibility.  Prepare them as early in the engagement as possible for this responsibility so that they’re working on it.  Leave them no excuses.  Be sure to include it in the schedule and at the appropriate points in the project get status updates from them on it.  Include it as tasks to cover in the status meetings and discussions that you have on the engagement.  Be sure that they understand that this is solely their task to deliver on.  You can help them along the way, but make your involvement as minimal as possible.

Be available for testing – but don’t do it for them. Make yourself available to the project client during user acceptance testing, but be involved as little as possible.  Think of yourself as more of an advisor – definitely not a participant.  You don’t want any appearance of subjectiveness or conflict of interest that could cause you problems later on.  

Get formal UAT signoff. Finally, get a formal sign off from the project client following their acceptance of the testing process.  This formal signoff is critical – it’s basically just as important as the final signoff on the entire solution when the engagement is over.  Documentation – especially when you’re talking about approval documentation – is extremely important in consulting engagements.

Summary / call for input

No matter how well you want it to matter how much you want things to go right...and no matter how easy you want to make it on your project customer who may be struggling – especially on tech projects – you can't do the testing for them.  It won't end well.  Help them prepare and walk them through it.  That is what you can do.

Readers – tell us about your testing nightmares.  Share any stories where you struggled with user acceptance testing and the concept of getting the customer to adequately test the solution you were turning over to them.


Add comment