UAT Test Plan

In our series on Testing concepts and fundamentals, this blog post is going to tackle a significant testing practice known as User Acceptance Testing and the UAT evaluation plan.

User Acceptance Testing or UAT Testing is an intrinsic part of all Software Testing -- irrespective of methodology. Whether you are using Agile development methodologies or sticking it out with Waterfall, any software product that you construct needs to undergo User Acceptance. 

Therefore, UAT is ran following all development and functional testing (read Procedure Testing) is finished, and just before the product is pushed forward to the release or implementation phase. I am sure that you know all this.

What is User Acceptance Testing?

On the uninitiated, UAT represents essentially the last frontier for Testing to capture any unseemly bugs prior to a product launch to customers. The idea is you won't have the chance to fix any glaring flaws with your product beyond this phase in the project. By user, we suggest those who commissioned the merchandise in the first place. These might be people that directly utilize the product, or who anticipate their customers to use it.

By Way of Example,

If you are building a team facing front end to get a core banking system,'users' are employees in the various offices of the bank which will use the employees front end on a daily basis.

If you are constructing a customer facing mobile program to get a retail lender,'users' would be the business proposition team which have requested the performance served with the app. They in turn have captured their needs based on interactions with or feedback from clients or the marketplace.

UAT Test Plan:

Now that we have established who the users are, UAT signifies the cycle of testing traditionally performed by users themselves to ascertain that the item works as anticipated, and meets all the requirements they provided at the beginning of the job.

The actual testing can be conducted completely by users themselves. This might require a certain amount of committed resource allocation from the sponsoring user group.

But, this isn't always possible. Because of any number of reasons, you may not always have adequate consumer time available to complete a comprehensive UAT cycle. What's common, therefore, is the users appoint a committed team of testers that they outsource UAT testing campaign to.

Notice the difference here: consumers these days outsource the Execution of UAT -- maybe not the decision which includes it. They appoint a responsible UAT supervisor who works with the project team to come up with a UAT test program, also recruits a team of seasoned testers to execute the test cases.

Thus, it's possible that the consumers hand over Duty for planning and executing UAT to a dedicated testing team. The users continue to be Accountable for signing off a item which has finished UAT. 

That is, they need to have the ability to express utmost faith in the product having fulfilled all its intended original requirements before it's greenlighted for launch.

Depending on the applications development methodology -- Waterfall, Agile, or anything in between -- how UAT is planned and implemented may change. On the other hand, the essence of what UAT represents and the goals it intends to achieve remain the identical irrespective of the way you bake UAT into your delivery.