Testes Agéis

Testes Ágeis: Estratégias para Equipes Ágeis e DevOps

Testes Ágeis: Estratégias para Equipes Ágeis e DevOps

Featured

Meta Description: Aprenda estratégias de testes ágeis para equipes Scrum, Kanban e DevOps. Como implementar qualidade contínua em ciclos de desenvolvimento rápidos.

Introdução aos Testes Ágeis

Testes ágeis é uma abordagem que integra atividades de teste ao longo de todo o ciclo de desenvolvimento ágil, em vez de tratá-las como uma fase separada após a implementação. Esta filosofia promove qualidade contínua e colaboração entre desenvolvedores e testadores.

Princípios Fundamentais

  1. Qualidade é responsabilidade de todos – Toda equipe é responsável pela qualidade
  2. Testar cedo e frequentemente – Shift-Left em ação
  3. Automação como habilitador – CI/CD e testes automatizados
  4. Feedback rápido – loops de feedback curtos
  5. Adaptação contínua – Melhoria baseada em retrospectivas

Testes em Diferentes Frameworks Ágeis

1. Testes em Scrum

Distribuição de Testes por Sprint

Sprint (2 semanas)
├── Semana 1
│   ├── Dia 1-2: Planejamento + Desenvolvimento User Stories
│   ├── Dia 3-4: Desenvolvimento + Testes Unitários
│   └── Dia 5: Integração + Testes de Integração
│
└── Semana 2
    ├── Dia 1-2: Testes manuais/exploratórios
    ├── Dia 3-4: Automação de regressão
    └── Dia 5: Demo + Retrospectiva

Definition of Done (DoD)

Cada User Story só está “Done” quando:

  • [ ] Código implementado
  • [ ] Unit tests escritos e passando (>80% coverage)
  • [ ] Code review aprovado
  • [ ] Testes de integração passando
  • [ ] Testes funcionais passando
  • [ ] Critérios de aceitação cumpridos
  • [ ] Documentação atualizada
  • [ ] Ready for Production

Definition of Ready (DoR)

Antes de entrar no Sprint:

  • [ ] Critérios de aceitação definidos
  • [ ] Critérios de aceite claros e testáveis
  • [ ] Dependências identificadas
  • [ ] Estimativa de tamanho feita
  • [ ] Wireframes/UI definidos (se aplicável)

2. Testes em Kanban

WIP Limits para QA

Etapa WIP Limit Razón
To Do 10 Capacidade da equipe
In Progress 5 Permite foco
Testing 3 Qualidade no teste
Review 2 bottlenecks visíveis
Done ∞ Meta, não limite

Fluxo de Testes Contínuo

Backlog → Ready → In Dev → In Test → Ready to Deploy → Done
              ↑                                   ↓
              ←←←←←← BUG FOUND ←←←←←←←←←←←←←←←←←←←

3. Testes em SAFe (Scaled Agile)

Hierarquia de Testes

Portfolio
    ↓
Value Stream
    ↓
Large Solution (Program)
    ├── Solution Demo
    ├── Solution Acceptance
    └── System Integration
        ↓
    Agile Release Train (ART)
    ├── Iteration Planning
    ├── Continuous Delivery Pipeline
    └── System Demo
        ↓
    Team
    ├── Unit Tests
    ├── Component Tests
    └── Feature Tests

Estratégias de Teste por Fase Ágil

Sprint 0: Preparação

Atividades de Teste:

✅ Configurar ambiente de teste
✅ Implementar framework de automação
✅ Definir estratégia de testes
✅ Criar templates de casos de teste
✅ Estabelecer métricas de qualidade

Durante o Sprint

Daily Testing Activities

  1. Code Reviews – Verificar antes de commitar
  2. Unit Tests – Desenvolvedor escreve junto com código
  3. Peer Testing – Testar funcionalidades de colegas
  4. Continuous Integration – Execução automática em cada commit

Quando Receber uma User Story

1. READ → Ler critérios de aceitação
2. DISCUSS → Tirar dúvidas com PO/analista
3. CLARIFY →确保 compreensão comum
4. PLAN → Identificar casos de teste
5. TEST → Executar durante desenvolvimento
6. AUTOMATE → Scripts de automação
7. VERIFY → Confirmar que está "Done"

Fim do Sprint

Sprint Review Testing

  • Demonstração de funcionalidades
  • Validação com stakeholders
  • Verificação de DoD
  • Feedback do Product Owner

Sprint Retrospective

  • O que funcionou bem em QA?
  • O que precisa melhorar?
  • Ações de melhoria para próximo sprint

Testes Ágeis em Prática

Behavior-Driven Development (BDD)

O Ciclo BDD

        SPECIFICATION
              ↓
    ┌─────────────────────┐
    │   User Stories      │
    │   (Given-When-Then) │
    └─────────────────────┘
              ↓
        IMPLEMENTATION
              ↓
    ┌─────────────────────┐
    │   Executable Specs  │
    │   (Cucumber/Behave) │
    └─────────────────────┘
              ↓
         VALIDATION
              ↓
         FEEDBACK

Exemplo de Cenário BDD

# features/login.feature
Feature: Login de Usuário

  Como um usuário registrado
  Quero fazer login no sistema
  Para acessar minha conta

  Scenario: Login com credenciais válidas
    Given que estou na página de login
    And o usuário "joao@exemplo.com" está registrado
    When eu preencho o campo email com "joao@exemplo.com"
    And eu preencho o campo senha com "Senha@123"
    And clico no botão "Entrar"
    Then sou redirecionado para o dashboard
    And uma mensagem de boas-vindas é exibida

  Scenario: Login com senha incorreta
    Given que estou na página de login
    And o usuário "joao@exemplo.com" está registrado
    When eu preencho o campo email com "joao@exemplo.com"
    And eu preencho o campo senha com "senhaerrada"
    And clico no botão "Entrar"
    Then permaneço na página de login
    And uma mensagem de erro "Credenciais inválidas" é exibida

# steps/login_steps.py
from behave import given, when, then
from selenium.webdriver.common.by import By

@given('que estou na página de login')
def step_impl(context):
    context.driver.get('https://exemplo.com/login')

@when('eu preencho o campo email com "{email}"')
def step_impl(context, email):
    context.driver.find_element(By.ID, 'email').send_keys(email)

@then('sou redirecionado para o dashboard')
def step_impl(context):
    assert 'dashboard' in context.driver.current_url

Test-Driven Development (TDD)

Ciclo Red-Green-Refactor

    RED          GREEN         REFACTOR
     ↓            ↓              ↓
┌─────────┐  ┌─────────┐   ┌─────────────┐
│Escreva   │  │Faça o   │   │Melhore o    │
│Teste que │→ │teste    │→  │código sem   │
│falha    │  │passar   │   │alterar      │
└─────────┘  └─────────┘   │comportamento│
     ↑                        └─────────────┘
     └──────────────────────────────┘
              (Repetir)

Exemplo TDD

# TDD: Calculadora de desconto

# 1. RED - Escrever teste que falha
def test_calcular_desconto_10_porcento():
    resultado = calcular_desconto(100, 10)
    assert resultado == 90  # Falha!

# 2. GREEN - Implementar código mínimo
def calcular_desconto(valor, percentual):
    return valor - (valor * percentual / 100)

# 3. REFACTOR - Melhorar código
def calcular_desconto(valor: float, percentual: float) -> float:
    """Calcula o valor final após desconto."""
    if not 0 <= percentual <= 100:
        raise ValueError("Percentual deve estar entre 0 e 100")
    return valor * (1 - percentual / 100)

Automação de Testes em Ambientes Ágeis

Pirâmide de Testes Ágil

                    /\
                   /  \
                  / E2E \     10% - Testes end-to-end
                 /________\   Testes de aceitação de usuário
                /          \
               /Integração  \ 20% - Testes de API/serviços
              /______________\
             /                \
            /   Unitários      \ 70% - Testes unitários
           /____________________\ Rápidos, isolados, confiáveis

Ferramentas por Camada

Camada Ferramentas Linguagem
Unit JUnit, pytest, Jest, Mocha Qualquer
Integration TestContainers, Postman Qualquer
E2E Playwright, Cypress, Selenium TS/JS/Python
Contract Pact, Spring Cloud Contract Java/JS
Performance k6, JMeter, Gatling Multi

CI/CD Pipeline com Testes

# .github/workflows/ci.yml
name: CI Pipeline

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest

    services:
      postgres:
        image: postgres:15
        env:
          POSTGRES_DB: testdb
          POSTGRES_USER: test
          POSTGRES_PASSWORD: test

    steps:
      - uses: actions/checkout@v4

      # Build
      - name: Build application
        run: npm ci && npm run build

      # Testes Unitários
      - name: Unit tests
        run: npm run test:unit -- --coverage
        env:
          DB_HOST: postgres

      # Testes de Integração
      - name: Integration tests
        run: npm run test:integration
        env:
          DB_HOST: postgres

      # Testes E2E
      - name: E2E tests
        run: npm run test:e2e
        if: github.event_name == 'push'

      # Análise de Código
      - name: SonarCloud Analysis
        uses: SonarSource/sonarcloud-github-action@master
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

      # Upload Coverage
      - name: Upload coverage
        uses: codecov/codecov-action@v3

Métricas Ágeis de Qualidade

burndown de Defeitos

Dias:   1  2  3  4  5  6  7  8  9 10
        │  │  │  │  │  │  │  │  │  │
Ideal ──└──┴──┴──┴──┴──┴──┴──┴──┴──┘
        │
Real ───└──┬──┬──┬──┐     ┌──┬──┬──┘
          │  │  │  │     │  │  │
         d1 d2 d3 d4     d7 d8 d9

Meta: Reduzir defeitos abertos ao longo do sprint

Relatório de Qualidade do Sprint

Métrica Sprint Anterior Sprint Atual Target
Defeitos abertos no início 15 12 <10
Defeitos criados 8 6 <5
Defeitos resolvidos 11 10 >8
Defeitos em aberto no fim 12 8 <5
Cobertura de código 72% 78% >80%
Testes passando 95% 97% >98%

Velocity de Testes

# Métricas de velocity de testes
velocity_data = {
    "sprints": [1, 2, 3, 4, 5],
    "testes_automatizados": [45, 68, 92, 115, 140],
    "cobertura": [45, 55, 65, 73, 80],
    "tempo_execucao_min": [60, 50, 42, 35, 30]
}

# Tendências
tendencia_teste = calculate_trend(velocity_data["testes_automatizados"])
tendencia_cobertura = calculate_trend(velocity_data["cobertura"])
tendencia_tempo = calculate_trend(velocity_data["tempo_execucao_min"], descending=True)

Desafios e Soluções

Desafio 1: Falta de Tempo para Testes

Soluções:

  • Automatizar tarefas repetitivas
  • Priorizar testes de maior impacto
  • Implementar Shift-Left
  • Dedicated time para automação

Desafio 2: Testes Lentes no CI

Soluções:

  • Execução paralela
  • Selecionar testes por impacto
  • Cache de dependências
  • Execução em cloud

Desafio 3: Testes Flaky

Soluções:

  • Waits explícitos ao invés de sleeps
  • Isolamento de testes
  • Retry strategies
  • Investigar root cause

Desafio 4: Cobertura Insuficiente

Soluções:

  • TDD para novos features
  • Code coverage gates
  • Análise de risco para priorizar
  • Pair testing com devs

Checklist de Testes Ágeis

Antes do Sprint

  • [ ] User Stories com critérios de aceitação claros
  • [ ] Ambiente de teste configurado
  • [ ] Framework de automação pronto
  • [ ] Dados de teste准备好了

Durante o Sprint

  • [ ] Unit tests escritos com código
  • [ ] Code reviews realizados
  • [ ] CI pipeline passando
  • [ ] Testes manuais/exploratórios executados

Fim do Sprint

  • [ ] Todos os testes passando
  • [ ] DoD cumprido para cada story
  • [ ] Regressão executada
  • [ ] Métricas atualizadas
  • [ ] Retrospectiva de QA realizada

Conclusão

Testes ágeis não são apenas sobre ferramentas e automação – são sobre uma mentalidade de qualidade compartilhada por toda a equipe. As chaves para o sucesso são:

  1. Integração – Testes não são fase separada
  2. Automação – Habilitador de velocidade
  3. Colaboração – Todos responsáveis por qualidade
  4. Feedback – Loops curtos de informação
  5. Melhoria – Retrospectivas e adaptação

FAQ

P: Como introduzir testes em uma equipe que não faz?
R: Comece com unit tests, demonstre valor com métricas, expanda gradualmente.

P: Quantos testadores uma equipe ágil precisa?
R: Não há número fixo. A proporção ideal depende da complexidade do projeto e maturidade da equipe.

P: Testes manuais ainda fazem sentido em ágil?
R: Sim! Exploratory testing, UX testing e testes de novos cenários ainda são valiosos.

P: Como medir sucesso de testes ágeis?
R: Métricas como cobertura, tempo de execução, defeitos em produção e velocity.