QA Code Review (E2E WebdriverIO)

Esta skill define como revisar código de automação E2E (WebdriverIO) em tests/e2e/ (specs, screenobjects, data, helpers, config), considerando a perspectiva de cada subagent QA e consolidando as preocupações em um relatório focado em manutenção, qualidade e padronização.

When to Use

• •Usuário pede revisão de specs, data, helpers, screenobjects ou fluxo.
• •Usuário pergunta "o que acha do código?" ou "revise esse teste".
• •Usuário quer uma lista consolidada de melhorias sob a ótica dos padrões QA do projeto.

Process

1. •Identificar escopo: O que está em revisão? (spec único, fluxo inteiro, data, helpers, config.)
2. •Aplicar cada perspectiva QA relevante lendo e aplicando os critérios de:
   • •Convenções (maintain): skill-qa-wdio-maintain-conventions — imports relativos, uso de data/, estrutura, seletores (testID, accessibilityLabel).
   • •Setup (add-setup): skill-qa-wdio-add-setup — se hooks ou helpers de setup reduziriam duplicação ou melhorariam a estrutura.
   • •Flow (add-flow): skill-qa-wdio-add-new-flow — ao revisar um fluxo: pastas em specs/, screenobjects, data, nomenclatura.
3. •Opcionalmente considerar:
   • •Test-data: skill-qa-wdio-add-test-data — se a revisão envolve tests/e2e/data/.
   • •Frontend-friendly: skill-frontend-qa-friendly — testID, acessibilidade, seletores estáveis no app.
4. •Produzir um único relatório com a estrutura abaixo.

Output Structure

Entregar o review nesta ordem:

1. Manutenção (convenções)

• •Checklist da skill maintain: imports relativos (sem @playwright/test), uso de data/ vs hardcode, estrutura config/data/helpers/screenobjects/specs, async/await.
• •Explícito: ✅ atende / ⚠️ atenção / ❌ não atende, com motivo breve.

2. Qualidade

• •Seletores: estáveis (testID, accessibilityLabel via helpers getElementByTestID, getElementByText) vs frágeis (XPath por posição, classes).
• •Assertions: expect com critérios claros, timeouts adequados (waitForDisplayed, waitForExist), uso correto de async/await.
• •Legibilidade: Arrange–Act–Assert, comentários úteis, nome do teste descritivo.

3. Padronização

• •Estrutura: tests/e2e/ com specs/, screenobjects/, data/, helpers/ alinhados ao fluxo; nomenclatura de pastas e arquivos.
• •Dados: data/ (Constants.ts, Logins.ts ou módulos) usados nos specs; evitar valores fixos quando há constante.
• •Setup: se fizer sentido sugerir hook no config ou helper compartilhado para evitar duplicação (ex.: login, limpeza de cache).

4. Resumo de melhorias

• •Lista objetiva e acionável (ex.: "Usar PLACE_NAME_TO_TEST de Constants no spec em vez de string fixa").
• •Priorizar: quebra de convenção > qualidade > padronização > sugestões opcionais.

Delegation Note

Você não invoca outros agentes programaticamente. Aplique os critérios você mesmo: leia as skills listadas acima (maintain, add-setup, add-flow e opcionalmente add-test-data, frontend-qa-friendly) e avalie o código como cada um desses agentes avaliaria. Depois una os achados no relatório único (manutenção, qualidade, padronização, resumo).

References

• •AGENTS.md — lista de agents e skills QA
• •Estrutura do projeto: tests/e2e/ (config, data, helpers, screenobjects, specs)