Browser QA — Teste Visual Automatizado e Interação
Quando Usar
- Após implantar uma funcionalidade em staging/preview
- Quando precisar verificar o comportamento da IU em várias páginas
- Antes do lançamento — confirmar que layouts, formulários e interações realmente funcionam
- Ao revisar PRs que mexem no código frontend
- 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 primeiro — raio de alcance (executar somente leitura por padrão)
O QA de Navegador usa autenticação real e jornadas reais de usuário, portanto trate o raio de alcance explicitamente. Padrão é somente leitura: nunca execute uma jornada mutante (checkout, pagamento, exclusão, atualização em massa) contra uma URL de produção — exija uma aceitação explícita e uma URL staging/preview. Use credenciais de teste semeadas, nunca logins reais de produção, e remova credenciais/tokens/PII antes de salvar qualquer captura de tela.
Fase 1: Teste de Fumaça
1. Navegue até a URL alvo
2. Verifique erros de console (filtre ruídos: analytics, terceiros)
3. Verifique se não há 4xx/5xx nas requisições de rede
4. Capture tela acima da dobra em viewport desktop + mobile
5. Verifique 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 mortos
2. Envie formulários com dados válidos — verifique estado de sucesso
3. Envie formulários com dados inválidos — verifique estado de erro
4. Teste fluxo de autenticação: login → página protegida → logout (apenas credenciais de teste, nunca produção)
5. Teste jornadas críticas de usuário (checkout, onboarding, pesquisa)
— somente leitura por padrão; exercite jornadas mutantes apenas contra staging
com aceitação explícita (veja "Segurança primeiro" acima)
Fase 3: Regressão Visual
1. Capture tela de páginas-chave em 3 breakpoints (375px, 768px, 1440px)
2. Compare com capturas de tela de linha de base commitadas
— sem linha de base ⇒ reporte INCONCLUSIVO, nunca um PASS silencioso
3. Sinalize mudanças de layout > 5px, elementos ausentes, overflow
4. Verifique 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 pontos de referência de leitor de tela
Nota: axe-core cobre automaticamente cerca de 30–40% da WCAG. Uma execução limpa é necessária, não suficiente — navegação por teclado, ordem de foco e uma verificação com leitor de tela ainda precisam de verificação manual. Não relate "acessível" apenas com uma verificação automatizada.
Formato de Saída
## Relatório de 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 e-mail inválido
- [✓] Fluxo de autenticação: login/logout funcionando
### Visual
- [✗] Seção hero transborda no viewport 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.