6 min leitura • Guide 769 of 877
Estratégias de Teste para Equipes Ágeis
Teste não é uma fase - é contínuo. O GitScrum ajuda equipes a integrar testes em cada sprint e entregar software de qualidade consistentemente.
Pirâmide de Testes
Níveis de Teste
PIRÂMIDE DE TESTES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ /\ │
│ / \ TESTES E2E │
│ / \ Poucos, lentos, caros │
│ /──────\ Testam jornadas de usuário │
│ / \ │
│ / \ TESTES DE INTEGRAÇÃO │
│ / \ Quantidade média │
│ /──────────────\ Testam interação de componentes│
│ / \ │
│ / \ TESTES UNITÁRIOS │
│ / \ Muitos, rápidos, baratos │
│ /────────────────────── Testam unidades individuais│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PROPORÇÃO RECOMENDADA: │
│ 70% Testes unitários │
│ 20% Testes de integração │
│ 10% Testes E2E │
│ │
│ PRINCÍPIO CHAVE: │
│ Feedback mais rápido = mais baixo na pirâmide │
│ Maior confiança = mais alto na pirâmide │
│ Balance ambas necessidades │
└─────────────────────────────────────────────────────────────┘
Testes em Sprints
Testes Integrados
TESTES DENTRO DE STORIES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ STORY COM TESTES INCLUÍDOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PROJ-200: Cadastro de Usuário ││
│ │ ││
│ │ CRITÉRIOS DE ACEITE: ││
│ │ ☐ Usuário pode cadastrar com email/senha ││
│ │ ☐ Validação de email funciona ││
│ │ ☐ Força de senha validada ││
│ │ ☐ Email de confirmação enviado ││
│ │ ☐ Email duplicado prevenido ││
│ │ ││
│ │ REQUISITOS DE TESTE: ││
│ │ ☐ Testes unitários para lógica de validação ││
│ │ ☐ Teste de integração para fluxo de cadastro ││
│ │ ☐ Teste E2E para happy path ││
│ │ ☐ Edge cases testados ││
│ │ ││
│ │ EDGE CASES PARA TESTAR: ││
│ │ ☐ Formatos inválidos de email ││
│ │ ☐ Senhas fracas ││
│ │ ☐ Cadastro duplicado ││
│ │ ☐ Falha do serviço de email ││
│ │ ││
│ │ ESTIMATIVA: 5 pontos (inclui testes) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ANTI-PADRÃO: │
│ ❌ Story: 3 pontos │
│ ❌ Tarefa separada "Testes": 2 pontos │
│ │
│ CORRETO: │
│ ✅ Story: 5 pontos (testes incluídos) │
│ ✅ Não está done até testes passarem │
└─────────────────────────────────────────────────────────────┘
Workflow de QA
QA NO WORKFLOW ÁGIL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QA CONTÍNUO (não fim-de-sprint): │
│ │
│ TIMELINE DO SPRINT: │
│ │
│ Dia 1-2: │
│ • Dev começa feature │
│ • QA revisa critérios de aceite │
│ • QA escreve casos de teste │
│ │
│ Dia 3-5: │
│ • Dev completa feature │
│ • QA testa conforme features completam │
│ • Bugs corrigidos imediatamente │
│ │
│ Dia 6-8: │
│ • Teste completo de features │
│ • Testes de regressão │
│ • Polimento e correções │
│ │
│ Dia 9-10: │
│ • Verificação final │
│ • Preparação para release │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NÃO FAÇA ASSIM: │
│ │
│ Dia 1-7: Dev desenvolve │
│ Dia 8-10: QA testa tudo → Caos, bugs acumulados │
└─────────────────────────────────────────────────────────────┘
Automação de Testes
O Que Automatizar
DECISÕES DE AUTOMAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AUTOMATIZE: │
│ ──────────── │
│ ✅ Testes de regressão (rodam toda vez) │
│ ✅ Testes unitários (feedback rápido) │
│ ✅ Testes de API (estáveis, rápidos) │
│ ✅ Smoke tests (verificação básica) │
│ ✅ Validações de dados │
│ ✅ Cálculos de negócio │
│ │
│ MANTENHA MANUAL: │
│ ──────────────── │
│ ✅ Teste exploratório (descobrir unknowns) │
│ ✅ Teste de usabilidade (julgamento humano) │
│ ✅ Features novas (entender primeiro) │
│ ✅ Testes visuais complexos │
│ ✅ Cenários raros │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ROI DA AUTOMAÇÃO: │
│ │
│ Alto ROI: │
│ • Roda frequentemente │
│ • Resultados previsíveis │
│ • Fácil de manter │
│ │
│ Baixo ROI: │
│ • Raramente roda │
│ • Ambiente instável │
│ • Alta manutenção │
└─────────────────────────────────────────────────────────────┘
Rastreando Automação
TRACKING DE AUTOMAÇÃO NO GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAREFAS DE AUTOMAÇÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TECH-50: Automatizar testes de regressão de login ││
│ │ ││
│ │ ESCOPO: ││
│ │ ☐ Login com email/senha ││
│ │ ☐ Login social (Google, GitHub) ││
│ │ ☐ Reset de senha ││
│ │ ☐ Logout ││
│ │ ││
│ │ CRITÉRIOS DE ACEITE: ││
│ │ ☐ Testes rodam em CI ││
│ │ ☐ Tempo de execução < 2 min ││
│ │ ☐ Zero falsos positivos ││
│ │ ☐ Documentação atualizada ││
│ │ ││
│ │ ESTIMATIVA: 3 pontos ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MÉTRICAS A ACOMPANHAR: │
│ │
│ • % de testes automatizados │
│ • Tempo de execução da suite │
│ • Taxa de flakiness │
│ • Bugs escapados para produção │
└─────────────────────────────────────────────────────────────┘
Definition of Done
Incluindo Testes
DOD COM QUALIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DEFINITION OF DONE PADRÃO: │
│ │
│ CÓDIGO: │
│ ☐ Código completo e commitado │
│ ☐ Code review aprovado │
│ ☐ Sem TODOs ou código comentado │
│ │
│ TESTES: │
│ ☐ Testes unitários escritos e passando │
│ ☐ Cobertura de código ≥ 80% (para lógica nova) │
│ ☐ Testes de integração (se aplicável) │
│ ☐ Testes de regressão passando │
│ ☐ Teste manual de AC's feito │
│ │
│ QUALIDADE: │
│ ☐ Zero bugs conhecidos P1/P2 │
│ ☐ Performance aceitável │
│ ☐ Segurança verificada (se aplicável) │
│ │
│ DOCUMENTAÇÃO: │
│ ☐ Documentação técnica atualizada │
│ ☐ Release notes preparadas │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SE NÃO ATENDE DoD: │
│ • Story não está done │
│ • Não conta na velocity │
│ • Não vai para release │
└─────────────────────────────────────────────────────────────┘