User acceptance testing

An executable operator acceptance protocol with prerequisites, expected outcomes, defects, retest and sign-off.

Product decision
Require operators to explain the exception, not merely clear it.

Document type

User acceptance testing

Status

Portfolio sample · written from my healthcare claims experience

Product decision

Require operators to explain the exception, not merely clear it.

Portfolio sample from my healthcare product experience. Requirements, thresholds and review records are illustrative; they are not employer documents or historical sign-offs.

In this document 7 sections

Status and acceptance objective

Status: NOT RUN for this reconstructed sample. UAT determines whether intended users can complete and recover supported claims without bypassing evidence. Functional QA and operator acceptance answer different questions; a service response can be technically correct while its explanation leads an operator to the wrong action.

1. UAT determines whether intended users can complete and recover supported claims without bypassing evidence
2. Functional QA and operator acceptance answer different questions
3. a service response can be technically correct while its explanation leads an operator to the wrong action

Status: NOT RUN for this reconstructed sample

Prerequisites and participants

Use an identified candidate build, sample professional/institutional fixtures, controlled provider records, a receiver simulator and role-specific accounts. Functional blockers must be resolved or explicitly prevent the affected scenario from proceeding. Operations and claims specialists perform task acceptance; provider-data stewards assess identity handling; customer care assesses status explanations. Engineering/QA capture evidence. Security, legal/compliance and relevant patient-safety partners review their boundaries. No real patient information is entered into the portfolio.

1. Use an identified candidate build, sample professional/institutional fixtures, controlled provider records a receiver simulator and role-specific accounts
2. Operations and claims specialists perform task acceptance provider-data stewards assess identity handling; customer care assesses status explanations
3. Engineering/QA capture evidence
4. Security, legal/compliance and relevant patient-safety partners review their boundaries

No real patient information is entered into the portfolio

Acceptance scenarios

Record actual behavior beside the expected result; do not replace it with a checkbox alone.

ID / Given	When / participant action	Expected result	Actual / status
U1 valid CMS-1500 or UB-04	Operator follows the claim through handoff	Correct 837 variant; acknowledgement distinct from final disposition	NOT RUN
U2 uncertain required field	Authorized operator compares source and corrects	Correction lineage retained; revalidation before advance	NOT RUN
U3 missing or ambiguous provider	Operator interprets response and assigns review	No arbitrary selection; reason and accountable queue visible	NOT RUN
U4 stale/unavailable provider source	Operator examines status and next action	Does not treat old evidence as current; controlled hold/retry	NOT RUN
U5 invalid EDI or delayed acknowledgement	Claims specialist explains current state	Correct error action; no unsupported completion promise	NOT RUN
U6 retry and replay discrepancy	Operator/engineer recover a bounded fixture	Stable identity; discrepancy visible; no live replay duplication	NOT RUN
U7 restricted user	Customer-care role attempts an unauthorized change	Action denied; appropriate status remains available	NOT RUN
U8 mixed inventory	Operations reviews queue and report	Unique records reconcile; pending/held work remains visible	NOT RUN

Execution record and defect treatment

For each task retain build, fixture version, participant role, action sequence, observation, actual result and evidence reference. Record misunderstanding as a usability finding even if no system exception occurs. Link a failed task to the corresponding requirement and defect. Severity describes consequence; priority describes repair order. Unsupported identity, duplicate submission, missing inventory or unauthorized exposure blocks the affected acceptance path. Product does not lower severity merely because the happy path works.

1. For each task retain build, fixture version, participant role action sequence, observation, actual result and evidence reference
2. Record misunderstanding as a usability finding even if no system exception occurs
3. Link a failed task to the corresponding requirement and defect
4. Severity describes consequence; priority describes repair order

Unsupported identity, duplicate submission, missing inventory or unauthorized exposure blocks the affected acceptance path

Retest and acceptance meeting

After correction, the original participant or an equivalent role repeats the failed scenario on the new build. QA repeats adjacent regression cases, such as normalized address plus ambiguity or timeout plus known acknowledgement. Reopen the defect if either fails. The acceptance meeting reviews unresolved findings, residual work and support capacity rather than averaging tasks into a misleading overall percentage. Performance evidence is reviewed separately against p95 ≤500 ms at 50 requests/second; operator UAT does not substitute for a load test.

1. repeats the failed scenario on the new build the original participant or an equivalent role
2. QA repeats adjacent regression cases normalized address plus ambiguity or timeout plus known acknowledgement
3. Reopen the defect if either fails
4. reviews unresolved findings, residual work and support capacity rather than averaging tasks into a misleading overall percentage

Sign-off and release gate

No approvals are recorded here.

Accountable role	Acceptance responsibility	Current status
Operations / customer care	Recovery usability, staffing, training and status language	NOT RUN / not signed
Claims / provider specialist	Domain interpretation and identity exceptions	NOT RUN / not signed
Engineering / QA	Reproducibility, regression and recovery evidence	Not supplied for this sample
Security / legal / compliance	Applicable controls and obligations	Not signed
Product release owner	Scope and residual-risk decision	NO RELEASE APPROVAL

Exit condition

Release requires completed actual evidence, resolved blocking findings, reconciled inventory and accountable support. A conditional acceptance must identify the affected scope, mitigation, owner, expiry and retest obligation. Historical automation outcomes do not replace this reconstructed release evidence.

1. completed actual evidence
2. resolved blocking findings
3. reconciled inventory
4. accountable support

A conditional acceptance must identify the affected scope, mitigation, owner, expiry and retest obligation