You know you need custom software. Now that you’ve jumped in, you realize how many strange words these people use—API, agile, scrum… the list goes on forever. One word you hear over and over is “UAT.” It sounds like it involves you, but what does it mean? How do you do it? Why is it necessary?
I’m so glad you asked. Here’s a practical guide to the UAT phase of your custom software journey.
Let’s clear up the acronym first. UAT stands for “User Acceptance Testing.” It’s the process you go through to make sure the custom software you’ve commissioned is what you need.
“But I have no idea how software works—shouldn’t someone more qualified test it?”
Actually, you are the most qualified person to perform UAT. Remember, the “U” stands for “user.” The goal of UAT is not to establish whether the inner workings of the code are good (that’s another issue for another group of people).
Instead, the goal of UAT is for you to sit down and make sure that the custom software you’ve commissioned works for you and your business. And you’re the best one to do it, because you’re the one who will be using it.
“What if it doesn’t work? Can I return custom software?”
The name UAT can be misleading. “Acceptance” implies that you could also reject the software if you decide you don’t want it anymore. Personally, I think User Confirmation Testing would be a better term, since you’re confirming that what you’ve received is what you agreed on.
Let’s say you’re having your final wedding dress fitting (I know, bear with me). You’ve already decided what you want and the dress is almost complete. You try it on and notice that it’s a little loose and the hem is a little long.
You can’t return a custom wedding dress, and you don’t want to, since it’s almost perfect. Some tweaks need to be made, but the overall results are there as you expected. So you confirm the dress, have the alterations made, and get on with the wedding planning.
That’s UAT. You’re confirming that your expectations have been met and identifying any tweaks that need to be made before using the software for real.
It’s unlikely that the software would need to be overhauled or large changes made in this phase since the software was already made to your original specifications.
You’ve probably guessed it already. The point of user acceptance testing is to make sure that the custom software does what it’s supposed to do.
The goal is to work out all the kinks before you use your software for real. It helps the transition process go more smoothly when you do start using it in real life, and it helps you feel more confident.
Back to the wedding dress—can you imagine a bride putting on her dress for the first time on the day of the wedding? A million little things could go wrong. What if the hem is too short or the waist is a little too tight? What if a button is missing?
All those issues could be solved easily two weeks in advance, but it’s much more difficult to fix a button while she’s walking down the aisle.
UAT is the fail-safe before the launch.
The “when” of user acceptance testing depends on the company developing your custom software. If you do much research online, you’ll find that the usual time for UAT is after the software development is done but before actually making the software live for real use.
In other words, it’s the “final fitting.”
But just as a bride usually has multiple fittings throughout the dress-making process, UAT can also happen throughout software development.
This is how you get to the end-of-project testing with confidence that the project won’t need an overhaul—you’ve already seen most of the project.
This is our philosophy at EduSource. We want you as the user to be part of the software development process as it’s happening, not after it’s already over.
We like to break projects into blocks of functionality that take two or three weeks to complete. At the end of every block, we have you do UAT on that part of the project. That way we catch issues early and make sure the project is meeting your needs as we go.
If any changes need to be made, it’s much simpler to do them during the process rather than retrofitting afterwards.
You, the user, should do UAT. But why hog all the fun for yourself?
Of course, if you’re the only one who will be using the software, that’s one thing. But it’s an unlikely scenario.
This is more likely: You have an employee who manages customers, another employee who manages logistics, and a third employee who manages finances. And you manage employees.
That’s four unique uses of your software. If you’re the only one doing user acceptance testing, you’re only being 25% as effective as you could be if you and your three employees all tested the software.
Will your customers be using your software? They should do UAT as well. Not en masse—that’s a bad idea. But consider whether it’s feasible to have someone, perhaps a trusted customer or a reliable friend who isn’t familiar with your business processes, test that your software is useful in that capacity.
Make sure that the users testing your software accurately represent the users who will be using your software. It will ensure your software is universally effective.
When it comes to UAT, we talk about location in two different ways.
The first is environment. This isn’t environment as in “save the.” When software companies say environment, they mean the virtual space where your software is located. Throughout its life, your software will live in multiple environments.
It starts in the development environment, where the software developers create it, and ends in the production environment, where the finished software will live so that you can use it in your business.
In between those two, though, is the UAT environment. This is the location where your software lives while you test it.
It’s basically an up-to-date copy of what the developers are continuing to work on in the development environment. It allows you to have access without requiring the finalization of being in a production environment.
The second “where” is the actual, physical location where you test the software. Sometimes EduSource does guided UAT at our office with clients, but we don’t consider UAT complete until you’ve done it on your computer at your office.
Why? Because some things just can’t be anticipated.
We recently had a client who loved the software we were making for him when he saw it at our office on our high-definition monitors. But when he got back to his office and looked at it on his monitor, he realized he couldn’t read the type on the webpage because his company’s monitors didn’t have high enough resolution.
We increased the font size and the issue was resolved, but we wouldn’t have known that was a problem unless he tried the software on his own equipment.
What you’ve been waiting for: the actual “how to” of user acceptance testing.
Go in with a plan
Make note of the key functionality your custom software should be able to perform. An easy way to do this is to pull out the requirements list from your original meetings about the software.
The company should have the list if you don’t anymore (and they may provide it to you as part of the testing process.)
Use the list to guide your testing. Remember, the point of UAT is to confirm that the software lives up to your original needs.
Use real data
Make sure to use your software for a normal workflow situation with real data. Don’t just use your checklist, use the software.
Let’s say you have a landscape company. Don’t just check that you have an orders page. And don’t just test your software by creating an order for “widgets” that cost $100 per item.
Instead, create an order for “red cedar mulch” that costs $38.56 for three cubic feet.
This way, you’ll know what results to expect, and you’ll notice if the results look funny. (For example, maybe you forgot to specify in your requirements that mulch is sold in cubic feet. You wouldn’t know that was missing unless you used a real scenario for testing.)
Keep track of what you’re doing
This is vital. Why?
If you encounter an issue while you’re testing, you can tell the company “the cost report isn’t working.”
That’s better than nothing. At least the company knows there’s something wrong with the cost report.
What’s astronomically better is if you say “when I view the cost report and click on the sort-by-date button, nothing happens,” and take a screen shot of the problem.
That tells the company exactly the issue you’re experiencing and gives them the information they need to fix the problem effectively. Your custom software is tailored to your business needs, and you are the most knowledgeable about your business. The more specific you can be in your feedback, the more helpful it is to the developers who are fixing the issues.
Be thorough but not perfectionistic
The software should do what you expect it to do. So put in the effort to make sure your software does what you’re expecting in every way you can think of.
But keep in mind that the software isn’t production-ready (yet). So if you find a word misspelled, go ahead and make note of it, but don’t panic.
The point of UAT is to make sure the software does what it’s supposed to do. If you don’t love the color scheme, it can be changed. But don’t get distracted from your main mission—confirming the effectiveness of the functionality.
That’s it. User acceptance testing is the process that allows you, the user, to confirm that your custom software is everything you expect it to be.