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

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
1. [ ] Unit tests escritos e passando (>80{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442} coverage)
2. [ ] Code review aprovado
3. [ ] Testes de integração passando
4. [ ] Testes funcionais passando
5. [ ] Critérios de aceitação cumpridos
6. [ ] Documentação atualizada
7. [ ] Ready for Production

Definition of Ready (DoR)

Antes de entrar no Sprint:

1. [ ] Critérios de aceitação definidos
2. [ ] Critérios de aceite claros e testáveis
3. [ ] Dependências identificadas
4. [ ] Estimativa de tamanho feita
5. [ ] 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
DISCUSS → Tirar dúvidas com PO/analista
CLARIFY →确保 compreensão comum
PLAN → Identificar casos de teste
TEST → Executar durante desenvolvimento
AUTOMATE → Scripts de automação
VERIFY → Confirmar que está "Done"

Fim do Sprint

Sprint Review Testing

1. Demonstração de funcionalidades
2. Validação com stakeholders
3. Verificação de DoD
4. Feedback do Product Owner

Sprint Retrospective

1. O que funcionou bem em QA?
2. O que precisa melhorar?
3. 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{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442} - Testes end-to-end
                 /________   Testes de aceitação de usuário
                /          
               /Integração   20{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442} - Testes de API/serviços
              /______________
             /                
            /   Unitários       70{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442} - 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{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}	78{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}	>80{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}
Testes passando	95{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}	97{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}	>98{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}

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:

1. Automatizar tarefas repetitivas
2. Priorizar testes de maior impacto
3. Implementar Shift-Left
4. Dedicated time para automação

Desafio 2: Testes Lentes no CI

Soluções:

1. Execução paralela
2. Selecionar testes por impacto
3. Cache de dependências
4. Execução em cloud

Desafio 3: Testes Flaky

Soluções:

1. Waits explícitos ao invés de sleeps
2. Isolamento de testes
3. Retry strategies
4. Investigar root cause

Desafio 4: Cobertura Insuficiente

Soluções:

1. TDD para novos features
2. Code coverage gates
3. Análise de risco para priorizar
4. Pair testing com devs

---

Checklist de Testes Ágeis

Antes do Sprint

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

Durante o Sprint

1. [ ] Unit tests escritos com código
2. [ ] Code reviews realizados
3. [ ] CI pipeline passando
4. [ ] Testes manuais/exploratórios executados

Fim do Sprint

1. [ ] Todos os testes passando
2. [ ] DoD cumprido para cada story
3. [ ] Regressão executada
4. [ ] Métricas atualizadas
5. [ ] 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.