Creating UAT Test Scripts

Creating UAT Scripts can be difficult for several reasons. These reasons can include your audience, the content of the sprint stories, multiple sprint stories, and the presentation format. There isn’t a standard for creating UAT Scripts, but there are some general guidelines such as UAT Scripts should be business-focused, scenario-driven, clear and repeatable, verifiable, and traceable.

When trying to understand the UAT audience, you must consider factors such as the audience's computer skills, software knowledge, understanding of the system's processes, and language skills. A teacher once told me that when writing your UAT script, you should write as if the audience has never used a computer before, because you shouldn’t assume someone's computer skills. That isn’t the best method when you know your audience's computer skills, such as when working on a development project. If the UAT Script is for a broader scale audience, you may want to factor in lower computer skills.

The contents of the UAT Scripts are developed from user stories. The user stories can come from multiple sprints or a single sprint, depending on the client and development team's agreement on what has been completed in that phase. When writing UAT Scripts, you need to understand what the audience wants to see. Do they want a test script for each user's story, or combine the user's stories to create fewer scripts? Bringing user stories together for test scripts is great because it reduces repetition in the UAT Scripts. This can make it quicker for the UAT Tester to complete the scripts and provide feedback on the new features and what worked correctly for them. Writing test scripts for each user story can involve many repeated steps to access related features. Here is an example: you have two different user stories to create different types of updates to the home page. One user's story is to add fields, and another is about the function of those fields. When you create test scripts for each user's story, those steps get repeated. When you combine those user stories into a single test script, you can have the tester verify the fields and the logic behind them. This will save the tester time.

Getting the client’s input on how they would like their user stories to be relayed in test scripts is important. Letting them know the pros and cons of both approaches and how each approach can verify that the requirements are being met. Multiple user stories in one can be more closely related to the business process the client will use the system for and help them understand the importance of the function.  

The format of the UAT Test Scripts may vary. There are dedicated programs to help create and run UAT Scrips, but some testers utilize either Word or Excell. These two programs are simple, easy to use, and are widely utilized. I personallyprefer using an Excel document over Word because it is easier to have each test script on its own sheet and to move between sheets. Word is a significant document, and it can be hard to navigate if it isn’t formatted correctly. It can be difficult for a tester to enter their responses into a word as it is not formatted into a table. An Excel document is already a table that is easier to work with. In a Word or Excel Modern workspace featuring a laptop with a UAT test script, surrounded by notes and icons highlighting best practices for creating clear, business-focused, and repeatable UAT scripts.document, the UAT Scripts need to cover what the project is, what is being tested, how to get to the system being tested, different roles, the test scripts, what user story is part of a test script, what roles for the test script need, assumptions being made, what is Pass, fail or need improve, and many other items. 

When formatting these documents, ensure they are clear so that testers understand what, how, and why they are performing these tests. These scripts, being related to the business process, can make it easier for the client to follow the test script.  The language in the test script is very important. Keeping the language consistent throughout the UAT test script will ensure the UAT runs smoothly. Don’t switch the words, click, hint, or select each other to click a button on the system. Each one should have its own meaning. The wording of the test scripts should be simple so that a third grader can understand how to perform these steps. When creating a UAT script, they need to clarify, organize, and document the requirements so the client can understand, repeat the steps, and validate them. As the BA and QA create UAT Scripts for development projects, what are the tips and tricks you use to create your UAT scripts?