User Acceptance Testing Best Practices

Beth Rolfe |
 Salesforce |
 Jul 6, 2022

User Acceptance Testing (UAT) Best Practices, aka: “Have we produced what our customers want?”

Introduction:
A common misconception is: “Roycon, you’ve already built and tested this, why does the need exist for us, the customer, to also test? This is your expertise, not ours!”

UAT, or user acceptance testing, is arguably the most important part of any implementation project. After we’ve spent countless hours working together to define requirements, write user stories, worked in sprints, done demos & subsequently adjusted… it’s now time to hand over this project for you, the customer, to use as you would day to day.

We’ll write the scripts for you, we will provide a log to share feedback, and we’ll host meetings along the way to receive your feedback, but we need your help to dive in and do the testing itself.
Think of it like a test kitchen scenario – we provide the recipes, the fridge is stocked, the table is set…but we need you to prepare the dishes to ensure they work for the preferences of you and your guests.

What exactly is UAT?

User acceptance testing (UAT) is the last phase of the software testing process. During UAT, actual software users test the software to make sure it can handle necessary tasks in real-world scenarios, according to specifications. UAT is one of the final and critical software project procedures that must occur before launching a new software to the market.

  • DevelopMentor puts it more succinctly when they describe user acceptance testing (UAT) as:

The goal of User Acceptance Testing is to assess if the system can support day-to-day business and user scenarios and ensure the system is sufficient and correct for business usage.

We want to ensure that we’ve produced exactly what the end-user needs, will use, and makes sense for them. We can erroneously design a system that won’t be adopted because it’s too complex, doesn’t suit the needs of the end-user, or has a snag that will deter your end user from logging in again. We want a system that you love and works for your needs in the real world.

We get excited thinking about your end users saying “Dang, that Roycon made this easy for me to do my job!”Rather than the alternative…which I won’t list here, but I bet you can improvise what that might sound like!

In summation, we at Roycon ask, throughout the process: “Have we produced what our customers want?” Our customer is you, the company that has engaged us to build your system.

I assert that UAT is your chance, as our customer, to explore the same question. Who is your end-user, and have your produced what they want? Does this work for your employees who are doing data entry? For your customer who isn’t an employee, but logs in online to make a payment?
UAT is your final dress rehearsal before the big show. Get out there and break a leg!

Top Five Best Practices for UAT

#1 – Login As Your Users Do

Roycon is unable to use the system the same way your employees, your customers, and your management will!

We want your users in the system to use it as they would during a typical work day, trying to create output as they want it to look when the implementation is complete. If you have users logging in to check the status of their product, we want you to login as they do, and be mindful of the comments and help desk inquiries you get. We want the system to be perfectly calibrated for your use and tested in ways we at Roycon simply can not know.

#2 – Identify your testers early

Identify your testers early and block time on their calendars to test. A variety of different types of testers explored later in this article is imperative. UAT takes time to do and ensuring your testers have time to work in the system blocked on their calendar, and that they aren’t booked in calls and meetings is imperative. Your end-users will use the test scripts we provide, as well as simply poking around in the system to discover any fixes required.

#3 – Identify Users, Roles, and Practice UAT

Identify users, and their roles, and have them practice logging in before UAT actually starts.
Are logins setup and passwords correct? Have you identified a variety of roles/permissions to be testers? Is the browser they’re using compatible with your build?
…like arriving to the airport without your passport before an international flight, UAT will be delayed (or worse!) if your user’s logins are not working when it’s time to log in and get started.

#4 – Use Our Log

Use our provided log, in the shared space provided, to document errors as you find them. The more detail, the better! By adding detail, our team can recreate the error and work out action steps to move forward. Screenshots, logging any small details, and when and how the error occurred all help to make our troubleshooting easier and faster.

#5 – Costly Reminder

A reminder that NOT doing this can result in some serious consequences….rework, which costs you more time and more money, and, possibly, angry customers when they log into the “new and improved portal” and it doesn’t allow them to do what they need. The worst possible outcome is that users simply refuse to use this system after a few tries because it is such a mismatch to their needs. We want you happy, and your customers delighted with your new portal.
In short, we do NOT want to be the U2 album that Apple forced on us all in 2014; unwanted, unnecessary, and something users hate.

Conclusion:

At the end of UAT, we should ask: “Have we produced what our customers want?”
If there are errors, it is imperative to find them now, during UAT, rather than later, when this is a live production environment. This is our only goal with an implementation. To produce what our customers want, need, and will use.

About Roycon, Salesforce Implementation and Consuulting Partner
We’re an Austin-based Salesforce Consulting partner, with a passion and belief that the Salesforce platform’s capabilities can help businesses run more efficiently and effectively. Thanks for stopping by the Roycon Salesforce blog, be sure to subscribe. If you need help, or just feel like talking Salesforce you can always contact us. Thanks for reading and as always, happy building!

AUTHOR

Beth Rolfe

Beth Rolfe

Salesforce Project Manager

Beth brings her very unique background to interject a hospitable flavor to the project management experience. Marrying attention to detail and adherence to timeline to ensure your project crosses the finish line, Beth has been in software since 2017.

Related Articles

Inherited Salesforce Org | Back-end Review

Inherited Salesforce Org | Back-end Review

Back End Review: Reviewing Technical Debt | Integrations | Data Now that you have high-level information on your new company, it is time to dig under the hood of your Salesforce org. What is under the hood you ask? Well, I can’t tell you – that will be up to you to...

read more
Inherited Salesforce Org | Where to Start

Inherited Salesforce Org | Where to Start

,Part I: Where to Start | Understanding the Business | Identifying Processes Starting a new position as a Salesforce Administrator or Consultant can be overwhelming, especially if you are relatively new to the Salesforce ecosystem. This is only exacerbated if you are...

read more
10 Salesforce AppExchange Apps You Should Know About

10 Salesforce AppExchange Apps You Should Know About

The Salesforce AppExchange While Salesforce is a highly powerful tool used to support any organization’s day-to-day functions, there are many Apps available in what is called the Salesforce AppExchange to help enhance the solution to support any organization’s needs....

read more
Tweet
Share