UAT for RPA Bots
User Acceptance Testing (UAT) is the final testing phase before a bot goes live in production. Business users — the people who currently perform the process manually — test the bot against real scenarios to confirm it works exactly as expected. UAT is not a technical test. It is a business validation: does the bot do what the business needs it to do?
UAT bridges the gap between what the developer built and what the business actually needs. Even a technically correct bot can fail UAT if it does not match the way the business expects the process to run.
Who Participates in UAT?
| Role | Responsibility in UAT |
|---|---|
| Business SME (Subject Matter Expert) | Executes test cases based on real scenarios; validates outputs match expectations |
| Process Owner / Manager | Final approval authority; signs off on UAT completion |
| RPA Developer | Available to fix defects discovered during UAT; explains bot behaviour |
| Business Analyst | Facilitates UAT, compares outputs against PDD requirements |
| IT / Infrastructure Team | Ensures UAT environment is stable and mirrors production |
UAT vs Development Testing
| Aspect | Development Testing | UAT |
|---|---|---|
| Who runs it? | RPA developer and QA team | Business users |
| What is tested? | Technical correctness | Business correctness |
| Data used | Synthetic test data | Real or near-real business data |
| Environment | Dev/QA environment | UAT environment (mirrors production) |
| Focus | Does the bot run without errors? | Does the bot produce the right business outcome? |
The UAT Process
STEP 1: UAT PLANNING ───────────────────────────────────────────────────── Define scope: Which scenarios will be tested? Prepare UAT test cases based on PDD business rules Set up UAT environment (copy of production systems) Prepare realistic test data (real data, masked if needed) Schedule UAT sessions with business users STEP 2: UAT EXECUTION ───────────────────────────────────────────────────── Business users run each test case Bot executes in the UAT environment Users compare bot outputs to expected results Users document: PASS / FAIL / OBSERVATION for each case STEP 3: DEFECT REPORTING ───────────────────────────────────────────────────── Business users log any discrepancy between expected and actual bot behaviour Developer investigates and fixes Fixed cases are re-tested (re-test cycle) STEP 4: UAT SIGN-OFF ───────────────────────────────────────────────────── All critical test cases pass Business owner formally signs the UAT acceptance document Project moves to production deployment
Writing UAT Test Cases
UAT test cases are written in plain business language — not technical specifications. Each test case describes one scenario the business user will verify.
UAT Test Case Template
| Field | Example |
|---|---|
| Test Case ID | UAT-INV-001 |
| Test Description | Process a standard invoice from an approved vendor under $5,000 |
| Pre-conditions | Invoice email is in the inbox; vendor "Acme Ltd" is on the approved list; SAP is available |
| Test Data | Invoice: INV-TEST-001, Vendor: Acme Ltd, Amount: $1,500, Date: Today |
| Steps to Execute | 1. Start bot manually 2. Observe bot open Outlook 3. Watch bot process invoice 4. Check SAP for posted document 5. Check confirmation email |
| Expected Result | Invoice posted in SAP; document number appears in tracking sheet; confirmation email received by vendor |
| Actual Result | (Filled in during UAT) |
| Status | PASS / FAIL |
| Defect Reference | (If FAIL — link to defect ticket) |
Sample UAT Scenarios for an Invoice Bot
UAT-INV-001: Standard invoice, approved vendor, amount < $5,000 → PASS
UAT-INV-002: Invoice amount > $5,000 → approval email sent → PASS
UAT-INV-003: Vendor not on approved list → exception handling correct → PASS
UAT-INV-004: Duplicate invoice number → not posted, flagged correctly → PASS
UAT-INV-005: Invoice dated 95 days ago → skipped, logged as aged → FAIL ✗
(Bot posted it instead of skipping — developer fixes)
UAT-INV-006: Foreign currency invoice → routed to manual queue → PASS
UAT-INV-007: SAP session timeout mid-process → bot re-logs in, resumes → PASS
UAT-INV-008: Empty inbox — no invoices to process → graceful exit → PASS
UAT-INV-009: 50 invoices processed in sequence — all correct → PASS
UAT-INV-010: Summary email received at end of run with correct counts → PASS
Handling UAT Defects
Not every UAT issue is a defect in the bot. Some issues reveal gaps in the original PDD — steps that were undocumented or business rules that were not communicated during discovery. Classify each UAT finding carefully:
- Bot Defect: The bot behaves differently from what the PDD specified → developer fixes the bot
- PDD Gap: The PDD was missing or incorrect → update the PDD, update the SDD, fix the bot
- Change Request: The business wants something different from what was originally specified → formal change request, scope and timeline impact assessed before fixing
UAT Entry and Exit Criteria
Entry Criteria (Before UAT Can Start)
- All development testing is complete and signed off
- No critical defects outstanding from development testing
- UAT environment is set up and verified to mirror production
- Test data is prepared and loaded
- UAT test cases are reviewed and approved by the business
Exit Criteria (Before UAT Can Close)
- All critical and high-priority test cases have PASS status
- All critical defects have been fixed and re-tested
- Minor defects have been documented and accepted or deferred
- Business process owner has formally signed the UAT acceptance document
UAT Sign-Off Document
The UAT sign-off is a formal document confirming the business accepts the bot for production deployment. It records the test summary — how many cases passed, how many failed, what defects were found and their resolution status. The process owner, project manager, and RPA lead all sign it. This document becomes part of the project's governance record and audit trail.
Summary
UAT is the business validation phase that confirms a bot produces correct business outcomes — not just technically correct outputs. Business SMEs run test cases against realistic data in a UAT environment. Every scenario from the PDD must be covered. Defects are classified as bot issues, PDD gaps, or change requests. UAT closes only when all critical test cases pass and the process owner formally signs off. UAT sign-off is the green light for production deployment — and the clearest protection against deploying a bot that damages real business data.