When most people think of business analysis, they think of identifying needs and defining requirements for an end product. A quick search of the web will show plenty of tools and techniques aimed at getting this facet of the project right.

Because of this emphasis, it might seem like the business analyst’s job is complete once requirements are identified.

In fact, your most important job still lies ahead.

The Critical Role of User Testing

Requirements that define the end product are only a means to the end and not the end itself. This is where user acceptance testing comes into play. Your ultimate goal is to deliver to the users a system that satisfies the documented requirements and works in the environment it was designed to be used in. Only the users themselves can tell you if the end product has succeeded on these fronts. And it’s only through testing that you can you get their verification and agreement that the product really works as it was designed.

Your ultimate goal is to deliver a final product that works in the real world. This means that while the project team is developing the end product, you should be defining testing scenarios that replicate the real-world future state. Creating these user acceptance testing outlines is not always easy. The good news is, you have lots of time to get it right.

If you look at the broader picture of a project, discovering requirements and identifying components represents only about 10-20% of the time dedicated to it. Developing and deploying the end product takes about 60-80% of the time. That leaves a fairly large span of time between the point in which requirements are defined and the product is actually completed. That’s time you should be actively working on preparing user testing.

Developing User Acceptance Testing Scenarios

While the developers conduct testing throughout, it’s not until users get the product in a near real-time setting that they can actually accept it. Your task is to create the conditions that allow them to determine whether or not the end product truly satisfies their requirements.

Here are a few things to keep in mind when developing and analyzing your testing:

1. Test scenarios should be created based on what end users will be doing in a real-world job. The ideal scenario is very close to—or even better, actually in—a live user setting.

2. The scenarios have to be able to prove each part of the product, verifying that each of the documented requirements performs as defined in the real-word environment. In some situations, user acceptance testing scenarios can only test one requirement; in others, they can be created to test several requirements at once.

3. If the user testing does not end in favorable results, then there is no stamp of approval or acceptance.

This testing is the final step before the end product is integrated in to the user’s live work environment—hence the name, user acceptance testing. No other form of testing will give them the confidence to accept the end product.

And that’s why it’s the business analyst’s most important responsibility. Make sure you give it the attention it deserves.