UAT AnalystAnalista de UATAnalista UAT
Business acceptance tests.Testes de aceitação de negócio.Pruebas de aceptación de negocio.
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-traceprompts - 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
- 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.
- As a UAT Analyst, I want UAT sessions scheduled automatically from the release plan, so that no feature ships without a dated rehearsal.
- As a UAT Analyst, I want recorded walkthroughs attached to each sign-off, so that audits and future regressions have an artifact to replay.
- 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.
- 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.
- As a UAT Analyst, I want every scenario written in the business’s own words, so that domain experts can approve without translation.
- As a UAT Analyst, I want sign-offs time-stamped and signed, so that governance and compliance audits are satisfied without manual packaging.
- 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
- Open the Release Candidate channel in Microsoft Teams; check which features are in the UAT queue.
- In VS Code, run
/uat-plan --release=nextto regenerate the plan with session times, participants, and required evidence slots. - Review overnight drift alerts from Azure Application Insights against previously signed scenarios.
- Pull the latest
SPECIFICATION.mdand confirm new or changed requirements have draft scenarios ready for review. - Sync with the Business Analyst to confirm domain vocabulary added to the glossary.
Midday execution
- Facilitate UAT sessions with domain experts. Use Playwright MCP to record every walkthrough.
- For each scenario executed, run
/sign-offto capture the result, evidence link, and signer identity; the prompt writes a signed record into the repository. - For new requirements, invoke
/acceptance-scenariosto draft Given-When-Then blocks in business language, then review with the domain expert before freezing. - Open a PR that adds or updates the scenario files; reviewers include the Business Analyst and the Product Owner.
Afternoon review
- Run
/business-traceto regenerate the traceability matrix and publish it to Loop for stakeholders. - Check the divergence report: any production telemetry that contradicts a signed scenario becomes an incident ticket in GitHub Projects.
- Post a daily digest in Microsoft Teams with sign-off counts, open scenarios, and next-day schedule.
Recommended primitives
Agent
| Agent | File | Purpose |
|---|---|---|
acceptance-scribe | .github/agents/acceptance-scribe.agent.md | Drafts acceptance scenarios, maintains the UAT plan, records sign-offs, and refreshes the business-traceability matrix |
Slash prompts
| Command | File | Purpose |
|---|---|---|
/acceptance-scenarios | .github/prompts/acceptance-scenarios.prompt.md | Convert a business requirement into Given-When-Then scenarios in business language |
/uat-plan | .github/prompts/uat-plan.prompt.md | Generate the UAT schedule, participants, evidence slots for a release |
/sign-off | .github/prompts/sign-off.prompt.md | Capture a signed, evidence-backed acceptance of a scenario |
/business-trace | .github/prompts/business-trace.prompt.md | Refresh the business-traceability matrix and export to Azure DevOps Test Plans |
Instructions scoped
Scope (applyTo) | File | Purpose |
|---|---|---|
docs/scenarios/**/*.feature | .github/instructions/scenarios.instructions.md | Business-language rules, no technical jargon, one requirement per scenario |
docs/uat/**/*.md | .github/instructions/uat-plan.instructions.md | UAT plan format with participants, dates, evidence links |
docs/signoff/**/*.md | .github/instructions/signoff.instructions.md | Sign-off format with signer, timestamp, evidence URL |
Hooks
pre-release: block release if any in-scope requirement lacks a signed scenariopost-merge: rebuild the business-traceability matrix and push to Azure DevOps Test Plansnightly: compare production telemetry against signed scenarios and emit divergence issuespre-uat-session: generate the participant email, Teams invite, and evidence checklistpost-uat-session: archive the Playwright MCP recording to Azure Blob Storage and link it from the sign-off
Validated MCPs
| MCP | Purpose | Owner |
|---|---|---|
| GitHub MCP Server | Manage PRs that add scenarios and sign-offs, open divergence issues | GitHub |
| Azure DevOps MCP Server | Sync UAT plan and sign-offs into Azure DevOps Test Plans | Microsoft |
| Playwright MCP | Record every UAT walkthrough for evidence | Microsoft |
| Azure MCP Server | Pull Application Insights telemetry for production-drift detection | Microsoft |
| Microsoft Learn Docs MCP | Resolve Microsoft 365 and Azure feature semantics referenced in scenarios | Microsoft |
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
| Metric | Baseline (manual) | Target (agentic) | Source |
|---|---|---|---|
| Requirements with signed scenario | 70 percent | 100 percent | Business-traceability matrix |
| Sign-off cycle time | 4 days | < 1 day | GitHub PR timestamps |
| Production-to-scenario divergences unresolved > 24h | 10 | 0 | Divergence hook |
| UAT sessions recorded | 40 percent | 100 percent | Playwright MCP archive |
| Business vocabulary drift incidents | 6 per quarter | 0 | Glossary diff |
| Participant no-show rate | 25 percent | < 5 percent | Teams invites |
| Sign-off audit readiness | Days | Minutes | Azure 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
- Azure DevOps Test Plans — official destination for UAT evidence and plans
- Microsoft Teams and Loop for collaboration — stakeholder communication channels
- Playwright MCP — recording and driving acceptance walkthroughs
- GitHub Projects — divergence ticket tracking
- Application Insights for live monitoring — production divergence signal
- Microsoft Purview information protection — audit readiness for sign-off evidence
- GitHub Actions — CI and deployment orchestration across the stack
- Microsoft Learn Docs MCP — first-party documentation retrieval at implementation time
- GitHub Advanced Security — CodeQL, Dependabot, Secret Scanning, Push Protection
O Analista de UAT é a persona que representa o negócio dentro da fase de Verificação. Em um SDLC AI-nativo, o Analista de UAT opera um agente Acceptance Scribe que converte a intenção de negócio em evidências de aceitação executáveis — não um formulário estático de sign-off.
Resumo executivo
O Analista de UAT fecha o loop entre os requisitos do Business Analyst e a realidade do usuário final. Enquanto o Engenheiro de QA prova que o sistema foi construído corretamente, o Analista de UAT prova que é o sistema correto. Em um SDLC AI-nativo, essa prova é montada com um único agente Acceptance Scribe, quatro slash prompts, instruções com escopo e um catálogo validado de MCPs que alcança Azure DevOps Test Plans, GitHub e Playwright para walkthroughs gravados.
As saídas primárias são cenários de aceitação em linguagem de negócio, um plano formal de UAT com participantes e cronograma, registros de sign-off respaldados por evidências e um mapa de rastreabilidade linkando cada requisito de negócio a uma demonstração revisada. O Analista de UAT protege contra o modo de falha mais antigo do software: entregar o que foi pedido no papel e não o que o negócio precisa na prática.
O Analista de UAT também é o tradutor entre especialistas de domínio e engenharia. Ele conduz o último ensaio antes da produção e o primeiro ensaio depois, confirmando que o comportamento em produção corresponde ao que foi assinado.
Papel e responsabilidades
Pense no Analista de UAT como um dramaturgista de teatro conduzindo o ensaio geral final. O diretor, o roteirista e os atores têm cada um sua visão; o dramaturgista garante que a plateia vai entender o que está acontecendo e que a peça honra o material original. Em um SDLC AI-nativo, o Analista de UAT é a persona responsável pela perspectiva da audiência em cada feature antes de ir ao ar.
Responsabilidades primárias:
- Converter cada requisito de negócio em cenários de aceitação Given-When-Then em linguagem de negócio
- Coordenar sessões de UAT com especialistas de domínio reais, não proxies
- Gravar cada walkthrough de aceitação com o Playwright MCP para evidência
- Capturar sign-offs com assinaturas digitais armazenadas no repositório e referenciadas no Azure DevOps Test Plans
- Manter a matriz de rastreabilidade de negócio: requisito → cenário → evidência → sign-off
- Operar o agente Acceptance Scribe e os prompts
/acceptance-scenarios,/uat-plan,/sign-off,/business-trace - Sinalizar qualquer comportamento de produção que diverge do cenário assinado em até 24 horas após o release
- Curar o glossário de termos de negócio para que engenharia e negócio compartilhem um vocabulário único
Jobs to be done
- Como Analista de UAT, eu quero que cada requisito de negócio tenha pelo menos um cenário de aceitação executável, para que o sign-off seja respaldado por evidência, não opinião.
- Como Analista de UAT, eu quero sessões de UAT agendadas automaticamente a partir do plano de release, para que nenhuma feature seja entregue sem um ensaio datado.
- Como Analista de UAT, eu quero walkthroughs gravados anexados a cada sign-off, para que auditorias e regressões futuras tenham um artefato para reproduzir.
- Como Analista de UAT, eu quero divergências entre cenários assinados e comportamento de produção detectadas em um dia, para que a confiança com o negócio seja preservada.
- Como Analista de UAT, eu quero uma matriz de rastreabilidade de negócio única e consultável, para que a liderança consiga responder “o requisito X está verificado em produção?” em segundos.
- Como Analista de UAT, eu quero cada cenário escrito nas próprias palavras do negócio, para que especialistas de domínio possam aprovar sem tradução.
- Como Analista de UAT, eu quero sign-offs com timestamp e assinatura, para que auditorias de governança e compliance sejam satisfeitas sem empacotamento manual.
- Como Analista de UAT, eu quero o plano de UAT distribuído no Microsoft Teams e Loop, para que stakeholders vejam datas, donos e resultados em um só lugar.
Dores antes do AI-nativo
- Requisitos se traduzem mal. Pessoas de negócio falam linguagem de processo, engenheiros escrevem código; cenários de aceitação no meio ficam diluídos.
- Sign-offs sem evidência. Uma checkbox em um formulário não prova nada quando o incidente acontece.
- UAT como última hora. UAT recebe os dois últimos dias antes do release; problemas encontrados ali ou são entregues ou atrasam o release.
- Deterioração de cenários. Cenários escritos para a versão 1 continuam sendo os únicos cenários na versão 4.
- Sem loop de feedback de produção. O cenário assinado nunca é reverificado em produção, então a deriva passa despercebida.
- Agendamento manual. Sessões de UAT são coordenadas por email com cinco colisões de agenda.
- Ferramentas desconectadas. Sign-offs em email, cenários em um doc, evidência em um drive compartilhado; nada é rastreável.
Fluxo diário AI-nativo
O Analista de UAT trabalha principalmente no Microsoft 365 (Teams, Loop) e no Visual Studio Code com GitHub Copilot, invocando o agente Acceptance Scribe para redigir e manter cenários.
Setup da manhã
- Abra o canal de Release Candidate no Microsoft Teams; verifique quais features estão na fila de UAT.
- No VS Code, rode
/uat-plan --release=nextpara regenerar o plano com horários de sessão, participantes e slots de evidência necessários. - Revise alertas noturnos de drift do Azure Application Insights contra cenários previamente assinados.
- Puxe o último
SPECIFICATION.mde confirme que requisitos novos ou alterados têm cenários rascunhados prontos para revisão. - Sincronize com o Business Analyst para confirmar vocabulário de domínio adicionado ao glossário.
Execução no meio do dia
- Facilite sessões de UAT com especialistas de domínio. Use o Playwright MCP para gravar cada walkthrough.
- Para cada cenário executado, rode
/sign-offpara capturar o resultado, o link de evidência e a identidade do assinante; o prompt grava um registro assinado no repositório. - Para novos requisitos, invoque
/acceptance-scenariospara redigir blocos Given-When-Then em linguagem de negócio, depois revise com o especialista de domínio antes de congelar. - Abra um PR que adiciona ou atualiza os arquivos de cenário; revisores incluem o Business Analyst e o Product Owner.
Revisão no fim da tarde
- Rode
/business-tracepara regenerar a matriz de rastreabilidade e publicá-la no Loop para stakeholders. - Verifique o relatório de divergência: qualquer telemetria de produção que contradiz um cenário assinado se torna um ticket de incidente no GitHub Projects.
- Poste um resumo diário no Microsoft Teams com contagens de sign-off, cenários abertos e cronograma do dia seguinte.
Primitivas recomendadas
Agente
| Agente | Arquivo | Propósito |
|---|---|---|
acceptance-scribe | .github/agents/acceptance-scribe.agent.md | Redige cenários de aceitação, mantém o plano de UAT, registra sign-offs e atualiza a matriz de rastreabilidade de negócio |
Slash prompts
| Comando | Arquivo | Propósito |
|---|---|---|
/acceptance-scenarios | .github/prompts/acceptance-scenarios.prompt.md | Converter um requisito de negócio em cenários Given-When-Then em linguagem de negócio |
/uat-plan | .github/prompts/uat-plan.prompt.md | Gerar o cronograma de UAT, participantes, slots de evidência para um release |
/sign-off | .github/prompts/sign-off.prompt.md | Capturar uma aceitação assinada e respaldada por evidência de um cenário |
/business-trace | .github/prompts/business-trace.prompt.md | Atualizar a matriz de rastreabilidade de negócio e exportar para o Azure DevOps Test Plans |
Instruções com escopo
Escopo (applyTo) | Arquivo | Propósito |
|---|---|---|
docs/scenarios/**/*.feature | .github/instructions/scenarios.instructions.md | Regras de linguagem de negócio, sem jargão técnico, um requisito por cenário |
docs/uat/**/*.md | .github/instructions/uat-plan.instructions.md | Formato do plano de UAT com participantes, datas, links de evidência |
docs/signoff/**/*.md | .github/instructions/signoff.instructions.md | Formato de sign-off com assinante, timestamp, URL de evidência |
Hooks
pre-release: bloquear release se qualquer requisito no escopo não tiver um cenário assinadopost-merge: reconstruir a matriz de rastreabilidade de negócio e enviá-la ao Azure DevOps Test Plansnightly: comparar telemetria de produção contra cenários assinados e emitir issues de divergênciapre-uat-session: gerar o email de participantes, convite do Teams e checklist de evidênciapost-uat-session: arquivar a gravação do Playwright MCP no Azure Blob Storage e linká-la do sign-off
MCPs validados
| MCP | Propósito | Dono |
|---|---|---|
| GitHub MCP Server | Gerenciar PRs que adicionam cenários e sign-offs, abrir issues de divergência | GitHub |
| Azure DevOps MCP Server | Sincronizar plano e sign-offs de UAT no Azure DevOps Test Plans | Microsoft |
| Playwright MCP | Gravar cada walkthrough de UAT como evidência | Microsoft |
| Azure MCP Server | Puxar telemetria do Application Insights para detecção de drift em produção | Microsoft |
| Microsoft Learn Docs MCP | Resolver semântica de features do Microsoft 365 e Azure referenciadas em cenários | Microsoft |
Exemplos reais
Exemplo 1: um novo fluxo de aprovação de sinistro
O Business Analyst publica REQ-CLM-210: “Aprovadores devem receber uma notificação do Teams dentro de 30 segundos após um sinistro entrar em revisão.” O Analista de UAT invoca /acceptance-scenarios para redigir três cenários Given-When-Then (caminho feliz, caminho com atraso, usuário indisponível). Uma sessão é realizada com dois especialistas de domínio; o Acceptance Scribe grava walkthroughs via Playwright MCP. /sign-off captura as assinaturas. A matriz de rastreabilidade de negócio altera REQ-CLM-210 de draft para accepted-prod.
Exemplo 2: divergência detectada em produção
Telemetria do Application Insights mostra que notificações levam 70 segundos em 2 por cento dos sinistros em um sábado. O hook de divergência noturno compara contra o REQ-CLM-210 assinado e abre uma issue no GitHub em minutos. O Analista de UAT coordena com o SRE; a causa-raiz é throttling do Azure Service Bus. Após a correção, um /sign-off abreviado reverifica o cenário, e a matriz retorna a accepted-prod.
Exemplo 3: aposentando um cenário
Um regulador deprecia uma etapa de KYC; o Business Analyst marca REQ-KYC-018 como aposentado. O Analista de UAT invoca /business-trace para riscar o cenário, arquiva o último sign-off com razão retired e publica o log de mudanças no Microsoft Loop. A engenharia remove o caminho de código com confiança porque a matriz de rastreabilidade mostra que nenhum cenário downstream permanece.
Anti-padrões
- Sign-off por checkbox. Uma assinatura sem evidência linkada não é melhor do que nenhum sign-off. Sempre anexe a gravação do Playwright e um ID de cenário.
- Engenharia escreve cenários. Quando engenheiros escrevem cenários de negócio, eles codificam suposições do código; faça especialistas de domínio revisarem ou rejeitarem cada cenário.
- UAT em lote no final. UAT por feature é melhor que UAT por release; atrasar colapsa a janela de feedback.
- Inchaço de cenários. Cenários que testam dez coisas ao mesmo tempo não podem ser assinados com clareza. Um cenário, um resultado.
- Glossário sem dono. Um glossário de domínio sem um dono nomeado apodrece; o Analista de UAT é o dono.
- Sign-offs obsoletos. Um sign-off de seis releases atrás não prova nada sobre o código de hoje; atualize em mudanças de versão major.
- Cenários escondidos. Cenários em um drive privado ou thread de email não podem ser auditados; tudo vive no repositório.
KPIs e métricas de impacto
| Métrica | Linha base (manual) | Meta (agêntico) | Fonte |
|---|---|---|---|
| Requisitos com cenário assinado | 70 por cento | 100 por cento | Matriz de rastreabilidade de negócio |
| Tempo de ciclo de sign-off | 4 dias | < 1 dia | Timestamps de PR no GitHub |
| Divergências produção-cenário não resolvidas > 24h | 10 | 0 | Hook de divergência |
| Sessões de UAT gravadas | 40 por cento | 100 por cento | Arquivo do Playwright MCP |
| Incidentes de drift de vocabulário de negócio | 6 por trimestre | 0 | Diff do glossário |
| Taxa de no-show de participantes | 25 por cento | < 5 por cento | Convites do Teams |
| Prontidão para auditoria do sign-off | Dias | Minutos | Exportação do Azure DevOps Test Plans |
Maturidade em quatro níveis
- L1 Manual: Cenários em um doc compartilhado, sign-offs por email, sem gravações, sem matriz de rastreabilidade.
- L2 Assistido: Copilot redige cenários mas humanos copiam manualmente para uma wiki; sign-offs são screenshots.
- L3 Aumentado: Agente Acceptance Scribe, quatro slash prompts, instruções com escopo, gravações do Playwright MCP linkadas dos sign-offs.
- L4 Autônomo: Detecção de divergência noturna, agendamento automatizado no Microsoft Teams, matriz de rastreabilidade de negócio publicada diariamente no Loop, hook pre-release bloqueia requisitos não aceitos automaticamente.
Integração com outras personas
- Do Business Analyst: requisitos aprovados com declarações EARS e atualizações do glossário de domínio.
- Do Product Owner: plano de release priorizado indicando quais requisitos precisam de UAT neste ciclo.
- Para o Developer: issues de divergência com cenários assinados linkados e telemetria do Application Insights.
- Com o QA Engineer: fixtures Playwright compartilhados; cenários de aceitação alimentam candidatos a suíte de regressão.
- Para o Compliance Auditor: a matriz de rastreabilidade de negócio e artefatos assinados como evidência de auditoria.
- Para o Release Manager: hook pre-release bloqueia em sign-offs ausentes.
- Com o Tech Writer: sincronização de glossário para que docs de usuário e cenários compartilhem o mesmo vocabulário.
Glossário
- Cenário de aceitação: um bloco Given-When-Then escrito em linguagem de negócio, de propriedade de um especialista de domínio.
- Sign-off: uma aceitação assinada, com timestamp e evidência linkada, de um cenário.
- Matriz de rastreabilidade de negócio: o mapeamento vivo de requisito a cenário a evidência a assinante.
- Divergência: comportamento de produção que contradiz um cenário assinado, detectado por comparação de telemetria.
- Glossário de domínio: a lista canônica de termos de negócio compartilhada entre engenharia e negócio.
- Evidência: um walkthrough gravado, tipicamente produzido via Playwright MCP, referenciado do sign-off.
- Ensaio: o walkthrough final antes do release, executado em um ambiente de staging com o roster completo de participantes.
Referências
- Azure DevOps Test Plans — destino oficial para evidências e planos de UAT
- Microsoft Teams e Loop para colaboração — canais de comunicação com stakeholders
- Playwright MCP — gravação e condução de walkthroughs de aceitação
- GitHub Projects — rastreamento de tickets de divergência
- Application Insights para monitoramento em produção — sinal de divergência em produção
- Microsoft Purview para proteção de informação — prontidão para auditoria de evidências de sign-off
- GitHub Actions — orquestração de CI e deploy em todo o stack
- Microsoft Learn Docs MCP — recuperação de documentação first-party no momento da implementação
- GitHub Advanced Security — CodeQL, Dependabot, Secret Scanning, Push Protection
El UAT Analyst es la persona que representa el negocio dentro de la fase de Verification. En un SDLC AI-nativo, el UAT Analyst opera un agente Acceptance Scribe que convierte la intención del negocio en evidencia de aceptación ejecutable — no un formulario estático de sign-off.
Resumen ejecutivo
El UAT Analyst cierra el loop entre los requisitos del Business Analyst y la realidad del usuario final. Donde el QA Engineer prueba que el sistema está construido correctamente, el UAT Analyst prueba que es el sistema correcto. En un SDLC AI-nativo, esa prueba se ensambla con un único agente Acceptance Scribe, cuatro slash prompts, instrucciones con alcance, y un catálogo de MCPs validados que alcanza Azure DevOps Test Plans, GitHub y Playwright para walkthroughs grabadas.
Las salidas primarias son escenarios de aceptación en lenguaje de negocio, un plan formal de UAT con participantes y cronograma, registros de sign-off respaldados por evidencia, y un mapa de trazabilidad que enlaza cada requisito de negocio a una demostración revisada. El UAT Analyst se protege contra el modo de falla más antiguo del software: entregar lo que se pidió sobre papel y no lo que el negocio necesita en la práctica.
El UAT Analyst es también el traductor entre los expertos de dominio e ingeniería. Dirige el último ensayo antes de producción y el primero después, confirmando que el comportamiento de producción coincide con lo que fue autorizado.
Rol y responsabilidades
Piensa en el UAT Analyst como un dramaturgo teatral dirigiendo el ensayo general final. El director, el escritor y los actores tienen su propia perspectiva; el dramaturgo asegura que la audiencia comprenda lo que está sucediendo y que la obra honre el material fuente. En un SDLC AI-nativo, el UAT Analyst es la persona responsable de la perspectiva de la audiencia en cada feature antes de que entre en producción.
Responsabilidades principales:
- Convertir cada requisito de negocio en escenarios de aceptación Given-When-Then en lenguaje de negocio
- Coordinar sesiones de UAT con expertos de dominio reales, no proxies
- Grabar cada walkthrough de aceptación con el MCP Playwright para evidencia
- Capturar sign-offs con firmas digitales almacenadas en el repositorio y referenciadas desde Azure DevOps Test Plans
- Mantener la matriz de trazabilidad de negocio: requisito → escenario → evidencia → sign-off
- Operar el agente Acceptance Scribe y los prompts
/acceptance-scenarios,/uat-plan,/sign-off,/business-trace - Marcar cualquier comportamiento de producción que diverja del escenario autorizado dentro de 24 horas de la entrega
- Curar el glosario de términos de negocio para que ingeniería y el negocio compartan un único vocabulario
Jobs to be done
- Como UAT Analyst, quiero que cada requisito de negocio tenga al menos un escenario de aceptación ejecutable, para que el sign-off esté respaldado por evidencia, no por opinión.
- Como UAT Analyst, quiero que las sesiones de UAT se programen automáticamente desde el plan de entrega, para que ninguna feature entre en producción sin un ensayo fechado.
- Como UAT Analyst, quiero que los walkthroughs grabados estén adjuntos a cada sign-off, para que auditorías y futuras regresiones tengan un artefacto para reproducir.
- Como UAT Analyst, quiero que las divergencias entre escenarios autorizados y comportamiento de producción se detecten dentro de un día, para que la confianza con el negocio se preserve.
- Como UAT Analyst, quiero una única matriz de trazabilidad de negocio consultable, para que el liderazgo pueda responder “¿está verificado el requisito X en producción?” en segundos.
- Como UAT Analyst, quiero que cada escenario esté escrito en las propias palabras del negocio, para que los expertos de dominio puedan aprobar sin traducción.
- Como UAT Analyst, quiero que los sign-offs tengan marca de tiempo y estén firmados, para que las auditorías de gobernanza y cumplimiento estén satisfechas sin empaquetamiento manual.
- Como UAT Analyst, quiero que el plan de UAT se distribuya en Microsoft Teams y Loop, para que los stakeholders vean fechas, propietarios y resultados en un único lugar.
Dolores antes de la era AI-nativo
- Requisitos se traducen mal. Las personas del negocio hablan lenguaje de procesos, los ingenieros escriben código; los escenarios de aceptación en el medio se diluyen.
- Sign-offs sin evidencia. Una casilla en un formulario no prueba nada cuando sucede el incidente.
- UAT como ocurrencia tardía. UAT recibe los últimos dos días antes de la entrega; los problemas encontrados allí o se envían o la entrega se retrasa.
- Escenarios obsoletos. Los escenarios escritos para la versión 1 siguen siendo los únicos escenarios para la versión 4.
- Sin loop de retroalimentación de producción. El escenario autorizado nunca se re-verifica en producción, así que la desviación pasa desapercibida.
- Programación manual. Las sesiones de UAT se coordinan por correo electrónico con colisiones de calendario de cinco vías.
- Herramientas desconectadas. Sign-offs por correo electrónico, escenarios en un documento, evidencia en una unidad compartida; nada es rastreable.
Flujo diario AI-nativo
El UAT Analyst trabaja principalmente en Microsoft 365 (Teams, Loop) y Visual Studio Code con GitHub Copilot, invocando el agente Acceptance Scribe para redactar y mantener escenarios.
Setup matinal
- Abre el canal Release Candidate en Microsoft Teams; verifica qué features están en la cola de UAT.
- En VS Code, ejecuta
/uat-plan --release=nextpara regenerar el plan con tiempos de sesión, participantes y slots de evidencia requeridos. - Revisa alertas de desviación nocturna de Azure Application Insights contra escenarios previamente autorizados.
- Trae el último
SPECIFICATION.mdy confirma que requisitos nuevos o cambiados tengan escenarios en borrador listos para revisión. - Sincroniza con el Business Analyst para confirmar que el vocabulario de dominio se haya añadido al glosario.
Ejecución al mediodía
- Facilita sesiones de UAT con expertos de dominio. Usa el MCP Playwright para grabar cada walkthrough.
- Para cada escenario ejecutado, ejecuta
/sign-offpara capturar el resultado, enlace de evidencia e identidad del firmante; el prompt escribe un registro firmado en el repositorio. - Para requisitos nuevos, invoca
/acceptance-scenariospara redactar bloques Given-When-Then en lenguaje de negocio, luego revisa con el experto de dominio antes de congelar. - Abre un PR que añade o actualiza los archivos de escenario; los revisores incluyen el Business Analyst y el Product Owner.
Revisión al final de la tarde
- Ejecuta
/business-tracepara regenerar la matriz de trazabilidad y publicarla en Loop para los stakeholders. - Verifica el reporte de divergencia: cualquier telemetría de producción que contradiga un escenario autorizado se convierte en un ticket de incidente en GitHub Projects.
- Publica un resumen diario en Microsoft Teams con conteos de sign-offs, escenarios abiertos y cronograma del próximo día.
Primitivas recomendadas
Agente
| Agente | Archivo | Propósito |
|---|---|---|
acceptance-scribe | .github/agents/acceptance-scribe.agent.md | Redacta escenarios de aceptación, mantiene el plan de UAT, registra sign-offs y refresca la matriz de trazabilidad de negocio |
Slash prompts
| Comando | Archivo | Propósito |
|---|---|---|
/acceptance-scenarios | .github/prompts/acceptance-scenarios.prompt.md | Convertir un requisito de negocio en escenarios Given-When-Then en lenguaje de negocio |
/uat-plan | .github/prompts/uat-plan.prompt.md | Generar el cronograma de UAT, participantes, slots de evidencia para una entrega |
/sign-off | .github/prompts/sign-off.prompt.md | Capturar una aceptación autorizada y respaldada por evidencia de un escenario |
/business-trace | .github/prompts/business-trace.prompt.md | Refrescar la matriz de trazabilidad de negocio y exportar a Azure DevOps Test Plans |
Instrucciones con alcance
Alcance (applyTo) | Archivo | Propósito |
|---|---|---|
docs/scenarios/**/*.feature | .github/instructions/scenarios.instructions.md | Reglas en lenguaje de negocio, sin jerga técnica, un requisito por escenario |
docs/uat/**/*.md | .github/instructions/uat-plan.instructions.md | Formato del plan de UAT con participantes, fechas, enlaces de evidencia |
docs/signoff/**/*.md | .github/instructions/signoff.instructions.md | Formato de sign-off con firmante, marca de tiempo, URL de evidencia |
Hooks
pre-release: bloquea la entrega si algún requisito en alcance carece de un escenario autorizadopost-merge: reconstruye la matriz de trazabilidad de negocio y envía a Azure DevOps Test Plansnightly: compara telemetría de producción contra escenarios autorizados y emite problemas de divergenciapre-uat-session: genera el correo del participante, invitación de Teams y lista de verificación de evidenciapost-uat-session: archiva la grabación del MCP Playwright en Azure Blob Storage y la enlaza desde el sign-off
MCPs validados
| MCP | Propósito | Dueño |
|---|---|---|
| GitHub MCP Server | Gestionar PRs que añaden escenarios y sign-offs, abrir problemas de divergencia | GitHub |
| Azure DevOps MCP Server | Sincronizar plan de UAT y sign-offs en Azure DevOps Test Plans | Microsoft |
| Playwright MCP | Grabar cada walkthrough de UAT para evidencia | Microsoft |
| Azure MCP Server | Extraer telemetría de Application Insights para detección de desviación de producción | Microsoft |
| Microsoft Learn Docs MCP | Resolver semántica de features de Microsoft 365 y Azure referenciadas en escenarios | Microsoft |
Ejemplos reales
Escenario A: un nuevo flujo de aprobación de reclamaciones
El Business Analyst publica REQ-CLM-210: “Los aprobadores deben recibir una notificación de Teams dentro de 30 segundos de que una reclamación entra en revisión.” El UAT Analyst invoca /acceptance-scenarios para redactar tres escenarios Given-When-Then (camino feliz, camino retrasado, camino usuario no disponible). Se realiza una sesión con dos expertos de dominio; el Acceptance Scribe registra los walkthroughs vía MCP Playwright. /sign-off captura las firmas. La matriz de trazabilidad de negocio cambia REQ-CLM-210 de draft a accepted-prod.
Escenario B: divergencia capturada en producción
La telemetría de Application Insights muestra que las notificaciones tardan 70 segundos en el 2 por ciento de las reclamaciones un sábado. El hook de divergencia nocturna compara contra el autorizado REQ-CLM-210 y abre una incidencia de GitHub en minutos. El UAT Analyst coordina con el SRE; la causa raíz es el throttling de Azure Service Bus. Después de la corrección, un /sign-off acortado re-verifica el escenario, y la matriz vuelve a accepted-prod.
Escenario C: retiro de un escenario
Un regulador depreca un paso de KYC; el Business Analyst marca REQ-KYC-018 como retirado. El UAT Analyst invoca /business-trace para tachar el escenario, archiva el último sign-off con razón retired y publica el registro de cambios en Microsoft Loop. Ingeniería elimina el camino de código con confianza porque la matriz de trazabilidad no muestra escenarios downstream restantes.
Anti-patrones
- Sign-off de casilla. Una firma sin evidencia enlazada no es mejor que ningún sign-off. Siempre adjunta la grabación de Playwright y un ID de escenario.
- Ingeniería redacta escenarios. Cuando los ingenieros redactan escenarios de negocio, codifican suposiciones del código; haz que los expertos de dominio revisen o rechacen cada escenario.
- UAT agrupado al final. UAT por feature supera UAT por entrega; retrasar colapsa la ventana de retroalimentación.
- Inflación de escenarios. Los escenarios que prueban diez cosas a la vez no pueden autorizarse limpiamente. Un escenario, un resultado.
- Glosario sin dueño. Un glosario de dominio sin dueño designado se pudre; el UAT Analyst es el dueño.
- Sign-offs obsoletos. Un sign-off de seis entregas atrás no prueba nada sobre el código de hoy; actualiza en cambios de versión mayor.
- Escenarios ocultos. Los escenarios en una unidad privada o hilo de correo no pueden auditarse; todo vive en el repositorio.
KPIs y métricas de impacto
| Métrica | Baseline (manual) | Objetivo (agéntico) | Fuente |
|---|---|---|---|
| Requisitos con escenario autorizado | 70 por ciento | 100 por ciento | Matriz de trazabilidad de negocio |
| Tiempo de ciclo de sign-off | 4 días | < 1 día | Timestamps de PR de GitHub |
| Divergencias de producción a escenario sin resolver > 24h | 10 | 0 | Hook de divergencia |
| Sesiones de UAT grabadas | 40 por ciento | 100 por ciento | Archivo del MCP Playwright |
| Incidentes de desviación de vocabulario de negocio | 6 por trimestre | 0 | Diff de glosario |
| Tasa de ausencia de participantes | 25 por ciento | < 5 por ciento | Invitaciones de Teams |
| Preparación para auditoría de sign-off | Días | Minutos | Exportación de Azure DevOps Test Plans |
Madurez en cuatro niveles
- L1 Manual: Escenarios en un documento compartido, sign-offs por correo, sin grabaciones, sin matriz de trazabilidad.
- L2 Asistido: Copilot redacta escenarios pero los humanos los copian manualmente en un wiki; los sign-offs son capturas de pantalla.
- L3 Aumentado: Agente Acceptance Scribe, cuatro slash prompts, instrucciones con alcance, grabaciones del MCP Playwright enlazadas desde sign-offs.
- L4 Autónomo: Detección de divergencia nocturna, programación automatizada en Microsoft Teams, matriz de trazabilidad de negocio publicada diariamente en Loop, hook de pre-entrega bloquea requisitos inaceptables automáticamente.
Integración con otras personas
- Del Business Analyst: requisitos aprobados con sentencias EARS y actualizaciones de glosario de dominio.
- Del Product Owner: plan de entrega priorizado indicando qué requisitos necesitan UAT en este ciclo.
- Para el Developer: problemas de divergencia con escenarios autorizados enlazados y telemetría de Application Insights.
- Con QA Engineer: fixtures compartidas de Playwright; escenarios de aceptación alimentan candidatos de suite de regresión.
- Para el Compliance Auditor: la matriz de trazabilidad de negocio y artefactos autorizados como evidencia de auditoría.
- Para el Release Manager: hook de pre-entrega bloquea en sign-offs faltantes.
- Con Tech Writer: sincronización de glosario para que los docs de usuario y escenarios compartan el mismo vocabulario.
Glosario
- Escenario de aceptación: un bloque Given-When-Then escrito en lenguaje de negocio, propiedad de un experto de dominio.
- Sign-off: una aceptación autorizada, marcada con tiempo y enlazada a evidencia de un escenario.
- Matriz de trazabilidad de negocio: el mapeo vivo desde requisito a escenario a evidencia a firmante.
- Divergencia: comportamiento de producción que contradice un escenario autorizado, detectado por comparación de telemetría.
- Glosario de dominio: la lista canónica de términos de negocio compartidos entre ingeniería y el negocio.
- Evidencia: un walkthrough grabado, típicamente producido vía MCP Playwright, referenciado desde el sign-off.
- Ensayo: el walkthrough final antes de la entrega, ejecutado en un ambiente de staging con el roster completo de participantes.
Referencias
- Azure DevOps Test Plans — destino oficial para evidencia y planes de UAT
- Microsoft Teams y Loop para colaboración — canales de comunicación de stakeholders
- Playwright MCP — grabación y ejecución de walkthroughs de aceptación
- GitHub Projects — rastreo de tickets de divergencia
- Application Insights para monitoreo en vivo — señal de divergencia de producción
- Microsoft Purview protección de información — preparación de auditoría para evidencia de sign-off
- GitHub Actions — orquestación de CI y deployment en toda la pila
- Microsoft Learn Docs MCP — recuperación de documentación de primera parte en tiempo de implementación
- GitHub Advanced Security — CodeQL, Dependabot, Secret Scanning, Push Protection