If your role is accountable for the correct understanding and implementation of requirements, User Acceptance Testing (UAT) might become one of your best friends once the solution is built. In this post, we are exploring the importance of implementing UAT, as well as how to prepare and run it. Let’s dive in!
Once the development and QA phases are completed, User Acceptance Testing should be included in your process prior to release. This ensures that the end users, or the SMEs on their behalf, validate that the experience meets the expectations outlined in the requirements. It will be the moment to show “how” those needs are going to be addressed.
Usually, a Business Analyst (BA) is accountable for leading this activity, which requires careful preparation. Let’s break down the User Acceptance Testing process:
- Limit the scope: Be aware of the different paths you will be preparing and take into consideration that non-happy paths should be included to ensure different scenarios are being covered.
- Create your document: A spreadsheet could be enough, choosing a tool that you are familiar with will be helpful for you and the collaborating users. Construct a template containing some space for the user information, such as Name, Role, and Date. Second, and in order to organize UAT instructions some of the columns that could be used for the headers are: Step #, Step Description, Expected Result, Actual Result (Pass/Fail), and Feedback. Whereas the rows will contain the actual description of each column.
- Break it down into the different processes: Separate each process or scenario. Providing a short introduction about what will be covered, will help the users to understand where it begins, ends, and any nuances involved.
- Delve into each step. At this point, you are probably eager to write down each step, so make sure that before getting started you grasp the end-to-end process. You should perform a walk through the entire process (and probably you will need to revisit it a couple of times) while describing each step and the expected result. Using the test cases built by the QAs could be tempting, but that is not a good practice. Don’t get me wrong, QA engineers do a terrific job while testing the solution, ensuring the quality of the development. However a UAT is not a copy/paste of the test cases, take into consideration that the perspective must be the user’s one (which mostly is non-technical), thus each step should be clear, concise, and avoid jargon. For instance, if the user should enter their credentials rephrase it to make it easy to understand, something like “Fill in the user name and the password field with the following information….”
- Double-check the environment. UAT is an activity performed before a functionality hits production, then an environment such as staging is more appropriate (if you are using Salesforce, a Partial Copy Sandbox is a good choice). At this point, you are making sure that each UAT participant is able to access the environment (for Salesforce double-check that users are created in the sandbox and have the appropriate permissions granted)
- Verify data and links. Related to the last point, if the user is expected to interact with several interfaces or fill in some data such as passwords, tokens, IDs, etc.; that information should be explicitly provided in the related step. Moreover, if an input is unique, that should be mentioned upfront, and an example per participant must be provided. It is a good idea to ask the devs or QA for a set of information and let them know it is going to be used in UAT only.
- Select the UAT users (including Subject Matter Experts) to join the activity. Be mindful to include people that will be interacting with the solution, where SMEs take an important role too since that can represent final users too. Once you have confirmation, make sure to copy your template accordingly, so that each person has their own.
- Set up the meeting and provide support. Explain the dynamic to the participants. Remember you are not the one executing the UAT, of course, to get started with the activity you can share your screen and use a couple of steps to show how each one should be reviewed and the template completed, but it is a hands-on activity for them. Pro tip: ask your participants to record their screen, if any bugs or questions are raised you will know where to refer.
- Bug’s prioritization. If any defect is reported, as a BA you should identify and capture it. Heads-up, UAT is not a space for new requirements, thus before reporting the bug to the team review the scope and the priority if, in fact, it is a bug.
- Sign off. Once the bugs have been corrected and retested, you are ready for the sign-off with a fully tested solution on both sides (IT team and SMEs)!
Following these 10 steps, User Acceptance Testing may look like a time-consuming activity, but conducting it as part of the development cycle adds value and assures users will have a seamless experience once the new solution hits production.
If you’re interested in BA content, check out our blog The Strategic Role of the Business Analyst in Salesforce Implementation.
