Communitygithub.com

DeanMcCoppin/browser-qa

Verificação de UI pós-implantação em um navegador real: erros de console e rede, verificação rápida de Core Web Vitals, formulários e fluxos de autenticação com contas de teste, capturas de tela em 375/768/1440px contra baselines e verificações de acessibilidade axe, resultando em um veredito SHIP / SHIP WITH FIXES / DO NOT SHIP. Use após implantar em staging ou URL de preview, antes de enviar alterações de frontend, ao revisar um PR de frontend ou para verificar layout responsivo e acessibilidade em uma página ativa.

O que é browser-qa?

Este é um skill de QA automatizado para navegador, focado em verificação visual e de interação pós-implantação. Ele executa uma bateria de testes em fases: smoke test (erros de console, rede, Core Web Vitals), teste de interação (navegação, formulários, fluxos de autenticação com credenciais de teste), regressão visual (comparação de screenshots em três breakpoints com baselines) e acessibilidade (axe-core, keyboard nav, landmarks). Por segurança, por padrão opera somente leitura e exige opt-in explícito para jornadas mutantes (como checkout/pagamento) — nunca em produção. No final, gera um relatório estruturado em markdown com um veredito: SHIP (liberar), SHIP WITH FIXES (liberar com correções) ou DO NOT SHIP (não liberar). O skill funciona com qualquer ferramenta de automação de navegador disponível na sessão (Claude in Chrome, Playwright MCP ou script Playwright).

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/DeanMcCoppin/Skills/tree/main/plugins/code-audit/skills/browser-qa
Ver original→Navegar por todas as habilidades

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentação

QA de Navegador — Testes Visuais e de Interação Automatizados

Quando Usar

  • Após implantar uma funcionalidade em staging/preview
  • Quando precisar 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 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 ativas como um usuário real.

Segurança em primeiro lugar — raio de explosão (execute somente leitura por padrão)

O QA de 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 um opt-in explícito e uma URL de staging/preview. Use credenciais de teste semeadas, nunca logins reais de produção, e redija credenciais/tokens/PII antes de salvar qualquer screenshot.

Fase 1: Teste Rápido (Smoke Test)

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 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 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 prod)
5. Teste jornadas críticas do usuário (checkout, onboarding, busca)
   — somente leitura por padrão; execute jornadas mutantes apenas contra staging
     com opt-in explícito (veja "Segurança em primeiro lugar" acima)

Fase 3: Regressão Visual

1. Capture screenshots das páginas principais em 3 breakpoints (375px, 768px, 1440px)
2. Compare com screenshots baseline confirmados
   — sem baseline ⇒ relate INCONCLUSIVO, nunca um PASS silencioso
3. Sinalize alterações de layout > 5px, elementos faltantes, 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 marcos (landmarks) 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 verificação com leitor de tela ainda precisam de uma verificação manual. Não relate "acessível" apenas com base em uma execução automatizada.

Formato de Saída

## Relatório QA — [URL] — [timestamp]

### Teste Rápido (Smoke Test)
- 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, baixo contraste nos links do rodapé

### Veredito: SHIP WITH FIXES (2 problemas, 0 bloqueadores)
# veredito ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP; use INCONCLUSIVO se não houver baseline visual

Integração

Funciona com qualquer ferramenta de navegador que a sessão tiver: Claude in Chrome (mcp__claude-in-chrome__*), um servidor MCP Playwright ou um script Playwright simples executado no shell. Se nenhum estiver disponível, informe e ofereça um script Playwright em vez de adivinhar resultados.

Para verificações repetíveis, transforme descobertas em testes com e2e-testing; para profundidade de acessibilidade, veja accessibility.

Habilidades Relacionadas

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community