ideiasti

Bem vindo ao Blog ideiasti, um blog voltado para Qualidade de Software e Engenharia de Software

Metodologias Ágeis e QA: Scrum, Kanban e XP na Prática

Testes Automatizados · 6 de julho de 2026

📖 7 min de leitura

QA em Scrum

Cerimônias e QA

Sprint Planning

# Sprint Planning - Input de QA


Antes da Planning


  • [ ] Backlog priorizado pelo PO
    1. [ ] User stories com critérios de aceitação
      2. 

    2. [ ] Histórias técnicas identificadas
      3. 

    

    Durante Planning
    

    Para cada história
    1. PO apresenta requirements
      2. 

    2. Devs estimam esforço
      3. 

    3. QA identifica:
      4. 

      - Riscos de teste
  - Dados necessários
  - Dependências
  - Complexidade de automação
    1. timebox: ~1 hora por sprint
      2. 

    

    Output
    1. [ ] Sprint backlog definido
      2. 

    2. [ ] Definition of Done clara
      3. 

    3. [ ] Dívidas técnicas identificadas
      4.

Daily Standup

# Daily Standup - QA Updates


Formato: 3 perguntas



O que fiz ontem para ajudar o time?
  1. "Finalizei testes da história #123"
    2. 

  2. "Revisei PR do João"
    3. 



O que farei hoje?
  1. "Vou testar história #124"
    2. 

  2. "Vou automatizar teste de login"
    3. 



Há algum impedimento?
  1. "Aguardando ambiente de staging"
    2. 

  2. "Preciso de acesso ao banco de produção"
    3. 



Tips para QA
  1. Mantenha updates curtos (~30 segundos)
    2. 

  2. Identifique bloqueios rápido
    3. 

  3. Ajude devs com code review
    4. 

  4. Coordene com outros QAers
    5.

Sprint Review

# Sprint Review - Testing Handoff


Demo Checklist
  1. [ ] Funcionalidades demonstradas
    2. 

  2. [ ] Critérios de aceitação cumpridos
    3. 

  3. [ ] Testes executados
    4. 

  4. [ ] Bugs documentados
    5. 



Demo Format
  1. "O que foi feito?"
    2. 

  2. "Como funciona?"
    3. 

  3. "O que não foi feito?" (e por quê)
    4. 

  4. "Próximos passos"
    5. 



Feedback de QA
  1. Qualidade geral
    2. 

  2. Issues encontrados
    3. 

  3. Recomendações
    4.

Sprint Retrospective

# Sprint Retrospective - QA Focus


Start (O que começar a fazer?)
  1. "Começar a fazer BDD com time"
    2. 

  2. "Começar a documentar testes"
    3. 



Stop (O que parar de fazer?)
  1. "Parar de fazer testes manuais em features pequenas"
    2. 

  2. "Parar de aceitar histórias sem critérios de aceitação"
    3. 



Continue (O que continuar fazendo?)
  1. "Continuar pair testing"
    2. 

  2. "Continuar code reviews"
    3. 



Ações para Próximo Sprint
  1. [ ] Ação 1 - Responsável: João
    2. 

  2. [ ] Ação 2 - Responsável: Maria
    3.

Definition of Done (DoD)

# Definition of Done - Checklist


Para uma história ser considerada "Done":



Código
  1. [ ] Código implementado
    2. 

  2. [ ] Code review aprovado
    3. 

  3. [ ] Branch merged to main
    4. 

  4. [ ] Sem warnings de linter
    5. 



Testes
  1. [ ] Unit tests escritos (> 80{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442} coverage)
    2. 

  2. [ ] Testes de integração passando
    3. 

  3. [ ] Testes funcionais passando
    4. 

  4. [ ] Testes de performance (se aplicável)
    5. 

  5. [ ] Accessibility testes (se aplicável)
    6. 



Qualidade
  1. [ ] Segurança revisada
    2. 

  2. [ ] Performance considerada
    3. 

  3. [ ] Responsivo (se web/mobile)
    4. 

  4. [ ] Logs implementados
    5. 



Documentação
  1. [ ] README atualizado
    2. 

  2. [ ] API docs (se aplicável)
    3. 

  3. [ ] Swagger/OpenAPI atualizado
    4. 



Deploy
  1. [ ] Deploy em staging
    2. 

  2. [ ] Smoke tests passando
    3. 

  3. [ ] Ready for production
    4.

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

# 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"], "{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}Y-{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}m-{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}d")
        done = datetime.datetime.strptime(ticket["done"], "{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}Y-{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}m-{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}d")



lead_time = (done - created).days
        cycle_time = (done - datetime.datetime.strptime(
            ticket["dev_start"], "{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}Y-{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}m-{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}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

# Pair Programming Roles


Driver
  1. Escreve o código
    2. 

  2. Focado na implementação
    3. 

  3. Compartilha tela
    4. 



Navigator
  1. Revisa código em tempo real
    2. 

  2. Pensa estrategicamente
    3. 

  3. Busca melhorias
    4. 

  4. Agenda refatoração
    5. 



Dicas
  1. Troque papéis a cada 30-60 minutos
    2. 

  2. Mantenha comunicação aberta
    3. 

  3. Ambos são responsáveis pela qualidade
    4. 



Benefícios
  1. 15{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442} mais lento, mas 15{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442} menos bugs
    2. 

  2. Transferência de conhecimento
    3. 

  3. Catches bugs em tempo real
    4.

TDD em XP

# 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

# 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

# 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):
        """{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442} 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{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}
# Defect Density: < 0.5 per story
# Escape Rate: < 10{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}

Test Velocity

# Test Velocity Metrics


metrics:
  - name: "Tests Written per Sprint"
    target: 50
    current: 47



- name: "Automation Coverage"
    target: "80{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}"
    current: "72{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}"



- name: "Test Execution Time"
    target: "< 30 min"
    current: "35 min"



- name: "Test Maintenance Effort"
    target: "< 20{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}"
    current: "25{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}"

Checklist de Práticas Ágeis para QA

Sprint

  1. [ ] Participar de planning
  2. [ ] Identificar riscos de teste
  3. [ ] Atualizar testes para histórias
  4. [ ] Executar testes
  5. [ ] Reportar bugs
  6. [ ] Participar de review
  7. [ ] Retrospectiva de QA

Continuous

  1. [ ] Manter testes atualizados
  2. [ ] Pair testing quando possível
  3. [ ] Code reviews
  4. [ ] CI/CD passing
  5. [ ] 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