Confessions of an Operations Guru Turned Legal Ops Novice, Part 8:
Why User Acceptance Testing Matters to Clients
When I had my first experience with user acceptance testing (UAT), I had no idea what it was or why I should be doing it. And it was honestly hard to learn about from a client perspective. Most articles I found related to why it’s important for software developers to include it in their implementation and sign-off process but didn’t tell me how it benefited me, the client.
So today, we’re going to talk about user acceptance testing in the client’s terms. We’ll go over what it is, why it’s important, and how you can execute it to gain the benefits.
What is user acceptance testing?
We’ve all heard of beta testing. It’s an important part of making sure products work in the real world. If you’ve ever waited to update the new software release on your phone until all the bugs are worked out, you know that there is always something that doesn’t quite work the way it was designed to (at least at first).
This isn’t a problem with the technology, a failure to define the project properly, or mean that the update was coded improperly. It just means that, once you put a new tool in the hands of the users, new scenarios pop up that couldn’t be anticipated. This can sometimes result in bugs or other pain points.
User acceptance testing can be thought of similarly to beta testing. When you build customized software, it’s designed to meet specific needs of the users. Implementation teams work with the developers to account for as many scenarios as they can, then the software is built. If the software is then handed to the client and the developer disappears, there’s no way to work out the kinks in the software once people run into unanticipated scenarios. Enter, user acceptance testing.
Why is user acceptance testing important for clients?
If your software doesn’t meet the user’s needs, or is hard to use, it doesn’t get used.
Okay, that’s a little bit simplistic, but if you’ve ever implemented…anything…you know that there’s always at least one person who bows out at the first sign of a challenge. User acceptance testing lets you solve these problems early so that you can keep your team engaged in your software, and so that your software gives you the ROI you expected.
Going back to products working in the real world – before the software is built, you and your team work with the developers to solve a specific set of problems and account for specific scenarios. Once the software is built, it’s thrown into your business processes and you need to make sure that it’s open/malleable enough to account for outliers and specific enough to save you time and energy in your work day. For instance, if you’ve set up contract management workflows where automations are in place surrounding finance and marketing approvals, but find that those automations aren’t accounting for some unique scenarios, you have the opportunity to adjust them during the testing period.
User acceptance testing protects you, the client, against getting a software product that doesn’t work in your context.*
*It should be noted, most UAT agreements cover a specific set of adjustments. You may discover needed changes that are outside those adjustments, and those can incur additional cost. Be sure you work with your development team early to avoid large, costly adjustments and to understand what is covered by their UAT agreement.
How do I execute user acceptance testing?
This shouldn’t be surprising at this point, but you execute your UAT through…the users! They are a critical part of knowing if your software actually works the way it was intended, and you can’t truly move forward without their input.
I’ve said it before and I’ll say it again. This is another point in your process that will go much more smoothly if you got buy-in early. If you did, not only might your users already know what they should be testing for, but they’ll know more easily if something is not working properly. The more involved your selected testers are in the design process, the more thorough your testing process will be.
OK, so how do you test? There are a lot of opinions on this out there. Depending on your position in your company, the number of people using your software, and the number of features/dependencies in your software, you might need to have a very thorough testing project plan. I’ve seen some testing plans designed for CTOs and their teams that would take weeks or months to execute – and in some circumstances, this is needed! But today, I’m going to go through the basics of what you’d want to look for – especially when it comes to legal operations solutions.
While you wait for your software to be built:
- Make a list of all the matters/contracts you set up in the software. Create as many use cases as you can think of for each one using different dependencies or workflows (do you have a financial cap that sends a contract to finance approval? Test the contract both over and under that cap).
- Recruit your testing team and outline a plan. Let folks know you’ll need their help testing the software. Make sure they know that this time investment is so that they get the best software possible and so that it makes sense to them. Be sure to bring in people from different roles that will be using the software differently. Use the sales team to create some test sales contracts – use the legal team to make sure they got what they needed from sales. Let your approvers know they might be getting test contracts/matters to approve and make sure they are receiving the information they need with the approval request.
Once your software is ready for testing:
- Carry out the plan you made with the team.
- Check your matters/contracts
- Check your fields/requirements (do the field names on intake make sense to the people filling them out?)
- Check your notifications, alerts, approvals, and emails
- Confirm your templates are populating the way you desire
- Confirm your clauses are populating properly
- Run through each of your workflows. Carry out every action and make sure that, as you manage a contract or matter, the workflows accomplish what you need them to (and that the order makes sense).
- Check permissions. Take this opportunity to ensure that your user groups can see what they need to (and not see what they don’t).
Completing the above check list will ensure that your software is running smoothly. There may be additional matters of preference that can be negotiated through managed services, if your solution offers that kind of service, but you’ll be able to get real-world experience out of your users so you can confidently sign off on the product you invested in.
