Testes de aceitação com Playwright MCP: os agentes conduzem os percursos

O que fazem aqui os testes de aceitação com Playwright MCP

Testes de aceitação conduzidos por agentes são um ciclo de verificação em que um agente de IA conduz cada percurso do utilizador num browser real e indica se passa ou falha face a critérios de aceitação congelados. Os percursos de API e MCP correm da mesma forma, como chamadas reais à aplicação em execução.

Um teste que quem constrói escreve para si próprio não prova nada. Queremos o veredito de um agente que apenas lê os critérios e conduz o produto. Depois de o Claude Code construir uma funcionalidade, um segundo agente percorre cada percurso com o Playwright MCP e tira uma captura de ecrã de cada observação decisiva. O ConvOps executa os passos, os pontos de controlo e o ciclo de correção. É um dos ciclos com que gerimos a nossa empresa.

Todos os exemplos usam a Quillbay, uma aplicação fictícia de reserva de aulas para estúdios de cerâmica, e a sua nova lista de espera para aulas lotadas.

Os critérios são congelados primeiro; uma falha volta atrás para ser corrigida e a execução completa repete-se.

Porque o construímos: camadas verdes, percursos partidos

Testes unitários verdes dizem que as peças funcionam. Não dizem nada sobre se uma pessoa consegue concluir a tarefa no ecrã.

Antes deste ciclo, todas as camadas inferiores passavam: testes unitários, revisões de fase, a suíte de regressão no pipeline de merge. Depois, a primeira execução dos percursos conduzida por um agente contra a aplicação real chumbou mesmo assim uma grande parte deles. Os defeitos viviam entre camadas: um link gerado por um serviço e lido por outro, um redirecionamento que perdia um parâmetro. Nenhuma camada era dona da junção, por isso nenhuma a apanhou.

Daí saíram duas convicções. Quem constrói não pode ser o juiz, por isso o testador nunca escreve nem corrige código. E só uma execução contra a aplicação real prova um critério.

Se as funcionalidades dos seus agentes passam em todas as verificações e mesmo assim falham no ecrã, veja como o ConvOps conduz um plano desde os critérios congelados até uma build verificada(abre num novo separador).

Como funciona: seis passos e quatro agentes

A segurança está na ordem dos passos. Os critérios são congelados antes de existir código, o ambiente é provado antes de o testador chegar e a decisão é tomada por alguém que não escreveu a correção.

O Claude Code constrói a funcionalidade entre os passos 2 e 3.

Escrever os critérios. Cada um indica um ator, um comportamento e algo que se possa observar: um ecrã, uma mensagem, uma resposta. «O código existe» nunca é um critério, porque o que não se pode observar não pode ser aceite. A aprovação congela a lista: os passos seguintes nunca acrescentam, retiram nem reinterpretam um critério.

Planear os percursos. Um percurso por critério, citado palavra por palavra e com o respetivo id, para que cada critério tenha exatamente um sítio onde é provado.

Preparar o ambiente. Um agente de infraestrutura dedicado levanta o ambiente da branch do próprio plano, provisiona dados e credenciais pelo mecanismo do plano e regista-os. O ponto de controlo exige verde, não esforço. O testador não prepara nada, por isso não pode passar à custa de um caso fácil feito à sua medida.

Executar, decidir, corrigir. O testador de aceitação conduz os percursos e nunca corrige. Uma falha envia o relatório ao agente de desenvolvimento, que faz commit das correções na mesma branch, e o plano inteiro volta a correr.

O ciclo não tem temporizador: corre depois da construção de cada plano e, numa tarefa, sempre que um percurso mudou. Uma execução ao nível da tarefa deriva 3 a 8 percursos: o caminho feliz mais o caminho de erro de maior risco por cada comportamento alterado. Só se pode dispensar a execução quando não há percurso a conduzir (uma refatoração pura, ferramentas, documentação, configuração ou alterações só de testes), com a razão declarada. Na dúvida, execute.

Os Playwright Test Agents(abre num novo separador) da Microsoft (planner, generator, healer) produzem e reparam código de teste. Os nossos produzem um plano a partir de requisitos congelados e um relatório de vereditos. Os pontos de controlo funcionam como em como construímos um sistema de IA que se melhora a si próprio, e as aprovações são pontos de controlo com intervenção humana.

Quatro agentes planeiam, preparam, testam e corrigem; uma pessoa aprova os critérios e lê cada relatório.

Uma execução, passo a passo: a lista de espera da Quillbay

O momento interessante não é o primeiro FAIL. É a nova execução depois da correção, porque o passo de decisão não aceita outra prova.

Gatilho. Terminam os passos de construção de plan/waitlist. Os critérios FR-1 a FR-4 foram congelados antes de existir qualquer código.

O plano. O percurso U2 cita o FR-2 e transcreve-o: «Quando um lugar fica livre, o primeiro aluno da fila recebe um email cujo link abre a aula com o lugar reservado durante 2 horas.» Cada pré-condição diz como confirmá-la: a aula acc-wl-r7-class-wheel-basics está lotada com 8 de 8 (a página mostra «Full», ou seja, lotada, e o botão Join waitlist, para entrar na lista de espera), os dois alunos conseguem iniciar sessão e o correio enviado chega à caixa de captura.

Cada percurso cita o seu critério palavra por palavra e indica o respetivo id.

Preparar. O agente de infraestrutura prova que wl-waitlist.app.quillbay.example.com e a respetiva API estão verdes, e regista as fixtures dos alunos e a chave do dono do estúdio para reutilização.

Execução 1. O testador de aceitação conduz quatro percursos a 1440x900 e volta a verificar a 390x844 os ecrãs que dependem do layout.

Recomendação: FIX REQUIRED. O U2 é uma junção: a API e a aplicação passam cada uma nos seus testes unitários, e só o percurso atravessa as duas.

Decidir. Uma pessoa aprova o relatório e decide que o plano falhou. O U2 é código que este plano entregou, por isso é corrigido na branch e não registado como ticket.

Corrigir. O agente de desenvolvimento reproduz o U2 no mesmo ambiente, altera o link, corre o teste unitário do ficheiro alterado e faz commit de fix(waitlist): email link uses the class id (4c1e9a7) em plan/waitlist. O agente de infraestrutura configura a captura de correio.

Execução 2. O plano inteiro volta a correr: os quatro percursos, não só o U2 e o U3. Todos passam, e a captura de ecrã do U2 mostra «Seat held for you for 2 hours» (lugar reservado para si durante 2 horas). Recomendação: PROCEED. A decisão é aprovar, e o relatório alimenta a secção de verificação do merge request.

A correção só conta depois de o plano completo voltar a correr e todos os percursos passarem.

Como é o relatório e como o ler

Leia BLOCKED antes de FAIL. Um percurso que ninguém conseguiu conduzir é o que mais provavelmente esconde um defeito real.

Os nossos planos têm mais uma regra: um passo que precisou de um pré-requisito não documentado, de uma nova tentativa ou de uma correção manual é FAIL, mesmo que o comportamento tenha funcionado no fim. Um PASS que precisou de ajuda não vai passar para um utilizador. E um PASS cuja captura de ecrã não mostra o elemento verificado não é prova: quem aceita o veredito abre as imagens.

Leia primeiro o cabeçalho e as linhas BLOCKED: dizem o que a execução não conseguiu testar.

O que corre mal: junções que nenhuma camada assumia

A maioria das nossas falhas de aceitação não foram bugs que escaparam ao modelo. Foram junções entre camadas que nenhuma camada assumia.

A principal tem a forma do U2 da Quillbay: uma primeira execução de aceitação chumba uma grande parte dos percursos enquanto todas as camadas inferiores estão verdes, e cada defeito fica entre camadas. A regra que daí saiu: correr a aceitação num ambiente real antes de os passos de revisão deixarem de ser baratos, e reservar uma segunda execução completa para qualquer plano com superfície de UI, API e MCP.

Cada camada passou sozinha; os defeitos viviam entre elas, onde só um percurso atravessa.

Separar a deteção da correção em trabalhos distintos é também a espinha dorsal do nosso ciclo de autorreparação do website.

Construa o seu: as instruções que cada agente recebe

Comece pelos critérios e pela regra «nunca corrigir». O Playwright MCP é a parte fácil. O testador serve para verificar, não para investigar: depure primeiro e execute a aceitação quando acreditar que a build funciona. Os passos abaixo dão a ordem; estas são as instruções, prontas a copiar.

Planeador de testes: o modelo de percurso.

Para cada critério congelado, escreva UM percurso:
  ID: U<n> (UI) ou A<n> (API/MCP)
  Critério: <FR id>, citado palavra por palavra
  Pré-condições: cada uma com «Como confirmar».
    Uma pré-condição em falta é um bloqueio,
    não algo a contornar.
  Passos: numerados; cada um indica o que vai observar.
  Viewports: 1440x900; volte a verificar a 390x844
    todos os ecrãs que dependem do layout.
  Fixtures: prefixo acc-<plan>-<run>-; varrimento no fim.
Confirme cada percurso face ao que o ambiente
consegue realmente fazer.

Agente de infraestrutura: preparar e verificar.

Prepare o ambiente da branch do plano e prove que está verde.
1. Inicie todos os serviços que o plano toca. Todos têm de
   estar ativos.
2. Provisione dados e credenciais APENAS pelo mecanismo
   do plano. Sem mecanismo: pare e pergunte. Registe as
   credenciais para o testador.
3. Verifique:
   - o endpoint de health devolve 200
   - um endpoint de dados REAL devolve 2xx, não só o health
   - chamada sem autenticação: 401/403; autenticada: 2xx
     (MCP: tools/list E uma chamada autenticada a uma ferramenta)
   - 3-5 páginas principais via Playwright: sem erros na
     consola, sem pedidos falhados, sem ecrãs em branco
   - o fluxo principal funciona de ponta a ponta uma vez
4. Corrija o que está vermelho, volte a verificar e avance
   só com verde. Reporte defeitos do produto com localização
   e provas.
Não execute os percursos. Não desmonte nada.

Testador de aceitação: executar e reportar.

O ambiente está preparado e em execução. Reutilize as
credenciais registadas. Não inicie nem desmonte nada.
Execute cada percurso de UI com o Playwright MCP, cada
percurso de API/MCP com chamadas reais e, depois, a
checklist de regressão.
Siga o plano por ordem. Nunca corrija código. Nunca ignore
uma falha. Nada de testes improvisados.
Tire uma captura de ecrã de cada observação que decide
um passo. Registe os corpos das respostas da API.
Veredito por percurso: PASS, PARTIAL PASS, FAIL, BLOCKED,
COVERED BY SUITE.
Relatório: Cabeçalho; Declarações obrigatórias do
cabeçalho (o que não conseguiu testar, cada item
identificado); Resultados dos percursos; Falhas em detalhe
(passo, esperado, obtido, prova, correção recomendada);
Checklist de regressão; Recomendação: PROCEED ou
FIX REQUIRED.

Regra de decisão.

PASS só quando cada percurso é PASS ou uma exceção
aceite: uma falha em código que esta alteração não
entregou, registada no seu próprio ticket e citada pelo id.
Tudo o resto é FAIL: envie o relatório para a correção e,
depois, execute o plano INTEIRO de novo.
Uma falha em código que esta alteração entregou é
corrigida na branch, nunca registada num ticket à parte.
Não é claro se um comportamento é intencional? Decide
uma pessoa.

Agente de desenvolvimento: corrigir.

Para cada percurso falhado: reproduza-o no mesmo
ambiente, encontre a causa, corrija-a e volte a conduzir
o percurso ao vivo.
Corrija só o que as falhas exigem. Sem minúcias, sem
arrumações.
Corra verificações unitárias e de lint só nos ficheiros
alterados.
Faça commit na mesma branch. Registe o que mudou e porquê.
Nunca certifique a sua própria correção: a nova execução
é a prova.

Esta camada não substitui o CI: os testes unitários, de integração e de regressão continuam a ser o ponto de controlo determinístico no pipeline de merge.

Copie estas instruções e acrescente os passos de aceitação ao seu fluxo de trabalho no ConvOps(abre num novo separador).