Browser QA — Teste Visual Automatizado e Interação
Quando Usar
- Após implantar uma funcionalidade em staging/preview
- Quando precisar verificar o comportamento da UI em diferentes páginas
- Antes de enviar para produção — confirme se layouts, formulários e interações realmente funcionam
- Ao revisar PRs que alteram o front-end
- Auditorias de acessibilidade e testes responsivos
Como Funciona
Usa o MCP de automação de navegador (claude-in-chrome, Playwright ou Puppeteer) para interagir com páginas ao vivo como um usuário real.
Segurança em primeiro lugar — raio de alcance (executar somente leitura por padrão)
O Browser QA aciona autenticação real e jornadas reais de usuário, portanto trate o raio de alcance explicitamente. Padrão para somente leitura: nunca execute uma jornada mutante (checkout, pagamento, exclusão, atualização em massa) contra uma URL de produção — exija um opt-in explícito e uma URL de staging/preview. Use credenciais de teste preparadas, nunca logins reais de produção, e redija credenciais/tokens/PII antes de salvar qualquer screenshot.
Fase 1: Teste de Fumaça
1. Navegue até a URL alvo
2. Verifique erros de console (filtre ruído: analytics, terceiros)
3. Verifique se não há 4xx/5xx nas requisições de rede
4. Capture screenshot acima da dobra no viewport desktop + mobile
5. Verifique os Core Web Vitals: LCP < 2,5s, CLS < 0,1, INP < 200ms
(INP substituiu FID em março de 2024; limites conforme web.dev)
Fase 2: Teste de Interação
1. Clique em cada link de navegação — verifique se não há links quebrados
2. Envie formulários com dados válidos — verifique o estado de sucesso
3. Envie formulários com dados inválidos — verifique o estado de erro
4. Teste o fluxo de autenticação: login → página protegida → logout (apenas credenciais de teste, nunca produção)
5. Teste jornadas críticas do usuário (checkout, onboarding, pesquisa)
— somente leitura por padrão; apenas execute jornadas mutantes contra staging
com opt-in explícito (veja "Segurança em primeiro lugar" acima)
Fase 3: Regressão Visual
1. Capture screenshots de páginas-chave em 3 breakpoints (375px, 768px, 1440px)
2. Compare com screenshots de base confirmados
— sem linha de base ⇒ reporte INCONCLUSIVO, nunca um PASS silencioso
3. Sinalize mudanças de layout > 5px, elementos ausentes, overflow
4. Verifique o modo escuro se aplicável
Fase 4: Acessibilidade
1. Execute axe-core ou equivalente em cada página
2. Sinalize violações WCAG 2.2 AA (contraste, rótulos, ordem de foco)
3. Verifique se a navegação por teclado funciona de ponta a ponta
4. Verifique os marcos do leitor de tela
Nota: axe-core cobre automaticamente cerca de 30–40% do WCAG. Uma execução limpa é necessária, não suficiente — navegação por teclado, ordem de foco e uma passagem com leitor de tela ainda precisam de uma verificação manual. Não relate "acessível" apenas com base em uma passagem automatizada.
Formato de Saída
## Relatório QA — [URL] — [timestamp]
### Teste de Fumaça
- Erros de console: 0 críticos, 2 avisos (ruído de analytics)
- Rede: todos 200/304, sem falhas
- Core Web Vitals: LCP 1,2s ✓, CLS 0,02 ✓, INP 89ms ✓
### Interações
- [✓] Links de navegação: 12/12 funcionando
- [✗] Formulário de contato: estado de erro ausente para email inválido
- [✓] Fluxo de autenticação: login/logout funcionando
### Visual
- [✗] Seção hero transborda no viewport de 375px
- [✓] Modo escuro: todas as páginas consistentes
### Acessibilidade
- 2 violações AA: texto alternativo ausente na imagem hero, contraste baixo nos links do rodapé
### Veredito: ENVIAR COM CORREÇÕES (2 problemas, 0 bloqueadores)
# veredito ∈ ENVIAR / ENVIAR COM CORREÇÕES / NÃO ENVIAR; use INCONCLUSIVO se não houver linha de base visual
Integração
Funciona com qualquer MCP de navegador:
- Ferramentas
mChild__claude-in-chrome__*(preferido — usa seu Chrome real) - Playwright via
mcp__browserbase__* - Scripts Puppeteer diretos
Combine com /canary-watch para monitoramento pós-implantação.