You’ve worked for weeks or months with your development partner on your new custom software project that is going to take your business to the next level. You’ve had multiple meetings to discuss strategy and gather requirements, weekly touch points with your product manager, approved budgets and wireframes, and more.
But now your partner is asking you to put even more time and effort into testing?
What is that? Why is it important? Do you really need to pull your users away from their jobs to participate?
Keep reading to find out why you don’t want to overlook this important phase of your software project, along with tips to be successful at it!
What is User Acceptance Testing (UAT)?
First, what is the user acceptance testing phase exactly?
User acceptance testing (UAT) is the phase in the software development life cycle that determines whether the new software system has met the project requirements.
In other words, it’s when your end users sit down and begin using the software in real-world scenarios to make sure it works as it should. During UAT, you ask, “Does the software meet the project requirements we agreed upon?”
Is the purpose of UAT to find “bugs” or glitches in the system? Yes, but finding bugs is only one part of the process. But, you can also find out a lot more during this phase.
SPARK Tip: It’s common to confuse UAT with user testing. User testing is the process through which the interface and functions of a website, app, product, or service are tested by real users who perform specific tasks in realistic conditions. User testing is a way of getting general feedback on an app’s usability and is different from testing whether the specific project requirements are met.
Why User Acceptance Testing Matters
While development teams run their own tests to minimize bugs and to make sure the software works as intended, this testing phase is designed specifically for the client and their end users to test the software. It’s your chance to “get your hands dirty” and confirm it was built according to plan and works as expected.
Yes, you may find some bugs during this phase. But, more importantly, you may discover and identify gaps in software’s logic or processes. You can also have “a-ha” moments, or realizations that “it would be nice if…” or “if only we could…” These usually don’t happen until you actually use the software. In general, during this phase, the last 5% of an application’s details get ironed out and fixed to make it ready for your business.
However, UAT can often get overlooked by teams. You might not take the time to do it. But, here’s why you don’t want to skip this phase.
Real-word Example: Good Experience vs Bad Experience
SPARK Systems Analyst George Joshua shared two of his own experiences working with clients during the UAT phase.
“SPARK once worked on a time tracking app that synced to an internal enterprise system for a construction company with union employees. Time tracking for union employees can be incredibly complex, with layers of overlapping rules that complicate business logic.
After we worked with management on building the app, we entered the UAT phase. They brought in some front-line employees to test it. While we had tested the functionality on our end, the engaged users found some gaps in the app’s logic that would have made it difficult to use.
Because this client took UAT seriously, we were able to use their feedback and make adjustments before we began a company-wide rollout. The rollout ultimately went very smoothly. But it wouldn’t have if our client hadn’t invested time and effort in the UAT process in the first place.”
On the other hand, when companies don’t fully commit to the UAT process, there can be issues.
“Before SPARK, I once worked on a scheduling app project to help coordinate and report on snow removal for corporations. But when it was time to enter the UAT phase, the client’s management didn’t want to involve the dispatchers and drivers who would be the main users of the app. So, they signed off that everything worked. But when the app launched, their users quickly reported it had missed the mark in a few places. Since these weren’t addressed until after go-live, it caused a months-long delay to finish the project and doubled their budget spend.”
Read stories about successful business tools launched with SPARK →
Tips for Successful User Acceptance Testing
UAT is a critical last step in ensuring the success of your development project. As you prepare for this stage, here’s some tips and best practices to follow.
-
1. Plan ahead for sufficient testing time and effort
User acceptance testing is more than just a formality. You don’t want to allocate 15 minutes, play around with the new software a bit, and say “looks good.” Instead, plan ahead and consider scheduling blocks of time when your employees (or end users) can perform testing.
SPARK Tip: Write out your testing plan, no matter how basic. You want to give your team a clear idea of the purpose of testing (meeting business requirements), what to test (use project requirements), and how to do it. In general, you should test your most commonly used processes and test the software using real data and scenarios.
-
2. Ask real end users to test
Always involve real end users during UAT. If you’re the VP of operations or head of IT, you might think that you know enough about what is needed to adequately test the software and don’t need anyone else. But this could lead to oversights– yours users could have processes and needs you don’t know about. And these gaps might be only discovered after the software goes live– leading to project delays and budget increases as shown above.
-
3. Try to break the software
Yes, try to break it! While testing, ask users to push the software’s limits with edge cases or situations that are unlikely to come up, but could. For example, enter incorrect data, push buttons out of order, etc. This is the best way to find bugs or gaps in the software’s logic.
-
4. Use different platforms
Test your new software on multiple platforms. Depending on the software, this could involve testing it on both MAC and PC computers, both iOS and Android mobile device, and Chrome, Edge, and Safari internet browsers. The software could behave differently across different platforms.
-
5. Set a limited testing window
Your employees are busy. UAT testing could fall toward the bottom of their to-do lists. So, decide on a specific and narrow window for testing to help them prioritize it. Otherwise, if the window is too big, it can cause users to disengage from the process.
-
6. Document and track what you find
Be sure to track and record any testing outcomes in one location, even just a simple shared spreadsheet works well. You can track the tester’s name, date, issue (what happened and what should have happened), and screenshots.
-
7. Communicate constantly with your development partner
If it hasn’t been done already, set up a regular meeting with your development partner to track and discuss feedback. Communication is crucial to drive the project toward a successful conclusion. So when you find issues, you can work with your development partner to fix them.
Don’t Overlook the UAT Phase
Without sufficient UAT, bugs won’t be uncovered and gaps in logic could be missed. At launch, your product might not work as needed, leading users to distrust it or even eventually classify the project as a failure.
Remember that the purpose of UAT is to make sure that the software product meets your project requirements. And the best way to do that is to involve your end users. It’s more than worth your time and effort!
Want to learn more about how to prepare for a successful experience with a custom software project? Check out these articles next:
