📊 Relatório Allure ao vivo — atualizado automaticamente a cada execução na main.
Este repositório contém testes automatizados do site automationexercise.com utilizando Playwright, Cucumber (BDD/Gherkin) e Page Object Model (POM).
O objetivo é demonstrar habilidades práticas de QA Automation, cobrindo fluxos de login, cadastro, logout, produtos, carrinho, checkout, contato, newsletter e verificações de segurança passivas com testes End-to-End (E2E).
Status: migração concluída (era baseado no saucedemo.com, mais simples). Cobertura atual: login, cadastro, logout, busca de produtos, carrinho, checkout, contato, newsletter e segurança (headers, HTTPS, cookies).
qa-playwright-sd/
├── .github/
│ ├── workflows/ # Pipeline de CI (GitHub Actions)
│ ├── ISSUE_TEMPLATE/ # Template de bug report
│ └── dependabot.yml # Atualização automática de dependências
├── docs/
│ ├── criterios-aceite/ # Critérios de aceite por feature (Dado/Quando/Então)
│ └── test-cases.md # Matriz de rastreabilidade de test cases
├── features/ # Cenários em Gherkin (.feature)
├── steps/ # Implementação dos steps do Cucumber
├── pages/ # Page Objects (LoginPage, RegisterPage, ...)
├── reports/ # Relatório HTML gerado a cada execução (não versionado)
├── allure-results/ # Dados brutos do Allure Report (não versionado)
├── cucumber.js # Configuração do Cucumber
├── eslint.config.js # Configuração do ESLint
├── .prettierrc.json # Configuração do Prettier
├── .env.example # Modelo de variáveis de ambiente
├── package.json # Dependências e scripts NPM
├── tsconfig.json # Configuração do TypeScript
├── Dockerfile # Imagem para rodar os testes containerizados
├── LICENSE # Licença MIT
├── SECURITY.md # Política de divulgação de vulnerabilidades
└── README.md # Este arquivo
git clone https://github.com/ThomasTDS/qa-playwright-sd.git
cd qa-playwright-sd
Requer Node.js 22 ou superior (engines no package.json).
npm install
npx playwright install
npm test
NOTA: Por padrão, os testes rodam com o navegador visível (headless = false). Para rodar em modo headless (ex.: como no CI), use a variável de ambiente HEADLESS:
# PowerShell
$env:HEADLESS="true"; npm test
# bash
HEADLESS=true npm test
Cenários críticos ponta-a-ponta são marcados com a tag @smoke. Para rodar só esse subconjunto:
npm run test:smoke
O projeto usa ESLint (qualidade/erros de código) e Prettier (formatação consistente):
npm run lint # verifica problemas de lint
npm run lint:fix # corrige o que for possível automaticamente
npm run format # formata todos os arquivos com Prettier
npm run format:check # só verifica, sem alterar (usado no CI)
npm run typecheck # verifica erros de tipos do TypeScript (sem gerar arquivos)
Um hook de pre-commit (via Husky + lint-staged) roda automaticamente a cada git commit, aplicando ESLint e Prettier só nos arquivos que estão staged — assim problemas de lint/formatação são pegos antes mesmo de chegar ao CI. O hook é instalado automaticamente pelo npm install (script prepare).
Por padrão os testes rodam no Chromium. Para rodar em outro navegador, defina BROWSER (chromium, firefox ou webkit):
# PowerShell
$env:BROWSER="firefox"; npm test
# bash
BROWSER=firefox npm test
O CI roda a suíte completa nos três navegadores a cada execução.
Cenários marcados com a tag @mobile (os mais sensíveis a layout: login, busca de produtos, carrinho e o fluxo completo de checkout) também rodam com emulação de um Pixel 7 (viewport, user agent e touch do dispositivo real, via o preset do próprio Playwright). Para rodar localmente:
# PowerShell
$env:DEVICE="mobile"; npm test -- --tags "@mobile"
# bash
DEVICE=mobile npm test -- --tags "@mobile"
Com DEVICE=mobile, a variável BROWSER é ignorada e o Chromium é usado sempre — é o defaultBrowserType do próprio preset do Pixel 7 no Playwright. O CI roda esse subconjunto automaticamente a cada execução, além dos três navegadores desktop.
Achado real ao validar isso: em viewport mobile estreito, anúncios do Google AdSense (incluindo um widget "side rail" fixo) carregam de forma assíncrona e tardia, causando um layout shift grande o bastante pra sobrepor botões reais da página — reproduzido e confirmado via o log de actionability do Playwright (
<iframe ... title="Advertisement"> ... subtree intercepts pointer events), tanto no botão "add to cart" quanto no modal de confirmação. É instabilidade real de terceiro, mas não é algo que faz sentido "esperar passar" com retry (às vezes persiste nas duas tentativas) nem contornar clicando em outro lugar (o anúncio pode acabar em qualquer posição). A solução foi bloquear as requisições aos domínios de anúncio do Google (googlesyndication.com,doubleclick.net, etc.) no contexto de teste — não é algo que estamos testando, é ruído de terceiro ortogonal ao comportamento da aplicação, o mesmo raciocínio de quem mockaria um widget de pagamento externo instável.
Por padrão os testes apontam para https://automationexercise.com/. Para rodar contra outro ambiente, defina BASE_URL:
# PowerShell
$env:BASE_URL="https://outro-ambiente.com/"; npm test
# bash
BASE_URL=https://outro-ambiente.com/ npm test
Os cenários de login usam uma conta já existente no automationexercise.com, definida por variável de ambiente (nunca hardcoded no código). Copie .env.example para .env (arquivo não versionado) e preencha:
BASE_URL=https://automationexercise.com/
HEADLESS=false
TEST_USER_EMAIL=
TEST_USER_PASSWORD=
No CI, essas mesmas variáveis vêm de GitHub Secrets (TEST_USER_EMAIL/TEST_USER_PASSWORD), configurados no repositório.
O Dockerfile usa a imagem oficial do Playwright (já com Chromium, Firefox e WebKit instalados), então não é preciso instalar navegadores localmente.
docker build -t qa-playwright-sd .
docker run --rm --env-file .env -v "$(pwd)/reports:/app/reports" qa-playwright-sdO --env-file .env repassa as credenciais de teste para o container, e o volume em reports/ traz o relatório HTML gerado de volta para a máquina host. Para rodar em outro navegador ou só o smoke, passe a variável ou o comando por cima do CMD padrão, por exemplo:
docker run --rm --env-file .env -e BROWSER=firefox -v "$(pwd)/reports:/app/reports" qa-playwright-sdCada execução gera reports/cucumber-report.html (não versionado) com o resultado dos cenários. Testes que falham têm automaticamente um print da tela no momento da falha anexado ao relatório, um trace do Playwright (traces/*.zip, não versionado) com a timeline completa da execução, DOM snapshots e código-fonte da ação que falhou, e um vídeo da execução do cenário (videos/*.webm, não versionado). Para abrir um trace: npx playwright show-trace traces/<arquivo>.zip. Cenários que passam gravam o vídeo normalmente, mas ele é descartado ao final — só os de cenários que falham são mantidos em disco.
Além do HTML do Cucumber, cada execução também gera dados brutos para o Allure Report em allure-results/ (não versionado). Para visualizar:
npm run allure:generate # gera allure-report/ a partir de allure-results/
npm run allure:open # abre o relatório gerado no navegadorO Allure agrupa os cenários por feature/severidade, mostra histórico de execuções e é mais navegável que o HTML simples do Cucumber para investigar uma suíte grande.
No CI, esse relatório é publicado automaticamente no GitHub Pages a cada push na main e a cada execução diária agendada — sempre reflete o estado real da última execução, falhe ela ou não.
Nota de configuração: o formatter
allure-cucumberjs/reporternão convive com os formatters de terminalprogress/summarydo Cucumber — ao combinar qualquer um deles, os arquivos deallure-results/simplesmente deixam de ser gerados, sem erro visível (parece bug de integração entre as duas libs). Por isso ocucumber.jsusa sóallure-cucumberjs/reporter+html, sem formatter de progresso no terminal — o trade-off é não ver mais o resumo"N scenarios (N passed)"direto no terminal/log do CI, só nos relatórios gerados.
-
BDD / Gherkin: Cenários claros e legíveis em .feature.
-
Page Object Model (POM): Separação de responsabilidades, com Pages encapsulando elementos e ações.
-
Testes End-to-End (E2E): Simulação de fluxos reais de usuário — login, cadastro, logout, busca de produtos, carrinho, checkout, contato e newsletter.
-
Multi-dispositivo: além dos três navegadores desktop, os cenários mais sensíveis a layout (login, busca, carrinho, checkout) rodam também com emulação de um Pixel 7 (tag
@mobile), validando que o fluxo crítico funciona em viewport mobile. -
Massa de dados dinâmica com Faker.js (locale pt-BR): o cenário de cadastro gera nome, e-mail, empresa, endereço e telefone diferentes a cada execução, evitando colisão com contas de execuções anteriores sem depender de timestamp no e-mail.
-
QA de Segurança (passivo/defensivo): cabeçalhos de segurança HTTP, redirecionamento forçado para HTTPS, mascaramento de campo de senha e flag
HttpOnlydo cookie de sessão. Sem tentativas de exploração ativa contra a aplicação de terceiros — só observação do que ela já expõe publicamente. -
Acessibilidade (passivo, com axe-core): verifica violações
critical/seriousnas páginas de login e produtos. Como a aplicação sob teste é de terceiros, o cenário não quebra o build — as violações encontradas são anexadas ao relatório HTML para documentação, no mesmo espírito da suíte de segurança. -
Verificação de API: chama diretamente a API pública do automationexercise.com (produtos, marcas, busca, login, conta de usuário), sem passar pela interface. Toda resposta é validada contra um schema (Zod, em
pages/api.schemas.ts) construído a partir de respostas reais — não só os campos usados nas asserções, a estrutura inteira. Se a API mudar um campo que nenhum teste checa diretamente, o schema ainda pega.
-
Template de bug report em
.github/ISSUE_TEMPLATE/bug_report.md, com severidade (impacto técnico) e prioridade (urgência de correção) tratadas como campos separados, e causa raiz preenchida só após investigação real. -
Matriz de rastreabilidade em
docs/test-cases.md, ligando cada test case ao cenário.featurecorrespondente via tag@TC-XXX. -
Critérios de aceite em docs/criterios-aceite/, um arquivo por feature, documentando a história de usuário e as regras de negócio em formato Dado/Quando/Então — o "por quê" de cada cenário, complementando o "onde" da matriz de rastreabilidade.
-
Validação de elementos com expect.
-
Estrutura modular que facilita manutenção e evolução.
O projeto roda automaticamente via GitHub Actions (.github/workflows/tests.yml) a cada push/PR para a main e diariamente às 06:00 UTC. Antes dos testes, o CI valida lint (eslint), formatação (prettier --check) e tipos (tsc --noEmit), quebrando o build se algo estiver fora do padrão. Os cenários rodam em paralelo (parallel: 4 no cucumber.js — cada worker abre seu próprio navegador/contexto isolado, sem estado compartilhado entre eles), reduzindo bastante o tempo total de execução. O relatório HTML, o relatório Allure e os traces de falhas são publicados como artifacts de cada execução; o relatório Allure da main também é publicado no GitHub Pages (link no topo deste README). A main é protegida: mudanças precisam passar por Pull Request com o check de testes verde. Cenários que falham são reexecutados automaticamente uma vez (--retry 1), para absorver instabilidades pontuais de rede sem mascarar bugs reais de código.
Investigação real por trás dessa decisão: rodei a suíte completa 4x em cada navegador, sem retry, pra entender de onde vem a instabilidade de verdade (em vez de só confiar no retry sem questionar). Chromium e WebKit ficaram 100% estáveis nas 4 rodadas cada. O Firefox falhou em 2 das 4, sempre no mesmo passo (
deleteAccount) — a princípio parecia um bug específico do navegador, mas investigando mais a fundo (reproduzindo repetidas vezes e capturando a página real no momento da falha) descobri que era um erro 520 do Cloudflare ("Web server is returning an unknown error"), intermitente (~1 em 10 execuções), vindo do próprio automationexercise.com — não é race condition do código nem do navegador. Como é uma falha de infraestrutura de terceiro genuinamente transitória, o--retry 1no nível do cenário já é o mecanismo certo pra absorver isso (ele reexecuta o fluxo inteiro, incluindo uma nova navegação, que na prática sempre resolve). Não havia bug de código pra corrigir aqui — a investigação confirmou que a estratégia de retry já em vigor estava correta.
npm audit --audit-level=highroda no CI a cada execução, quebrando o build se houver vulnerabilidade alta/crítica em dependências.- Dependabot ativo (
.github/dependabot.yml): atualizações automáticas semanais de dependências npm e das actions do workflow, além de alertas de segurança nativos do GitHub. - Política de divulgação de vulnerabilidades em SECURITY.md.
Distribuído sob a licença MIT. Veja LICENSE para mais detalhes.