paulasilvatech ASP Personas do SDLC Agêntico v1.0.0
EN PT ES
14 quality · Verification

Analista de UAT

Testes de aceitação de negócio.

Atualizado: 2026-04-24 14 seções Baixar .zip

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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ã

  1. Abra o canal de Release Candidate no Microsoft Teams; verifique quais features estão na fila de UAT.
  2. No VS Code, rode /uat-plan --release=next para regenerar o plano com horários de sessão, participantes e slots de evidência necessários.
  3. Revise alertas noturnos de drift do Azure Application Insights contra cenários previamente assinados.
  4. Puxe o último SPECIFICATION.md e confirme que requisitos novos ou alterados têm cenários rascunhados prontos para revisão.
  5. Sincronize com o Business Analyst para confirmar vocabulário de domínio adicionado ao glossário.

Execução no meio do dia

  1. Facilite sessões de UAT com especialistas de domínio. Use o Playwright MCP para gravar cada walkthrough.
  2. Para cada cenário executado, rode /sign-off para capturar o resultado, o link de evidência e a identidade do assinante; o prompt grava um registro assinado no repositório.
  3. Para novos requisitos, invoque /acceptance-scenarios para redigir blocos Given-When-Then em linguagem de negócio, depois revise com o especialista de domínio antes de congelar.
  4. 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

  1. Rode /business-trace para regenerar a matriz de rastreabilidade e publicá-la no Loop para stakeholders.
  2. 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.
  3. Poste um resumo diário no Microsoft Teams com contagens de sign-off, cenários abertos e cronograma do dia seguinte.

Primitivas recomendadas

Agente

AgenteArquivoPropósito
acceptance-scribe.github/agents/acceptance-scribe.agent.mdRedige 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

ComandoArquivoPropósito
/acceptance-scenarios.github/prompts/acceptance-scenarios.prompt.mdConverter um requisito de negócio em cenários Given-When-Then em linguagem de negócio
/uat-plan.github/prompts/uat-plan.prompt.mdGerar o cronograma de UAT, participantes, slots de evidência para um release
/sign-off.github/prompts/sign-off.prompt.mdCapturar uma aceitação assinada e respaldada por evidência de um cenário
/business-trace.github/prompts/business-trace.prompt.mdAtualizar a matriz de rastreabilidade de negócio e exportar para o Azure DevOps Test Plans

Instruções com escopo

Escopo (applyTo)ArquivoPropósito
docs/scenarios/**/*.feature.github/instructions/scenarios.instructions.mdRegras de linguagem de negócio, sem jargão técnico, um requisito por cenário
docs/uat/**/*.md.github/instructions/uat-plan.instructions.mdFormato do plano de UAT com participantes, datas, links de evidência
docs/signoff/**/*.md.github/instructions/signoff.instructions.mdFormato 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 assinado
  • post-merge: reconstruir a matriz de rastreabilidade de negócio e enviá-la ao Azure DevOps Test Plans
  • nightly: comparar telemetria de produção contra cenários assinados e emitir issues de divergência
  • pre-uat-session: gerar o email de participantes, convite do Teams e checklist de evidência
  • post-uat-session: arquivar a gravação do Playwright MCP no Azure Blob Storage e linká-la do sign-off

MCPs validados

MCPPropósitoDono
GitHub MCP ServerGerenciar PRs que adicionam cenários e sign-offs, abrir issues de divergênciaGitHub
Azure DevOps MCP ServerSincronizar plano e sign-offs de UAT no Azure DevOps Test PlansMicrosoft
Playwright MCPGravar cada walkthrough de UAT como evidênciaMicrosoft
Azure MCP ServerPuxar telemetria do Application Insights para detecção de drift em produçãoMicrosoft
Microsoft Learn Docs MCPResolver semântica de features do Microsoft 365 e Azure referenciadas em cenáriosMicrosoft

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étricaLinha base (manual)Meta (agêntico)Fonte
Requisitos com cenário assinado70 por cento100 por centoMatriz de rastreabilidade de negócio
Tempo de ciclo de sign-off4 dias< 1 diaTimestamps de PR no GitHub
Divergências produção-cenário não resolvidas > 24h100Hook de divergência
Sessões de UAT gravadas40 por cento100 por centoArquivo do Playwright MCP
Incidentes de drift de vocabulário de negócio6 por trimestre0Diff do glossário
Taxa de no-show de participantes25 por cento< 5 por centoConvites do Teams
Prontidão para auditoria do sign-offDiasMinutosExportaçã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