# Testes Ágeis: Estratégias para Equipes Ágeis e DevOps **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 ```gherkin # 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 ``` ```python # 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 ```python # 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 ```yaml # .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 ```python # 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.