# Metodologias Ágeis e QA: Scrum, Kanban e XP na Prática **Meta Description:** Entenda como QA se integra às metodologias ágeis: Scrum, Kanban e XP. Aprenda a aplicar práticas de qualidade em equipes ágeis. --- ## QA em Scrum ### Cerimônias e QA #### Sprint Planning ```markdown # Sprint Planning - Input de QA ## Antes da Planning - [ ] Backlog priorizado pelo PO - [ ] User stories com critérios de aceitação - [ ] Histórias técnicas identificadas ## Durante Planning ### Para cada história - PO apresenta requirements - Devs estimam esforço - QA identifica: - Riscos de teste - Dados necessários - Dependências - Complexidade de automação - timebox: ~1 hora por sprint ## Output - [ ] Sprint backlog definido - [ ] Definition of Done clara - [ ] Dívidas técnicas identificadas ``` #### Daily Standup ```markdown # Daily Standup - QA Updates ## Formato: 3 perguntas ### O que fiz ontem para ajudar o time? - "Finalizei testes da história #123" - "Revisei PR do João" ### O que farei hoje? - "Vou testar história #124" - "Vou automatizar teste de login" ### Há algum impedimento? - "Aguardando ambiente de staging" - "Preciso de acesso ao banco de produção" ## Tips para QA - Mantenha updates curtos (~30 segundos) - Identifique bloqueios rápido - Ajude devs com code review - Coordene com outros QAers ``` #### Sprint Review ```markdown # Sprint Review - Testing Handoff ## Demo Checklist - [ ] Funcionalidades demonstradas - [ ] Critérios de aceitação cumpridos - [ ] Testes executados - [ ] Bugs documentados ## Demo Format 1. "O que foi feito?" 2. "Como funciona?" 3. "O que não foi feito?" (e por quê) 4. "Próximos passos" ## Feedback de QA - Qualidade geral - Issues encontrados - Recomendações ``` #### Sprint Retrospective ```markdown # Sprint Retrospective - QA Focus ## Start (O que começar a fazer?) - "Começar a fazer BDD com time" - "Começar a documentar testes" ## Stop (O que parar de fazer?) - "Parar de fazer testes manuais em features pequenas" - "Parar de aceitar histórias sem critérios de aceitação" ## Continue (O que continuar fazendo?) - "Continuar pair testing" - "Continuar code reviews" ## Ações para Próximo Sprint - [ ] Ação 1 - Responsável: João - [ ] Ação 2 - Responsável: Maria ``` ### Definition of Done (DoD) ```markdown # Definition of Done - Checklist Para uma história ser considerada "Done": ## Código - [ ] Código implementado - [ ] Code review aprovado - [ ] Branch merged to main - [ ] Sem warnings de linter ## Testes - [ ] Unit tests escritos (> 80% coverage) - [ ] Testes de integração passando - [ ] Testes funcionais passando - [ ] Testes de performance (se aplicável) - [ ] Accessibility testes (se aplicável) ## Qualidade - [ ] Segurança revisada - [ ] Performance considerada - [ ] Responsivo (se web/mobile) - [ ] Logs implementados ## Documentação - [ ] README atualizado - [ ] API docs (se aplicável) - [ ] Swagger/OpenAPI atualizado ## Deploy - [ ] Deploy em staging - [ ] Smoke tests passando - [ ] Ready for production ``` --- ## QA em Kanban ### Quadro Kanban ``` ┌──────────┬──────────┬──────────┬──────────┬──────────┐ │ BACKLOG │ READY │ IN DEV │ TEST │ DONE │ ├──────────┼──────────┼──────────┼──────────┼──────────┤ │ Story 5 │ Story 1 │ Story 2 │ Story 3 │ Story 4 │ │ Story 6 │ │ │ │ Story 7 │ │ Story 8 │ │ │ │ │ └──────────┴──────────┴──────────┴──────────┴──────────┘ ∞ 5 3 3 ∞ ``` ### WIP Limits | Column | WIP Limit | Reason | |--------|-----------|--------| | Ready | 5 | Capacidade do time | | In Dev | 3 | Focus por developer | | Test | 3 | Capacidade QA | | Review | 2 | Bottlenecks visíveis | ### Métricas Kanban ```python # Lead Time e Cycle Time import datetime def calculate_metrics(): tickets = [ { "id": "PROD-123", "created": "2024-01-01", "ready": "2024-01-03", "dev_start": "2024-01-05", "dev_done": "2024-01-08", "test_start": "2024-01-09", "test_done": "2024-01-10", "done": "2024-01-10", } ] for ticket in tickets: created = datetime.datetime.strptime(ticket["created"], "%Y-%m-%d") done = datetime.datetime.strptime(ticket["done"], "%Y-%m-%d") lead_time = (done - created).days cycle_time = (done - datetime.datetime.strptime( ticket["dev_start"], "%Y-%m-%d" )).days print(f"{ticket['id']}: Lead={lead_time}d, Cycle={cycle_time}d") # Throughput def throughput(team_tickets): completed_last_30d = sum( 1 for t in team_tickets if is_done_recently(t, 30) ) return completed_last_30d ``` ### Classes of Service | Class | Priority | WIP | Lead Time Target | |-------|----------|-----|------------------| | Expedite | Crítica | 1 | < 1 dia | | Fixed Date | Alta | 2 | Na data | | Standard | Normal | ∞ | < 5 dias | | Intangible | Baixa | ∞ | Quando possível | --- ## XP (Extreme Programming) e QA ### Práticas XP #### Pair Programming ```markdown # Pair Programming Roles ## Driver - Escreve o código - Focado na implementação - Compartilha tela ## Navigator - Revisa código em tempo real - Pensa estrategicamente - Busca melhorias - Agenda refatoração ## Dicas - Troque papéis a cada 30-60 minutos - Mantenha comunicação aberta - Ambos são responsáveis pela qualidade ## Benefícios - 15% mais lento, mas 15% menos bugs - Transferência de conhecimento - Catches bugs em tempo real ``` #### TDD em XP ```python # Ciclo TDD em XP # Red -> Green -> Refactor (em pares!) # 1. RED: Escrever teste que falha def test_calcular_imposto(): resultado = calcular_imposto(100, 0.1) assert resultado == 10 # 2. GREEN: Fazer passar (mínimo) def calcular_imposto(valor, taxa): return 10 # Hardcoded # 3. REFACTOR: Melhorar (em par) def calcular_imposto(valor, taxa): return valor * taxa ``` #### Continuous Integration ```yaml # CI Pipeline XP Style name: XP CI on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 # 1. Commit pequeno # 2. Build e test - run: pip install pytest pytest-cov # 3. Todos testes passando - run: pytest -v --cov=src --cov-fail-under=80 # 4. Integrar frequentemente - name: Merge if green if: github.ref == 'main' run: echo "Ready to merge" ``` --- ## Métricas Ágeis de QA ### Defect Metrics ```python # Defect Metrics class DefectMetrics: def __init__(self, sprints): self.sprints = sprints def defect_leakage(self, sprint): """Defeitos encontrados em produção vs. antes""" prod_bugs = sprint.bugs_found_in_prod total_bugs = sprint.total_bugs return (prod_bugs / total_bugs) * 100 if total_bugs else 0 def defect_densities(self, sprints): """Densidade de defeitos por feature""" return { sprint.name: len(sprint.defects) / sprint.stories_completed for sprint in sprints } def escape_rate(self, sprint): """% de defeitos que escaparam para prod""" escaped = sprint.defects_found_after_release total = sprint.total_defects return (escaped / total * 100) if total else 0 # Targets # Defect Leakage: < 15% # Defect Density: < 0.5 per story # Escape Rate: < 10% ``` ### Test Velocity ```yaml # Test Velocity Metrics metrics: - name: "Tests Written per Sprint" target: 50 current: 47 - name: "Automation Coverage" target: "80%" current: "72%" - name: "Test Execution Time" target: "< 30 min" current: "35 min" - name: "Test Maintenance Effort" target: "< 20%" current: "25%" ``` --- ## Checklist de Práticas Ágeis para QA ### Sprint - [ ] Participar de planning - [ ] Identificar riscos de teste - [ ] Atualizar testes para histórias - [ ] Executar testes - [ ] Reportar bugs - [ ] Participar de review - [ ] Retrospectiva de QA ### Continuous - [ ] Manter testes atualizados - [ ] Pair testing quando possível - [ ] Code reviews - [ ] CI/CD passing - [ ] Métricas atualizadas --- ## Conclusão QA em agile requer adaptação constante e colaboração. As chaves são: 1. **Integração** - QA não é fase separada 2. **Comunicação** - Time completo é responsável 3. **Automação** - Habilita velocidade 4. **Métricas** - Medir para melhorar 5. **Melhoria** - Retrospectivas e adaptação