Here’s how to manage your User Acceptance Testing.
First, let’s clarify what UAT is
User Acceptance Testing (UAT) is the final stage of any software development life cycle. UAT is a testing exercise to validate that the software developed will meet the users needs when used in a real world environment. Users will test the software to see if it can perform the required tasks it was designed to do in a real-world situation.
UAT tests the adherence of the newly developed software, to the business requirements. It also tests the usability, user friendliness and performance of the new system or feature.
Who participates in the UAT?
- End users
- Subject matter experts
- Product/Project Manager
- Product Owner
- Scrum Master ( agile)
- Business Analyst
- QA team
- Developers
The end users and the subject matter experts are usually the main testers in a UAT. The product team, QA and Business Analyst can assist in testing but they are usually very close to the software and should be there to support the end users and SMEs.
The Product/Project Manager or Product Owner primarily helps in the UAT by organizing the resources and making sure the test environment is being setup. They also help to set the priority for the bugs that need to be fixed before launch.
The Scrum Master helps the UAT by removing any technical roadblocks and keeping the developers informed on outcomes from the UAT.
The Business Analyst usually owns the UAT exercise and is the one to write the UAT test cases, organize the testing exercise, develop the issue log list and answer any questions on expected behavior based on the business requirements.
The QA team participates in the UAT by creating all the bugs in the appropriate tool and making sure the developer can understand what to fix.
The developers participate in the UAT by fixing all the bugs discovered during testing and making the fixes available to be retested.
How to prepare for your User Acceptance Testing(UAT)
- Know the existing functionality
- Know the new functionality
- Think through edge cases
- Write test cases at a high level to allow testers to explore
- Setup the environment to be production-like
- Prep the data you’ll need
- Ensure testers are advised early
- Make sure testers have the right access and permissions
- Create a system for logging bugs ( A single spreadsheet works well!)
- Setup meetings at the end of each test day to prioritize UAT bugs
- Run through the test yourself to make sure its easy to understand
During the UAT sessions:
- Business Analyst should be available to answer UAT questions
- Testers should be focused only on testing ( not multitasking with their regular job!)
- Testers should NOT be creating bugs in the official bug tracking tool (for example – in Jira). This will cause duplicates and make it hard to manage. It’s better to have testers create the bugs in a spreadsheet that can be prioritized by the product team later.
- End and reschedule testing if you encounter bugs that will cause future tests to be invalid.
Managing the UAT
- Start with a testing kickoff meeting – explain the test environments, confirm that the testers have access to the environments and test documents needed.
- Explain the nuances of the test and issue logging sheet
- Make sure you or are accessible to answer test questions
- Meet with product/project manager or product owner to prioritize bugs after testing sessions
- Designate one person to create the bug tickets in the issue tracking tool
- Communicate with developers to clarify any requirements that are unclear
- Schedule retest
- Get sign off from UAT testers
- Close UAT phase.
For templates for managing your user acceptance testing: download here!
A smoke test (an exploratory end-to-end check of the application, which is sort of the lowest effort user journey) A substantial amount of exploratory testing (the actual things I m doing are approaching the application with a view to consider every component of that application from the perspective of it functionally works on the front-end, and if it makes sense if I was a user). There s a lot more detail to this, and I would be happy to expand on that if it helps you understand what s going on. A vendor acceptance phase, which as you have rightly said, doesn t really add anything to the product, because as the vendor I m invested in making it acceptable, (and vendors can consciously or unconsciously can redefine ambiguity to fit their idea of acceptance. I don t consciously do it, but I accept that I m potentially fallible to cognitive dissonance). At the moment project managers tell us that they don t have the budgets to support our estimate, and ask us what can be dropped to accommodate a much smaller time frame (think 2 days instead of 20 days).