How to Plan Your UAT - User Acceptance Test Plans That Work! | Business Analyst Training

Main ideas & lessons (UAT planning and success)

• Purpose of UAT (User Acceptance Testing): UAT verifies/validates that the software (feature/enhancement) actually solves a real business problem from the end-user perspective, before release to production.

• Why UAT is necessary:

  • QA testing may use dummy data and an artificial environment.
  • UAT tests in an environment similar to production with real/production-like data, ensuring the system works with other data, other systems, and all planned use cases.
  • Prevents releasing something that fails for real users, which can damage reputation and create additional issues.

• UAT is a “final gate”: A thorough final validation that builds confidence that the release is safe.

• What success depends on: The creator emphasizes three key factors: people, process, and priority.

---

Methodology / process for running and planning UAT (detailed steps)

1) Define why you’re doing UAT

• Confirm that the solution matches what stakeholders approved at the start and what was built from requirements/user stories.
• Ensure the product works as a whole, not just sprint-by-sprint demos.
• Validate that it works in a production-like operational environment where real-world factors and integrations exist.

2) Build the right UAT team (who participates)

• Primary responsibility:

  • A Business Analyst or product team typically leads/organizes UAT and coordinates with users.

• Testers / participants:

  • End users (ideal customers/customers) when appropriate (often with concerns about confidentiality).
  • Proxy users when end customers can’t participate—people who understand customer journey/expectations well, e.g.:
    • Customer support / customer service
    • Trainers
    • Designers (speaker suggests they may be “too close” and focus on trivial UI differences)
  • Product team roles:
    • Product Owner and potentially Product Manager can participate (but the BA leads).
  • QA team:
    • Helps manage and track bugs found during UAT (UAT may surface issues QA didn’t catch).
  • Developers:
    • Needed to fix bugs found during UAT.

• Avoid / be cautious with:

  • People overly technical can miss the “real customer reality” perspective or approach testing differently.
  • The speaker warns against turning UAT into a technical QA exercise.

3) Plan and set priorities (the “priority” part)

• Use input from a Product Owner / Product Manager / Project Manager to decide:
  • Which defects/bugs are highest priority
  • Which issues must be fixed before production release
  • Which can be deferred and handled after release
• Establish a process so priority is clear and someone owns it.
• Guidance:
  • If it’s a missing critical feature, treat it as urgent.
  • Otherwise, avoid overloading the release with low-value issues.

4) Ensure knowledge of existing functionality + improvements

• Understand how the system works today, including:
  • Interactions with other components/data
  • How to write meaningful test cases
• Understand the new changes/enhancements in detail.
• Explicitly consider edge cases, not just the happy path:
  • How the system should behave and recover when things go wrong
  • Preventing duplicates and handling unusual scenarios

5) Use both ad-hoc and guided testing (balanced approach)

• The speaker argues for a managed UAT rather than purely ad hoc:
  • Ad hoc helps detect common mistakes anyone might make without instructions.
  • Ad hoc alone leads to missed scenarios (users don’t naturally follow the same “script” testers would).
• Recommended approach:
  • Start with ad hoc exploration first (enthusiasm, discovery).
  • Then introduce exact steps / test cases to deliberately cover edge cases.
  • Keep steps non-boring using high-level test cases that still cover required scenarios.

6) Set up a production-like environment (critical)

• Environment is essential: if it’s wrong, testing results are unreliable.
• Avoid running UAT like a pure QA environment; it may not reflect real user data behavior.
• Aim for:
  • Production-like configuration
  • Production-like permissions and roles
  • Production-like data (copy working data or create realistic datasets and load them)
• Environment examples:
  • Correct login access
  • Correct roles/permissions so users can test different views

7) Ensure QA is completed before UAT begins

• QA must be finished (unit testing, smoke testing, regression, etc.).
• Do not try to use UAT testers as additional QA.
• Merging QA and UAT causes headaches, schedule risk, and role confusion.

8) Prepare logistics and support testing

• Send invitations in advance; reserve dedicated time for testers.
• Make the BA/lead available during testing to answer questions and avoid duplicate errors.
• Testing focus:
  • Testers should be dedicated to UAT during test sessions (no multitasking).
  • Virtual sessions may help (screenshots, ongoing access to the meeting), but focus is still important.

9) Write UAT test cases effectively

• Prefer high-level steps (not click-by-click) to match how real users work.
• Include test-case structure elements:
  • Prerequisites (which environment, what must be configured)
  • Purpose (what the test checks: empty state, edge case, etc.)
  • Logical step groups (split long tests)
  • Target guideline: max ~10 steps per section
  • Expected outcomes (optional in some cases, but can verify correctness)
• Test yourself first:
  • Run through test cases to confirm they reveal the intended issues and don’t waste testers’ time.

10) Implement bug/problem logging (avoid chaos and duplicates)

• Preferred approach:

  • Testers record issues in a shared structured problem log (e.g., an Excel sheet template).
  • The BA or QA team then creates the official Jira issues to prevent duplicates and inconsistent bug-writing style.

• Problem log should include:

  • Test area/module (e.g., empty state, app, credit score)
  • Description with reproduction details (e.g., account number, identifying info)
  • Screenshots
  • URL or identifiers if applicable (web app URL, account ID, username)
  • Environment where it occurred (sandbox/preview/QA—not production)
  • Who reported / which tester observed it
  • Status (open/fixed/deferred/etc.)
  • Error type/category (e.g., missing requirement, design gap, development gap)
  • Jira issue number if already created
  • Priority (what should be fixed before release vs after)

• Emphasis:

  • Create Jira bugs only for items you believe should matter before or right after release; otherwise Jira becomes unmanageable.

11) Retest and obtain sign-off

• Report bugs early to QA/development.
• Retest once fixed to build confidence.
• Conclude UAT when:
  • Participants sign off that the feature works well in the production-like environment
  • The broader project team is informed that UAT is complete

12) Final checklist for a successful UAT (condensed)

• Schedule the right people (team availability and roles)
• Avoid duplicate bug creation (use one designated bug-creation owner/workflow)
• Grant users special privileges/appropriate permissions
• Meet regularly to prioritize bugs (daily prioritization mentioned)
• Create high-priority bugs only (to prevent overload)
• Set up production-like environment + correct data
• Write high-level test cases

---

Tools / templates mentioned

• The creator offers downloadable templates on their website:
  • UAT test case template
  • UAT bug tracking list template
• Website reference: caroliss.com → templates

---

Speakers / sources featured

• Primary speaker: The YouTube presenter/instructor (name not stated in the subtitles), teaching “Business Analyst Training” content on UAT planning.
• Sources: No external sources or additional speakers are cited in the subtitles.