8 min leitura • Guide 303 of 877
Melhores Práticas de Quality Assurance
Qualidade não é uma fase—é uma prática integrada em todo o desenvolvimento. As melhores equipes não testam qualidade no final; elas constroem desde o início. Este guia cobre abordagens práticas de quality assurance que escalam com sua equipe.
Pirâmide de Testes
| Nível | Velocidade | Escopo | Quantidade |
|---|---|---|---|
| Unitário | Rápido | Pequeno | Muitos |
| Integração | Médio | Médio | Alguns |
| E2E | Lento | Completo | Poucos |
| Manual | Mais Lento | Variável | Direcionado |
Shift Left
Qualidade Desde o Início
ABORDAGEM SHIFT LEFT
════════════════════
TRADICIONAL (SHIFT RIGHT):
─────────────────────────────────────
Requisitos → Dev → Dev → Dev → QA → QA → Deploy
QA no final:
├── Bugs encontrados tarde
├── Caro para corrigir
├── Pressão para entregar assim
├── Qualidade como pensamento posterior
└── Modo apagar incêndios
SHIFT LEFT:
─────────────────────────────────────
[QA] Requisitos → [QA] Dev → [QA] Review → Deploy
QA durante todo processo:
├── QA no planejamento
├── QA revisa requisitos
├── Testes escritos cedo
├── Testando durante dev
├── Bugs capturados cedo
└── Qualidade construída
PRÁTICAS:
─────────────────────────────────────
Planejamento:
├── QA revisa critérios de aceite
├── Identifica cenários de teste
├── Sinaliza complexidade
├── Estima esforço de teste
└── Parte da equipe
Desenvolvimento:
├── Desenvolvedores escrevem testes unitários
├── TDD para caminhos críticos
├── Parear com QA em cenários
├── Testar conforme codifica
└── Sem "jogar por cima do muro"
Revisão:
├── Testes requeridos no PR
├── Thresholds de cobertura
├── Verificações automáticas passam
├── QA revisa funcionalidade
└── Gate antes do merge
Estratégia de Automação
O Que Automatizar
DECISÕES DE AUTOMAÇÃO
═════════════════════
AUTOMATIZE:
─────────────────────────────────────
Testes unitários (alto valor, rápidos):
├── Lógica de negócios
├── Cálculos
├── Transformações de dados
├── Edge cases
└── Executar a cada commit
Testes de integração (valor médio):
├── Endpoints de API
├── Operações de banco de dados
├── Interações de serviços
├── Fluxos principais
└── Executar a cada PR
Testes E2E (seletivos):
├── Jornadas críticas do usuário
├── Smoke tests
├── Happy paths
├── Fluxos que impactam receita
└── Executar no deploy
Suite de regressão:
├── Bugs encontrados anteriormente
├── Issues corrigidos permanecem corretos
├── Áreas de alto risco
└── Executar regularmente
NÃO AUTOMATIZE:
─────────────────────────────────────
├── Testes exploratórios
├── Avaliação de usabilidade
├── Verificações únicas
├── UI mudando rapidamente
├── Edge cases ainda sendo descobertos
└── Manual é mais efetivo
PRIORIDADE DE AUTOMAÇÃO:
─────────────────────────────────────
ROI = (tempo manual × frequência) / custo automação
Automatize primeiro:
├── Executa muitas vezes
├── Demorado manualmente
├── Caminhos críticos
├── Funcionalidade estável
└── Alto retorno
Pirâmide de Testes
PIRÂMIDE DE TESTES
══════════════════
╱╲
╱ ╲
╱ E2E╲ Poucos
╱testes╲ (10%)
╱────────╲
╱ Integração╲ Alguns
╱ testes ╲ (20%)
╱───────────────╲
╱ Testes unitários ╲ Muitos
╱ ╲(70%)
╱────────────────────────╲
TESTES UNITÁRIOS (Base):
─────────────────────────────────────
├── Rápidos (milissegundos)
├── Muitos (centenas/milhares)
├── Testam uma coisa cada
├── Sem dependências externas
├── Executam constantemente
└── Escritos por desenvolvedores
TESTES DE INTEGRAÇÃO (Meio):
─────────────────────────────────────
├── Velocidade média (segundos)
├── Contagem moderada (dezenas/centenas)
├── Testam interações de componentes
├── Podem usar bancos de teste
├── Executam no PR e deploy
└── Desenvolvedor ou QA
TESTES E2E (Topo):
─────────────────────────────────────
├── Lentos (minutos)
├── Poucos (dezenas no máximo)
├── Jornadas completas do usuário
├── Browser/app real
├── Executam antes de produção
└── Frequentemente do QA
ANTI-PADRÃO: CONE DE SORVETE
─────────────────────────────────────
Muitos E2E, poucos unitários:
├── Feedback lento
├── Testes flaky
├── Difícil manter
├── Não aponta falhas específicas
└── Inverta a pirâmide!
Quality Gates
Qualidade no CI/CD
QUALITY GATES NO CI/CD
══════════════════════
NO COMMIT:
─────────────────────────────────────
├── Linting passa
├── Testes unitários passam
├── Build sucede
├── Feedback rápido (<5 min)
└── Falha rápida
NO PR:
─────────────────────────────────────
├── Todos testes unitários passam
├── Testes de integração passam
├── Threshold de cobertura atingido
├── Análise estática limpa
├── Scan de segurança limpo
├── Code review aprovado
└── Gate antes do merge
NO MERGE PARA MAIN:
─────────────────────────────────────
├── Suite completa de testes
├── Testes E2E
├── Benchmarks de performance
├── Deploy para staging
├── Smoke tests
└── Pronto para produção
NO DEPLOY EM PRODUÇÃO:
─────────────────────────────────────
├── Smoke tests
├── Health checks
├── Monitoramento ativo
├── Rollback pronto
├── Feature flags para rollout gradual
└── Observar e confirmar
EXEMPLO DE PIPELINE:
─────────────────────────────────────
[Commit] → Lint → Testes Unit → Build
↓
[PR] → Integração → Coverage → Segurança
↓
[Merge] → E2E → Staging → Smoke
↓
[Deploy] → Produção → Monitor → Alertas
Testes Exploratórios
Valor do Teste Manual
TESTES EXPLORATÓRIOS
════════════════════
O QUE É:
─────────────────────────────────────
Simultâneo:
├── Aprendendo sobre o sistema
├── Desenhando testes
├── Executando testes
├── Analisando resultados
└── Criatividade e intuição humana
QUANDO FAZER:
─────────────────────────────────────
├── Novas funcionalidades
├── Fluxos complexos
├── Avaliação de risco
├── Descoberta de edge cases
├── Avaliação de usabilidade
└── Automação não substitui
ABORDAGEM BASEADA EM SESSÃO:
─────────────────────────────────────
Sessão: 45-90 min de exploração focada
Exemplo de charter:
"Explorar o fluxo de checkout
com vários métodos de pagamento
para encontrar edge cases e problemas de usabilidade"
Documentar:
├── Tempo gasto
├── Cenários explorados
├── Issues encontradas
├── Questões levantadas
├── Áreas para automação
└── Relatório breve
COMPLEMENTAR AUTOMAÇÃO:
─────────────────────────────────────
Automação: Cenários conhecidos
Exploração: Cenários desconhecidos
Juntos:
├── Automação para regressão
├── Exploração para descoberta
├── Ambos valiosos
└── Propósitos diferentes
Gestão de Bugs
Rastreamento e Aprendizado
CICLO DE VIDA DO BUG
════════════════════
DESCOBERTA:
─────────────────────────────────────
Bug encontrado por:
├── Teste automatizado
├── Teste manual
├── Monitoramento de produção
├── Relato de usuário
└── Registrar fonte para análise
DOCUMENTAÇÃO:
─────────────────────────────────────
Bom relatório de bug:
├── Título claro
├── Passos para reproduzir
├── Comportamento esperado
├── Comportamento real
├── Detalhes do ambiente
├── Screenshots/logs
└── Suficiente para corrigir sem perguntas
TRIAGEM:
─────────────────────────────────────
Severidade:
├── Crítico: Produção fora do ar
├── Alto: Funcionalidade principal quebrada
├── Médio: Funcionalidade degradada
├── Baixo: Issue menor
└── Priorizar adequadamente
CORREÇÃO + TESTE:
─────────────────────────────────────
├── Corrigir o bug
├── Adicionar teste que o captura
├── Verificar que teste falha antes da correção
├── Verificar que teste passa após correção
├── Bug → Teste permanente
└── Nunca regredir
POST-MORTEM (para bugs significativos):
─────────────────────────────────────
"Como isso aconteceu?"
├── Causa raiz
├── Por que testes não capturaram
├── O que preveniria próxima vez
├── Itens de ação
├── Aprendizado sem culpa
└── Melhoria sistêmica
Integração de QA com GitScrum
Rastreamento de Qualidade
RECURSOS DE QA NO GITSCRUM
══════════════════════════
RASTREAMENTO DE BUGS:
─────────────────────────────────────
Tipo de tarefa: Bug
├── Campo de severidade
├── Passos para reproduzir
├── Ambiente
├── Vinculado à feature
├── Workflow de QA
└── Rastrear até resolução
WORKFLOW DE QA:
─────────────────────────────────────
Workflow customizado para QA:
├── Novo
├── Investigando
├── Não Reproduzido
├── Corrigindo
├── Pronto para Reteste
├── Verificado
├── Fechado
└── Status claro
STATUS DE TESTE:
─────────────────────────────────────
Checklist de tarefa da story:
☐ Testes unitários escritos
☐ Testes de integração escritos
☐ Teste manual feito
☐ Critérios de aceite verificados
☐ Code review passou
└── Definition of Done
DASHBOARD DE QUALIDADE:
─────────────────────────────────────
├── Bugs por severidade
├── Tendência de bugs (subindo/descendo)
├── Tempo médio para correção
├── Cobertura de testes
├── Defeitos escapados
└── Visibilidade de qualidade
Melhores Práticas
Para Quality Assurance
- Shift left — Qualidade desde planejamento, não no final
- Pirâmide de testes — Muitos unitários, poucos E2E
- Automatize regressão — Manual para descoberta
- Quality gates — Enforcement no CI/CD
- Aprenda com bugs — Post-mortems melhoram o sistema
Anti-Padrões
ERROS DE QA:
✗ Testar apenas no final
✗ Teste manual de regressão
✗ Sem testes automatizados
✗ Pirâmide pesada em E2E
✗ QA como guardião (não parceiro)
✗ Ignorar testes falhando
✗ Sem post-mortems
✗ Qualidade é "trabalho do QA"