QA Selenium SD

Português · English

Último relatório de testes publicado

Testes end-to-end usando Selenium WebDriver, TypeScript e Cucumber (BDD), seguindo o padrão Page Object Model (POM).

Site alvo: Automation Exercise

Cobertura atual

• Login (formulários exibidos, login com sucesso, tentativa de login inválida, logout)
• Produtos (busca por nome, busca sem resultados, detalhes do produto)
• Carrinho (adicionar produto, remover produto, carrinho vazio, quantidade e total por item, soma ao adicionar o mesmo produto de novo)
• Checkout sem estar logado (bloqueio esperado)
• Formulário de contato (envio com anexo, cancelamento no diálogo de confirmação, e-mail obrigatório)
• Newsletter do rodapé (assinatura na página inicial e no carrinho via Scenario Outline, e-mail inválido)
• Cadastro de usuário (criação e exclusão de conta, e-mail já existente, e 7 campos obrigatórios em branco via Scenario Outline)
• Checkout completo estando logado (carrinho → checkout → pagamento → confirmação do pedido)
• Tentativa de pagamento sem preencher os dados do cartão (bloqueio esperado)
• API pública do site, sem abrir browser (@api): listagem de produtos e marcas, busca, métodos não suportados, verificação de login, consulta e atualização de conta, e-mail já cadastrado

Quando a conta é só pré-condição (checkout, e-mail já existente), ela é criada pela API (POST /api/createAccount) em vez do formulário, o que deixa o cenário mais rápido e menos frágil. Toda conta de teste criada é excluída ao final do cenário por um hook After que chama a API do site (DELETE /api/deleteAccount). Como o hook roda mesmo quando o cenário falha, nenhuma conta fica acumulada no site. O cenário de cadastro (@TC-009) continua excluindo a conta pela interface, porque a exclusão faz parte do que ele testa.

Cada cenário é identificado e rastreável via tag @TC-XXX, listados em docs/test-cases.md junto com módulo, tipo, prioridade e status de automação. Os fluxos ponta-a-ponta mais críticos têm a tag @smoke e rodam sozinhos com npm run test:smoke, para uma checagem rápida antes de abrir um PR. O CI continua rodando a suíte completa em todo PR.

Estrutura do projeto

src/
├── config/     # variáveis de ambiente (env.ts) e criação do WebDriver
├── pages/      # page objects
├── features/   # especificações em Gherkin (.feature)
├── steps/      # step definitions
└── support/    # world e hooks do Cucumber, dados de teste e cliente da API do site

Pré-requisitos

• Node.js 22, 24 ou 26+ (exigido pelo @cucumber/cucumber)
• Google Chrome instalado (ou Microsoft Edge, veja BROWSER abaixo)

Instalação

npm install
cp .env.example .env

Executando os testes

npm test              # com browser visível
npm run test:headless # em modo headless
npm run test:smoke    # só os cenários @smoke (checagem rápida)
npm run test:api      # só os testes de API, sem browser

Relatórios são gerados em reports/ (HTML e JSON). Quando um cenário de interface falha, o relatório recebe a screenshot, a URL, o HTML da página (pagina.html) e os logs do console do browser (console.log) do momento da falha, então uma falha do CI pode ser investigada só pelo relatório.

Cenários que falham e só passam depois do retry aparecem no resumo do Cucumber como "passed". Para a instabilidade não passar despercebida, eles recebem uma nota "Cenário instável" no relatório HTML, e npm run report:flaky gera uma tabela com todos eles em reports/cenarios-instaveis.md. No CI, essa tabela aparece no resumo do job.

A suíte roda em 2 workers em paralelo (configurado em cucumber.js), reduzindo o tempo total de execução em quase a metade sem abrir muitas sessões de browser simultâneas.

Rodando via Docker

Não precisa de Node nem Chrome instalados localmente — só Docker:

docker build -t qa-selenium-sd .
docker run --rm qa-selenium-sd

A imagem já vem com o Google Chrome instalado e as variáveis BROWSER=chrome/HEADLESS=true configuradas.

Variáveis de ambiente (.env)

Variável	Padrão	Descrição
BASE_URL	https://automationexercise.com	URL base da aplicação sob teste
BROWSER	chrome	chrome ou edge
HEADLESS	false	true para rodar sem interface

Todas as variáveis são lidas num só lugar, src/config/env.ts, que também carrega o .env. O resto do código importa env em vez de ler process.env diretamente.

Qualidade de código

npm run lint
npm run format

Convenção de commits

O projeto segue Conventional Commits: tipo: descrição breve (ex.: feat: adiciona cenário de recuperação de senha).

Tipos aceitos: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert.

Aplicado via commitlint + husky: o hook commit-msg roda automaticamente após npm install (script prepare) e bloqueia qualquer commit fora do padrão.

Changelog

O CHANGELOG.md é gerado a partir dos commits (npm run changelog) e cobre apenas o histórico a partir da adoção do Conventional Commits — commits anteriores a essa convenção não entram. Só feat e fix aparecem no changelog; os demais tipos são considerados detalhes internos.

Integração contínua

Todo push e pull request para master dispara o workflow e2e.yml: um job quality roda lint e type-check e, se passar, um job e2e roda a suíte completa em modo headless no Chrome, publicando o relatório como artefato do job. O Edge continua suportado para execução local (veja BROWSER acima), mas foi removido da matrix de CI por instabilidade recorrente no runner — detalhes na Issue de bug report correspondente.

O workflow também roda todo dia às 06:17 (horário de Brasília), mesmo sem commits novos. O site alvo é de terceiros e pode mudar a qualquer momento, e a execução diária mostra quando uma mudança dele quebra algum fluxo, sem esperar o próximo PR. Se ela falhar, o GitHub avisa por e-mail. O GitHub desativa execuções agendadas de repositórios públicos sem atividade há 60 dias. Se isso acontecer, é só reativar o workflow na aba Actions.

Em todo push direto para master e em toda execução diária (não em pull requests), um terceiro job publica o relatório HTML mais recente no GitHub Pages: thomastds.github.io/qa-selenium-sd.

Um job docker (disparado manualmente via workflow_dispatch, não em todo push) builda a imagem e roda a suíte dentro do container, validando que o Dockerfile continua funcionando.

A master é protegida: só recebe mudanças via pull request, com os checks quality e e2e (chrome) passando e a branch atualizada em relação à master.

Manutenção de dependências

O Dependabot verifica semanalmente atualizações das dependências do npm e das actions usadas no workflow de CI, abrindo um pull request para cada atualização disponível.

Bumps major do TypeScript são ignorados: o @typescript-eslint/eslint-plugin atual só suporta até a versão 6.1, então uma versão major nova quebraria a instalação. A regra sai do dependabot.yml quando essa dependência acompanhar.

Notas técnicas

• O site alvo é monetizado com anúncios que podem sobrepor elementos e até interceptar navegações (interstitials). Para evitar flakiness, o driver.factory.ts bloqueia os domínios de anúncio via Chrome DevTools Protocol (CDP) logo após criar o driver.
• BasePage.click() faz scroll até o elemento e, se o clique nativo for interceptado, tenta um clique via JavaScript como fallback.
• O site alvo fica atrás do Cloudflare, que ocasionalmente trata o IP de datacenter dos runners de CI como suspeito, causando falhas intermitentes que não reproduzem localmente. O cucumber.js configura retry: 2 para absorver essa flakiness de ambiente sem mascarar regressões reais (que falham em todas as tentativas).

Bug reports

Bugs reais encontrados durante o desenvolvimento (na aplicação sob teste, na infraestrutura de CI ou no próprio código de automação) são documentados como Issues usando o template de bug report, com passos para reproduzir, evidências, causa raiz e a correção aplicada.