7 min leitura • Guide 108 of 877
Coordenando Quality Assurance e Desenvolvimento
Quality assurance funciona melhor quando integrado ao longo do desenvolvimento em vez de tratado como portão final antes do release. GitScrum permite colaboração próxima QA-dev através de visualizações de tarefas compartilhadas, critérios de aceitação estruturados, workflows de teste, e mecanismos de feedback que detectam problemas cedo, reduzem retrabalho, e criam ownership compartilhado de qualidade em todo o time.
Modelos de Integração QA
QA Embutido vs Separado
ESTRUTURAS TIME QA:
┌─────────────────────────────────────────────────────────────┐
│ COMO QA SE INTEGRA COM DESENVOLVIMENTO │
├─────────────────────────────────────────────────────────────┤
│ │
│ QA EMBUTIDO (Recomendado para Agile): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ TIME DEV SCRUM ││
│ │ ┌─────────────────────────────────────────────────────┐ ││
│ │ │ @dev-maria @dev-carlos @dev-ana @qa-tom │ ││
│ │ │ │ ││
│ │ │ QA é membro completo do time: │ ││
│ │ │ • Participa no sprint planning │ ││
│ │ │ • Participa no refinamento │ ││
│ │ │ • Mesmo standup, retro │ ││
│ │ │ • Testa durante sprint, não depois │ ││
│ │ │ │ ││
│ │ │ Ratio: 1 QA para cada 3-5 developers │ ││
│ │ └─────────────────────────────────────────────────────┘ ││
│ │ ││
│ │ Prós: ││
│ │ • Loops de feedback mais rápidos ││
│ │ • QA tem contexto de requisitos de negócio ││
│ │ • Bugs corrigidos mesmo sprint que são encontrados ││
│ │ • Qualidade se torna responsabilidade do time ││
│ │ ││
│ │ Contras: ││
│ │ • QA pode ser pressionado por deadline do sprint ││
│ │ • Menos compartilhamento de conhecimento QA-para-QA ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TIME QA SEPARADO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ BOARD TIME DEV BOARD TIME QA ││
│ │ ┌─────────────┐ ┌─────────────┐ ││
│ │ │ Tarefas dev │ ──► │ Fila QA │ ││
│ │ │ │ Passar│ │ ││
│ │ │ │ p/ QA │ │ ││
│ │ └─────────────┘ └─────────────┘ ││
│ │ ││
│ │ QA testa depois que dev completa: ││
│ │ • Handoff quando "Dev Pronto" ││
│ │ • QA testa em fase separada ││
│ │ • Bugs voltam ao board dev ││
│ │ ││
│ │ Prós: ││
│ │ • Especialização e expertise QA ││
│ │ • Testing objetivo (não influenciado por dev) ││
│ │ • Melhor para indústrias compliance/reguladas ││
│ │ ││
│ │ Contras: ││
│ │ • Delays de handoff ││
│ │ • Mentalidade "jogar por cima do muro" ││
│ │ • Bugs encontrados mais tarde custam mais corrigir ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Design de Workflow
Estrutura Board Compartilhado
BOARD INTEGRADO QA-DEV:
┌─────────────────────────────────────────────────────────────┐
│ COLUNAS WORKFLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┬──────────┬──────────┬──────────┬──────────────┐│
│ │ Backlog │ Em Dev │ Em QA │ Em UAT │ Pronto ││
│ ├─────────┼──────────┼──────────┼──────────┼──────────────┤│
│ │ │ WIP: 3 │ WIP: 2 │ │ ││
│ │ ┌─────┐ │ ┌─────┐ │ ┌─────┐ │ ┌─────┐ │ ┌─────┐ ││
│ │ │Tarefa1││ │Tarefa3││ │Tarefa5││ │Tarefa7││ │Tarefa9│ ││
│ │ └─────┘ │ │@maria│ │ │@tom │ │ │@client│ │ │ ✓ │ ││
│ │ ┌─────┐ │ └─────┘ │ └─────┘ │ └─────┘ │ └─────┘ ││
│ │ │Tarefa2││ ┌─────┐ │ ┌─────┐ │ │ ┌─────┐ ││
│ │ └─────┘ │ │Tarefa4││ │Tarefa6││ │ │Tarefa10│ ││
│ │ │ │@carlos│ │ │@tom │ │ │ │ ✓ │ ││
│ │ │ └─────┘ │ └─────┘ │ │ └─────┘ ││
│ │ │ │ │ │ ││
│ └─────────┴──────────┴──────────┴──────────┴──────────────┘│
│ │
│ LIMITES WIP: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Coluna Em QA tem limite WIP = pessoas QA × 2 ││
│ │ ││
│ │ Por quê: Previne gargalo QA, mantém fluxo movendo ││
│ │ ││
│ │ Quando QA está cheio: ││
│ │ • Devs não podem mover mais para QA (bloqueados) ││
│ │ • Sinal: Ajudar QA ou desacelerar novo dev ││
│ │ • Considerar: Developer ajuda com testing ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Integração Critérios Aceitação
Escrevendo Critérios Testáveis
MELHORES PRÁTICAS CRITÉRIOS ACEITAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ CRITÉRIOS QUE QA PODE REALMENTE TESTAR │
├─────────────────────────────────────────────────────────────┤
│ │
│ FORMATO: Dado-Quando-Então │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Tarefa: Reset Senha Usuário ││
│ │ ││
│ │ Critérios Aceitação: ││
│ │ ││
│ │ ✅ TESTÁVEL: ││
│ │ CA1: Dado usuário na página login ││
│ │ Quando clica "Esqueci Senha" ││
│ │ Então formulário input email é mostrado ││
│ │ ││
│ │ CA2: Dado email válido inserido ││
│ │ Quando envia formulário ││
│ │ Então email reset enviado em 30 segundos ││
│ │ E mensagem sucesso mostrada ││
│ │ ││
│ │ CA3: Dado formato email inválido ││
│ │ Quando envia formulário ││
│ │ Então erro validação mostrado ││
│ │ E nenhum email enviado ││
│ │ ││
│ │ ❌ VAGO (Não fazer isso): ││
│ │ • "Reset senha deveria funcionar" ││
│ │ • "Mensagens erro amigáveis" ││
│ │ • "Entrega email rápida" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ INCLUIR CASOS BORDA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CA4: Dado email não existe no sistema ││
│ │ Quando envia formulário ││
│ │ Então mensagem sucesso genérica mostrada ││
│ │ (segurança: não revelar se email existe) ││
│ │ ││
│ │ CA5: Dado reset solicitado duas vezes em 5 minutos ││
│ │ Quando envia novamente ││
│ │ Então mensagem limite rate mostrada ││
│ │ E nenhum segundo email enviado ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Gestão de Bugs
Workflow de Bug
PROCESSO TRATAMENTO BUGS:
┌─────────────────────────────────────────────────────────────┐
│ DA DESCOBERTA ATÉ O FECHAMENTO │
├─────────────────────────────────────────────────────────────┤
│ │
│ TEMPLATE TAREFA BUG: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Título: [Componente] Descrição breve ││
│ │ ││
│ │ **Ambiente:** ││
│ │ Navegador: Chrome 120 ││
│ │ SO: Windows 11 ││
│ │ Ambiente teste: staging.app.com ││
│ │ ││
│ │ **Passos para Reproduzir:** ││
│ │ 1. Navegar para /dashboard ││
│ │ 2. Clicar botão "Exportar" ││
│ │ 3. Selecionar formato "CSV" ││
│ │ 4. Clicar "Download" ││
│ │ ││
│ │ **Resultado Esperado:** ││
│ │ Arquivo CSV baixa com dados ││
│ │ ││
│ │ **Resultado Atual:** ││
│ │ Mensagem erro: "Exportação falhou" ││
│ │ ││
│ │ **Labels:** type/bug, severity/high, component/export ││
│ │ **Vinculado a:** Tarefa #123 (Feature exportação) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘