paulasilvatech ASP Agentic SDLC Personas v1.0.0
EN PT ES
14 quality · Verification

UAT Analyst

Business acceptance tests.

Updated: 2026-04-24 14 sections Download .zip

The UAT Analyst is the persona that represents the business inside the Verification phase. In an AI-native SDLC, the UAT Analyst operates an Acceptance Scribe agent that converts business intent into executable acceptance evidence — not a static sign-off form.

Executive summary

The UAT Analyst closes the loop between the Business Analyst’s requirements and the end user’s reality. Where the QA Engineer proves the system is built right, the UAT Analyst proves it is the right system. In an AI-native SDLC, that proof is assembled with a single Acceptance Scribe agent, four slash prompts, scoped instructions, and a validated MCP catalog that reaches into Azure DevOps Test Plans, GitHub, and Playwright for recorded walkthroughs.

The primary outputs are business-language acceptance scenarios, a formal UAT plan with participants and schedule, sign-off records backed by evidence, and a traceability map linking every business requirement to a reviewed demonstration. The UAT Analyst guards against the oldest failure mode in software: delivering what was asked for on paper and not what the business needs in practice.

The UAT Analyst is also the translator between domain experts and engineering. They run the last rehearsal before production and the first rehearsal after, confirming that production behavior matches what was signed off.

Role and responsibilities

Think of the UAT Analyst like a theatre dramaturg running final dress rehearsal. The director, writer, and actors all have their own view; the dramaturg ensures the audience will understand what is happening and that the piece honors the source material. In an AI-native SDLC, the UAT Analyst is the persona accountable for the audience perspective on every feature before it goes live.

Primary responsibilities:

  • Convert each business requirement into Given-When-Then acceptance scenarios in business language
  • Coordinate UAT sessions with real domain experts, not proxies
  • Record every acceptance walkthrough with the Playwright MCP for evidence
  • Capture sign-offs with digital signatures stored in the repository and referenced from Azure DevOps Test Plans
  • Maintain the business-traceability matrix: requirement → scenario → evidence → sign-off
  • Operate the Acceptance Scribe agent and /acceptance-scenarios, /uat-plan, /sign-off, /business-trace prompts
  • Flag any production behavior that diverges from the signed scenario within 24 hours of release
  • Curate the glossary of business terms so engineering and the business share a single vocabulary

Jobs to be done

  1. As a UAT Analyst, I want every business requirement to have at least one executable acceptance scenario, so that sign-off is backed by evidence, not opinion.
  2. As a UAT Analyst, I want UAT sessions scheduled automatically from the release plan, so that no feature ships without a dated rehearsal.
  3. As a UAT Analyst, I want recorded walkthroughs attached to each sign-off, so that audits and future regressions have an artifact to replay.
  4. As a UAT Analyst, I want divergences between signed scenarios and production behavior detected within one day, so that trust with the business is preserved.
  5. As a UAT Analyst, I want a single, queryable business-traceability matrix, so that leadership can answer “is requirement X verified in production?” in seconds.
  6. As a UAT Analyst, I want every scenario written in the business’s own words, so that domain experts can approve without translation.
  7. As a UAT Analyst, I want sign-offs time-stamped and signed, so that governance and compliance audits are satisfied without manual packaging.
  8. As a UAT Analyst, I want the UAT plan distributed in Microsoft Teams and Loop, so that stakeholders see dates, owners, and outcomes in one place.

Pain points before AI-native

  • Requirements translate badly. Business people speak process language, engineers write code; acceptance scenarios in the middle get watered down.
  • Sign-offs without evidence. A checkbox in a form proves nothing when the incident happens.
  • UAT as afterthought. UAT gets the last two days before release; problems found there either ship or slip the release.
  • Scenario rot. Scenarios written for version 1 are still the only scenarios for version 4.
  • No production feedback loop. The signed scenario is never re-verified in production, so drift goes unnoticed.
  • Manual scheduling. UAT sessions are coordinated by email with five-way schedule collisions.
  • Disconnected tools. Sign-offs in email, scenarios in a doc, evidence on a shared drive; nothing is traceable.

AI-native daily workflow

The UAT Analyst works primarily in Microsoft 365 (Teams, Loop) and Visual Studio Code with GitHub Copilot, invoking the Acceptance Scribe agent to draft and maintain scenarios.

Morning setup

  1. Open the Release Candidate channel in Microsoft Teams; check which features are in the UAT queue.
  2. In VS Code, run /uat-plan --release=next to regenerate the plan with session times, participants, and required evidence slots.
  3. Review overnight drift alerts from Azure Application Insights against previously signed scenarios.
  4. Pull the latest SPECIFICATION.md and confirm new or changed requirements have draft scenarios ready for review.
  5. Sync with the Business Analyst to confirm domain vocabulary added to the glossary.

Midday execution

  1. Facilitate UAT sessions with domain experts. Use Playwright MCP to record every walkthrough.
  2. For each scenario executed, run /sign-off to capture the result, evidence link, and signer identity; the prompt writes a signed record into the repository.
  3. For new requirements, invoke /acceptance-scenarios to draft Given-When-Then blocks in business language, then review with the domain expert before freezing.
  4. Open a PR that adds or updates the scenario files; reviewers include the Business Analyst and the Product Owner.

Afternoon review

  1. Run /business-trace to regenerate the traceability matrix and publish it to Loop for stakeholders.
  2. Check the divergence report: any production telemetry that contradicts a signed scenario becomes an incident ticket in GitHub Projects.
  3. Post a daily digest in Microsoft Teams with sign-off counts, open scenarios, and next-day schedule.

Agent

AgentFilePurpose
acceptance-scribe.github/agents/acceptance-scribe.agent.mdDrafts acceptance scenarios, maintains the UAT plan, records sign-offs, and refreshes the business-traceability matrix

Slash prompts

CommandFilePurpose
/acceptance-scenarios.github/prompts/acceptance-scenarios.prompt.mdConvert a business requirement into Given-When-Then scenarios in business language
/uat-plan.github/prompts/uat-plan.prompt.mdGenerate the UAT schedule, participants, evidence slots for a release
/sign-off.github/prompts/sign-off.prompt.mdCapture a signed, evidence-backed acceptance of a scenario
/business-trace.github/prompts/business-trace.prompt.mdRefresh the business-traceability matrix and export to Azure DevOps Test Plans

Instructions scoped

Scope (applyTo)FilePurpose
docs/scenarios/**/*.feature.github/instructions/scenarios.instructions.mdBusiness-language rules, no technical jargon, one requirement per scenario
docs/uat/**/*.md.github/instructions/uat-plan.instructions.mdUAT plan format with participants, dates, evidence links
docs/signoff/**/*.md.github/instructions/signoff.instructions.mdSign-off format with signer, timestamp, evidence URL

Hooks

  • pre-release: block release if any in-scope requirement lacks a signed scenario
  • post-merge: rebuild the business-traceability matrix and push to Azure DevOps Test Plans
  • nightly: compare production telemetry against signed scenarios and emit divergence issues
  • pre-uat-session: generate the participant email, Teams invite, and evidence checklist
  • post-uat-session: archive the Playwright MCP recording to Azure Blob Storage and link it from the sign-off

Validated MCPs

MCPPurposeOwner
GitHub MCP ServerManage PRs that add scenarios and sign-offs, open divergence issuesGitHub
Azure DevOps MCP ServerSync UAT plan and sign-offs into Azure DevOps Test PlansMicrosoft
Playwright MCPRecord every UAT walkthrough for evidenceMicrosoft
Azure MCP ServerPull Application Insights telemetry for production-drift detectionMicrosoft
Microsoft Learn Docs MCPResolve Microsoft 365 and Azure feature semantics referenced in scenariosMicrosoft

Real examples

Example 1: a new claim-approval flow

The Business Analyst publishes REQ-CLM-210: “Approvers must receive a Teams notification within 30 seconds of a claim entering review.” The UAT Analyst invokes /acceptance-scenarios to draft three Given-When-Then scenarios (happy path, delayed path, user unavailable path). A session is held with two domain experts; the Acceptance Scribe records walkthroughs via Playwright MCP. /sign-off captures the signatures. The business-traceability matrix flips REQ-CLM-210 from draft to accepted-prod.

Example 2: divergence caught in production

Application Insights telemetry shows that notifications take 70 seconds on 2 percent of claims on a Saturday. The nightly divergence hook compares against signed REQ-CLM-210 and opens a GitHub issue within minutes. The UAT Analyst coordinates with the SRE; the root cause is Azure Service Bus throttling. After the fix, a shortened /sign-off re-verifies the scenario, and the matrix returns to accepted-prod.

Example 3: retiring a scenario

A regulator deprecates a KYC step; the Business Analyst marks REQ-KYC-018 as retired. The UAT Analyst invokes /business-trace to cross off the scenario, archives the last sign-off with reason retired, and publishes the change log in Microsoft Loop. Engineering removes the code path with confidence because the traceability matrix shows no remaining downstream scenario.

Anti-patterns

  • Checkbox sign-off. A signature without linked evidence is no better than no sign-off. Always attach the Playwright recording and a scenario ID.
  • Engineering writes scenarios. When engineers author business scenarios, they encode assumptions from the code; have domain experts review or reject every scenario.
  • UAT batched at the end. UAT per-feature beats UAT per-release; delaying collapses the feedback window.
  • Scenario bloat. Scenarios that test ten things at once cannot be signed cleanly. One scenario, one outcome.
  • Unowned glossary. A domain glossary without a named owner rots; the UAT Analyst is the owner.
  • Stale sign-offs. A sign-off from six releases ago proves nothing about today’s code; refresh at major version changes.
  • Hidden scenarios. Scenarios in a private drive or email thread cannot be audited; everything lives in the repo.

KPIs and impact metrics

MetricBaseline (manual)Target (agentic)Source
Requirements with signed scenario70 percent100 percentBusiness-traceability matrix
Sign-off cycle time4 days< 1 dayGitHub PR timestamps
Production-to-scenario divergences unresolved > 24h100Divergence hook
UAT sessions recorded40 percent100 percentPlaywright MCP archive
Business vocabulary drift incidents6 per quarter0Glossary diff
Participant no-show rate25 percent< 5 percentTeams invites
Sign-off audit readinessDaysMinutesAzure DevOps Test Plans export

Maturity in four levels

  • L1 Manual: Scenarios in a shared doc, sign-offs by email, no recordings, no traceability matrix.
  • L2 Assisted: Copilot drafts scenarios but humans manually copy them into a wiki; sign-offs are screenshots.
  • L3 Augmented: Acceptance Scribe agent, four slash prompts, scoped instructions, Playwright MCP recordings linked from sign-offs.
  • L4 Autonomous: Nightly divergence detection, automated scheduling in Microsoft Teams, business-traceability matrix published daily to Loop, pre-release hook blocks unacceptable requirements automatically.

Integration with other personas

  • From Business Analyst: approved requirements with EARS statements and domain glossary updates.
  • From Product Owner: prioritized release plan indicating which requirements need UAT in this cycle.
  • To Developer: divergence issues with linked signed scenarios and Application Insights telemetry.
  • With QA Engineer: shared Playwright fixtures; acceptance scenarios feed regression suite candidates.
  • To Compliance Auditor: the business-traceability matrix and signed artifacts as audit evidence.
  • To Release Manager: pre-release hook blocks on missing sign-offs.
  • With Tech Writer: glossary synchronization so user docs and scenarios share the same vocabulary.

Glossary

  • Acceptance scenario: a Given-When-Then block written in business language, owned by a domain expert.
  • Sign-off: a signed, time-stamped, evidence-linked acceptance of a scenario.
  • Business-traceability matrix: the live mapping from requirement to scenario to evidence to signer.
  • Divergence: production behavior that contradicts a signed scenario, detected by telemetry comparison.
  • Domain glossary: the canonical list of business terms shared between engineering and the business.
  • Evidence: a recorded walkthrough, typically produced via Playwright MCP, referenced from the sign-off.
  • Rehearsal: the final walkthrough before release, run in a staging environment with the full participant roster.

References