UAT or User Acceptance Testing is when your application gets tested by the subject matter experts and users. It is (one of the) last crucial steps to get your application put to real-world usage in production.
While every organization, user group and project are unique and bring their nuances to how UAT should be executed, here are a set of best practices that may be treated as more common.
We will divide UAT into four main categories -
- User readiness
- Application readiness
- Environment readiness
- Test readiness
All three categories will go into a “UAT readiness plan” -
- A set of activities for UAT readiness that covers overall plan, people, pre-requisites and other activities in Microsoft Project, Excel, or a similar tool
- Repeatable set of tasks that can be applied across different projects for the same org
- Highlight dependencies between tasks / phases and critical tasks
- Provide critical path in the plan and key dependencies / milestones
Here’s a sample SFDC UAT prep plan in Excel format.
User readiness can make or break UAT and subsequent phases.
There can’t be UAT without users. - Anonymous
Never assume anything when it comes to users. While the IT team likes to see the application as being central to the universe, it is seldom the case. Users have other “less important” things like running business - convincing customers of the value in our product, visiting stores, providing support and such. Providing time for UAT can be seen as a chore - especially when you have UAT overlapping with critical business activities.
A few considerations that can help -
- Do not assume 100% user involvement for 100% of the time. Plan for contingencies and get more users onboard as part of the contingency
- Communicate through emails and webinars on the application changes. Generate excitement on the end product. Larger releases / completely new applications may need information posters in all the key areas (read: cafeteria), quizzes with exciting prices (a cup that proclaims how great the company is), et. al.
- Recognize the importance of application training. Set clear expections on what training is about - will that be a hands-on workshop, what types of users can participate, who will train who, and pre-requisites. Share pre-read materials to help users get comfortable with the scope and activities of training
- Involve business SMEs and functional analysts to decide all the roles that need to be tested. Map roles to available users, and if possible, make them generic. Users should be comfortable playing the test role
- Provide clear and simple directions on how to test application, log findings, and log defects. A cheat sheet with all application URLs, key activities and contact details is much better than a 30 page document. Set expectations on how users can work with the resolver teams and functional analysts to discuss questions, resolve issues and who they can reach out to escalate problems
- It is important to set clear expectations on what a successful UAT looks like. Define UAT exit criteria that includes conditions for sign-off, exceptions including any open defects that can be carried forward, completion of test case execution, etc.
Getting the code and data ready for testing is a big enterprise by itself.
- Set clear and concrete UAT entry criteria. For e.g. there should be zero High or Critical open issues, 90% of test cases in SIT should be executed and passed, etc.
- Set a simple status indicator that works for all stakeholders to communicate significance of application prep tasks. Plan buffer period, and have fallback measures on paper and ready to deploy - just in case the plan does not work
- Track milestones of application code/ configuration hand-offs' - even when the development and DevOps team are the same
- Track application runbooks with detailed tasks of what goes into deployment. This should be executable by a third party with enough technology knowledge. Manual tasks during deployment are the last resort and should be kept to a minimum
- Decide on what kind of environment you need. Budget for salesforce nuances vs. budget - e.g. who will use full-copy sandboxes in the org, how many users can be made available (license requirements), the volume of data you need for testing, etc.
- Create an enterprise architecture and infrastructure architecture diagram to serve as a common reference to all teams on how overall system integration work across applications
- Decide on batch job schedules. Schedule a higher frequency to help users to test faster without development team intervention
- Consider things like org-wide / compliance-driven change-freeze periods applicable for non-production controlled environments
- Scramble sensitive data in UAT. Make sure users know about scrambled data and what they need to do for data testing
- Create test cases with finite test cases in a range (e.g. 1 test case can have 5-12 steps). This helps users and others in the team estimate time and effort required to execute test cases
- Always keep traceability matrix updated. There has to be a clear mapping between user stories and test cases - at all times
- Provide a clear, well-sequenced test plan with no. of test cases assigned to specific dates and users. Do not leave it to the SMEs and end-users to figure this out, do not “play by wire” during test execution
- Provide examples of what an ideal defect looks like and how an ideal test scenario gets executed - a video or a visual representation of the process will help rather than a detailed 30 page document full of text
- Put a monitoring mechanism in place to show execution progress with simple charts. Establish communication plan to get this to users through email, Teams or equivalent mechanism
Even with the utmost care, UAT can throw up surprises to all stakeholders involved in the project. Creating a workable plan to get to UAT is just the first of many steps to ensure a successful product :)