O que QA do Navegador — Teste Visual Automatizado e de Interação faz?
Quando Usar
- Após implantar um recurso em staging/preview
- Quando você precisa verificar o comportamento da UI em várias páginas
- Antes de enviar — confirme que layouts, formulários e interações realmente funcionam
- Ao revisar PRs que envolvem código de 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 explosão (execute somente leitura por padrão)
O QA do Navegador conduz autenticação real e jornadas reais de usuário, portanto, trate o raio de explosão 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 uma aceitação explícita e uma URL de staging/preview. Use credenciais de teste semeadas, nunca logins reais de produção, e oculte credenciais/tokens/PII antes de salvar qualquer captura de tela.
Fase 1: Teste de Fumaça
1. Navegue para a URL de destino
2. Verifique erros de console (filtre ruído: analytics, terceiros)
3. Confirme que não há 4xx/5xx em requisições de rede
4. Capture a 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 — confirme que não há links quebrados
2. Envie formulários com dados válidos — confirme estado de sucesso
3. Envie formulários com dados inválidos — confirme 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; execute jornadas mutantes apenas contra staging
com aceitação explícita (veja "Segurança primeiro" acima)
Fase 3: Regressão Visual
1. Capture telas de páginas-chave em 3 pontos de quebra (375px, 768px, 1440px)
2. Compare com as capturas de tela de linha de base confirmadas
— sem linha de base ⇒ relate INCONCLUSIVO, nunca um PASS silencioso
3. Sinalize deslocamentos de layout > 5px, elementos ausentes, estouro
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 pontos de referência do leitor de tela
Nota: axe-core cobre automaticamente cerca de 30–40% da WCAG. Uma execução limpa é necessária, não suficiente — a navegação por teclado, a ordem de foco e uma verificação com leitor de tela ainda precisam de uma verificação manual. Não relate "acessível" a partir de uma execução automatizada isoladamente.
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 email inválido
- [✓] Fluxo de autenticação: login/logout funcionando
### Visual
- [✗] Seção Hero estoura no viewport de 375px
- [✓] Modo escuro: todas as páginas consistentes
### Acessibilidade
- 2 violações AA: texto alternativo ausente na imagem do 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.