VBM - Vision Based Methodology™

Activity 10: Reselling the Idea

Conducting Acceptance Testing

Finally, construction is complete. All of the system pieces are in place and are working. It is time for the grand finale - the Acceptance Test. The team has already rigorously scoured the system, looking for defects, with data of its own making. Who could possibly know the system better than the team who conceived it? Without question, every possible curve has been thrown at it, no problem area could remain. Just let the clients cook up a few test cases, and the team will run them. It may even be possible to let them watch while the team actually runs their tests. It might even help them a little in the upcoming system training."

That is a dangerous attitude. It invites a disaster of incredible proportion once the system is in place and processing live business information. Simply because the system is truly unproven. A system is comprised of three things: People, procedures, and technology. At this stage, only the technology has been proven - and this is suspect since it was tested by a team that cannot really be considered impartial. The only way to prove the system is to turn it over to the clients and let them have at it. A free for all, a true testing frenzy! Their challenge should be to break it. Anywhere and everywhere. But in a controlled environment. Again it is time to formulate another test plan.

Reverse Quality Assurance

This is the primary objective of the acceptance test. Proving that the system is able to produce pre-determined test results.

Forward Quality Assurance

This is the critical insight the acceptance test should provide to the business clients. Their participation should shed light on the manner which they will confirm live system results, especially when no pre-determined testing results are available.

Plan the Attack!

Acceptance testing is where the real love/hate relationship begins between the developers and the business clients. Up to this point, the business clients have been relied upon to supply requirements, to participate in reviews, and to be provide critiques of evolving system. All of which are somewhat armchair type activities. Now they are being asked to actually take responsibility for running the new system! This is a major step forward. Instead of just superficially knowing how everything works, they now have to prove their knowledge. In addition, they will be called upon to approve acceptance test results, and to give final sign-offs! All of this dramatically changes the role of the involved business clients. The job of the developers is to make this role change as smooth and painless as possible. Several proactive steps the developers can take to make this happen are:

• Discuss and document the acceptance test approach with the business clients early.
• Base the required sign-offs on tangible, predictable results which the business clients can easily support.
• Find a common understanding and criteria for acceptance testing success.
• Insist on client involvement in the planning and scheduling for the acceptance testing.
• Clearly define each team member and client role and responsibilities.
• Create an atmosphere of fun, learning, and challenge.

The new role of the business client will revolve around the creation, execution, and review of business test cases they have developed themselves. Hopefully, each of the involved clients will have either participated in the development of the system or will have attended the appropriate training sessions.