The phrase “UAT” is a familiar one within the software development world, but what do those three letters really stand for, and more importantly, what do they actually mean in terms of project timelines and success?
As someone who has been working in the web development world for several years now, with experience in both Quality Assurance and Business Analysis, I’ve been compiling several tips and tricks for managing internal and external testing periods for some time now.
UAT can be one of the trickiest parts of any project – especially when there is a degree of complexity that needs to be explained to the client/testers and/or a tight timeline. I thought it would be useful to share what has worked for me, in order to make all of our lives a little bit easier and the overall quality of our various projects that much better. In short: I’m here to help!
First, let’s start with a simple introduction to UAT.
What is UAT?
“UAT” is an acronym for “User Acceptance Testing”, which refers to the testing that needs to be done by actual users of a desired application, site, or software before it can go live to the general public.
What’s the Story Behind UAT?
This period of testing is also commonly referred to as “Beta testing” (for fellow members of the gaming community, the phrase “open Beta” might also come to mind). It’s definitely important for companies to do their own internal testing, but a product shouldn’t go live until it’s tested against a user base unfamiliar with the code structure, development process, and desired results.
For those of us in web development and digital marketing, this often comes down to what our client contacts think of the finished product: UAT means that it’s time for them to do some testing on the product they’ve commissioned, before they sign off on its live release.
UAT is important because it helps demonstrate that the business requirements are operating in a manner suited to real life users – not the people who spent hours and hours building the website or application, but the people who will actually use it.
Ready to manage some UAT? Let’s get to it.
Part 1. Planning UAT
UAT traditionally comes at the very end of the SDLC (Software Development Life Cycle), directly following internal testing (or Alpha QA). To ensure that UAT runs smoothly, it’s important to outline a UAT strategy during the project planning period, same as you would for internal or Alpha testing.
Create a Unique UAT Plan
It’s tempting to think that Alpha and Beta testing can be planned exactly the same way – after all, both require test cases, and both require testing the exact same application, website, or software. Don’t be tempted! Remember: Even though Alpha and Beta testing focus on the same product, completely different audiences are doing the actual testing.
A dedicated staff of trained QA professionals familiar with the architecture of the product usually handle Alpha testing, whereas UAT is tested by clients and/or additional users who have not been involved from the start of the project. The idea is to make sure the product works (and is satisfactory) for those who have been trained to break it and for those who haven’t.
That being said, designing test cases for both Alpha and Beta testing doesn’t have to be a tedious effort. Aspects of the Alpha test cases can be recycled for UAT with careful editing and consideration.
UAT Planning Best Practices
Keep the following in mind when translating Alpha test cases to UAT test cases:
Simple, clear language. Clients and users may not be familiar with technical terminology or code. Adjust all test cases to be as clear and straightforward as possible, using simple day-to-day language.
Keep real life applications in mind. It’s more important to tackle every possible way to break the product during Alpha QA than it is during UAT. Test cases used during Alpha QA that involve more fringe user scenarios, or more complicated steps, can be dropped for UAT; the idea is to catch the majority of issues during Alpha QA anyway. Overcomplicating UAT can lead to more confusion and additional questions that may or may not be appropriate so late in the project timeline.
When editing Alpha QA test cases for UAT, be sure to pay special attention to professionalism and audience; abbreviations and shorthand references used among internal testing teams may not be appropriate here. In the digital marketing and web development world in particular, our UAT is often handled by our clients – the people paying us!
Some clients and outside users may not be as familiar with testing documentation – what it looks like and how it should be used – as dedicate QA professionals are. Be sure to provide clear directions and outlines. Creating a UAT checklist to walk the client or user through the entire testing process can be especially helpful alongside the actual test cases themselves.
Be clear about timeline. Make sure the UAT testers know exactly how much time they should be spending on any given test case, and when they should report back all findings in order to meet the project deadline. If the UAT period is shorter than the internal Alpha testing period, be sure to adjust test cases accordingly, and drop any that seem extraneous or less relevant to real life application.
With careful planning and consideration ahead of time, UAT can be a smooth and easy process. Providing the right documentation is key.
Part 2. Dealing With Defect Resolution
Defects are inevitable: that’s just a fact of life. Nothing ever turns out perfectly on the first try (as much as we wish it would!). It’s the job of a company’s QA department to ensure that the majority of defects and issues are found and resolved during Alpha testing, rather than during UAT. That being said, UAT almost always produces at least some defects, issues, and questions based on client/user testing. Why? Because of the different audiences!
In general, QA professionals are primarily trained to “break” websites, applications, and softwares, and usually focus on complexity, browser differences, functionality, and code; UAT tends to focus more on usability, brand, and content. When UAT is handled by clients, it’s important to keep in mind that this may be the first time they’ve had the chance to get a glimpse of their final product in action: the thing they have been waiting all this time for! Client testers will likely find that some of the features and ideas they had at the very beginning of the project so many months ago are either no longer relevant, or don’t work exactly as they expected in real life application.
One of the hardest things to do as a client services professional, as well as a QA analyst, is manage UAT defect resolution. Determining what is or is not in scope to fix so late in the game based on client questions, needs, and desires isn’t exactly easy: it takes diligence, careful consideration, and excellent communication skills. Sometimes, change orders are needed and followed through with; other times, clients can be talked out of making big adjustments right before launch.
Defect Resolution Best Practices
Keep the following in mind when managing UAT defect resolution:
Provide the clie
nt with a clear and organized way to log their defects and questions. Shared test matrices and spreadsheets can be designed for this purpose, or programs like JIRA and Basecamp can be used. Whatever the preferred process, make sure everybody is aware of how it works. Sometimes it is appropriate to provide training ahead of time.
Be mindful of defects that result from contexts that are outside of your development team’s control. An example would be Internet Explorer browser compatibility mode. Some clients use corporate IT accounts/machines that are pre-set to compatibility mode or other less-than-ideal internet settings. Most websites are not designed to function within compatibility mode; professionally let the client or testers know that they may see more defects if they are unable to turn this mode off or use a different browser.
Always encourage testing best practices, especially with clients who may not be familiar with the ins-and-outs of web development. Again, communication is key. Let testers know up-front that it’s best to clear browser cache and cookies before any new testing session, for example. Be sure to sound helpful, not patronizing! This will prevent more defects, in the end.
When it comes to troubleshooting UAT defects, patience is imperative. Again, these are likely testers unfamiliar with the intricacies of code, web development, or digital marketing…be patient while they ask questions and get to know how their product works.
Some people are nitpicky – especially when the future of their company’s online presence is at stake (so who can blame them!?). If a lot of defects are coming in during UAT, it can be helpful to organize by priority: low, medium, or high. Don’t be afraid to ask the client from the start to list out what they feel are priorities, and to provide guidance on what they would like to see fixed before launch, and what they feel could be pushed to post-launch. WIth a little patience and understanding, a long list of defects doesn’t have to feel intimidating; more often than not, a lot of the requested changes can be easily handled post-launch, with simple content updates.
Be sure to get sign-off and final approval once all UAT defects have been resolved. Come up with a clearly defined deadline, and do your best to stick to it. Be sure to have the client or testing team indicate their acceptance that the product is ready to go live and meets all requirements; getting this in writing (or via email) can be particularly useful in case there are concerns or additional questions post-launch.
Together is Better
In the end, the key to a successful UAT period is communication and trust. Working together with the client or testing team will produce the best possible end results. Schedule regular check-ins, respond readily to emails and phone calls, and be respectful, patient, and understand at all times. We’ve all encountered our fair share of difficult personalities, but in the end, a little bit of kindness, as well as professionalism, goes a long way.
What successes have your or your company had with UAT? Share more tips and tricks below in our comments section, and be sure to share or “like” this post if you found it helpful!