Escrever testes contra um site de produção real parece a abordagem óbvia de prática até um CAPTCHA aparecer. Uma classe CSS pode ser renomeada num deploy que você não sabia, e você passa duas horas depurando um seletor quebrado em vez de aprender a técnica. Sites de prática construídos para automação têm atributos data-testid estáveis, estado previsível e cenários projetados para cobrir o que os entrevistadores realmente perguntam.
Por que você não pode simplesmente praticar em sites aleatórios
A abordagem óbvia é abrir um site qualquer e escrever testes contra ele. Funciona até parar de funcionar.
Sites reais mudam sem aviso. O formulário de login ganha um novo CAPTCHA. Os IDs dos elementos mudam. Uma classe CSS que você usava é renomeada num deploy que você nunca soube. Sua suite de testes quebra aleatoriamente, e depurar leva mais tempo do que escrever os testes.
Sites de prática construídos para testes são diferentes. Têm seletores estáveis, estado previsível e funcionalidades projetadas especificamente para cobrir cenários de automação. Você pode resetar dados, criar usuários, quebrar coisas e experimentar sem consequências.
O que torna um bom site de prática
Um ambiente de prática útil tem:
- Autenticação: fluxos de login/logout, rotas protegidas, tratamento de credenciais inválidas
- Tabelas de dados: ordenação, filtros, paginação, seleção de linhas
- Formulários: erros de validação, campos obrigatórios, dropdowns, date pickers
- Modais: comportamento de abrir/fechar, diálogos de confirmação, submit de formulário dentro de um modal
- Upload de arquivo: arrastar e soltar, validação de tipo de arquivo, progresso de upload
- API: mesmo backend acessível diretamente para testes de API em paralelo com os testes de UI
- Seletores estáveis: atributos
data-testidou IDs confiáveis que não vão mudar
A cobertura de cenários importa mais do que o polimento visual. Um site construído para prática vai ter tudo isso; um site de produção aleatório vai ter talvez dois.
O ambiente de prática lab.becomeqa.com
Construímos um lab de prática dedicado para os exercícios deste curso. Ele fica em lab.becomeqa.com e é gratuito.
O que tem nele:
Login / Autenticação- Fluxo de login válido (email + senha)
- Credenciais inválidas com mensagem de erro
- Rotas protegidas que redirecionam para o login se você não estiver autenticado
- Logout
- Adicionar, editar, deletar itens
- Coluna de status: Planned, In Progress, Completed
- Filtrar por status
- Ordenar por colunas
- Paginação
- Adicionar item abre um modal com formulário
- Editar item: mesmo modal, pré-preenchido
- Modal de confirmação de deleção
- Fechar clicando no X, fechar clicando fora, fechar pressionando Escape
- Upload por clique ou arrastar e soltar
- Validação de tipo e tamanho de arquivo
- Indicador de progresso de upload
- Número do cartão, validade, CVV
- Erros de validação com input inválido
- Fluxo de pagamento simulado
- Endpoints REST para todas as operações de dados
- Autenticação via Bearer token (mesmas credenciais do login da UI)
- Documentação OpenAPI disponível em
/api-docs
Credenciais padrão de teste
URL: https://lab.becomeqa.com
Email: admin@becomeqa.com
Senha: admin123São credenciais compartilhadas para prática. Não armazene dados reais. O lab é resetado periodicamente.
Um teste simples para confirmar o setup
Antes de continuar, verifique que seu ambiente conecta ao lab corretamente:
import { test, expect } from '@playwright/test';
test('lab está acessível e login funciona', async ({ page }) => {
await page.goto('https://lab.becomeqa.com');
await page.getByLabel('Email').fill('admin@becomeqa.com');
await page.getByLabel('Password').fill('admin123');
await page.getByRole('button', { name: 'Sign in' }).click();
await expect(page.getByText('Travel Items')).toBeVisible();
});Se passar, você está pronto.
Outros sites de prática que vale conhecer
O lab cobre os cenários principais deste curso. Para variedade, estes também valem:
The Internet (the-internet.herokuapp.com)Um clássico. Cobre: dropdowns, checkboxes, alertas JavaScript, iframes, drag and drop, upload de arquivo, scroll infinito. Bom para praticar técnicas específicas, mas não tem estrutura de app realista.
SauceDemo (saucedemo.com)Um site de e-commerce falso da Sauce Labs. Login, listagem de produtos, carrinho de compras, checkout. Útil para praticar um fluxo de compra completo. Tem versões quebradas do app para praticar depuração (locked_out_user, error_user).
Uma API REST pública que retorna dados de usuário falsos. Sem UI, só API. Útil para praticar testes de API sem configurar seu próprio backend.
DemoQA (demoqa.com)Cobre formulários, widgets, interações, alertas. Mais focado em componentes de UI do que em fluxos de trabalho. Bom para praticar tipos específicos de elementos.
O que praticar e em que ordem
Siga a ordem deste curso. Cada módulo introduz uma nova técnica; os exercícios do lab a aplicam contra uma funcionalidade real.
A progressão:
1. Escrever um teste de login (navegação básica, preenchimento de formulário, asserção)
2. Adicionar asserções em linhas de tabela (encontrar elementos em uma lista)
3. Abrir e preencher um formulário dentro de um modal
4. Testar validação de formulário (mensagens de erro com input inválido)
5. Upload de arquivo
6. Interceptação de requisição de API (verificar chamadas de rede a partir de ações da UI)
7. Fluxo completo (login > adicionar item > verificar na tabela)
Ao fim do módulo 5 (POM enterprise), você vai ter uma suite de testes completa cobrindo todo o lab. Essa suite está pronta para portfólio. Demonstra a mesma estrutura usada em projetos de automação em produção.
→ Veja também: Testes de API com Playwright: Além da Interface | SQL para QA: As Consultas que Você Realmente Precisa