Checklist de Refinamento Técnico (Three Amigos): Como Prevenir Bugs Antes do Código
Se você trabalha na área de garantia da qualidade, certamente já presenciou um dos maiores clássicos dos projetos de software: o desalinhamento entre a regra de negócio definida pelo PO e a implementação feita pelo time de desenvolvimento.
A dinâmica dos Three Amigos (PO, Dev e QA) existe para evitar exatamente isso. Quando a reunião de refinamento técnico é pulada ou feita de forma superficial, o desenvolvedor costuma tomar decisões técnicas por conta própria ao encontrar uma limitação no código ou na infraestrutura — e o resultado é um bug funcional que só estoura na fase final de testes ou em produção.
Neste artigo do QA Prática, apresentamos um Checklist Prático de Refinamento Técnico e um estudo de caso real mostrando como a falta de alinhamento gera retrabalho e desperdício de tempo da sprint.
💣 Estudo de Caso Real: A Regra do Empréstimo x Manutenção do Banco
Para entender o impacto de um refinamento técnico mal executado, analise o seguinte cenário real de uma funcionalidade de concessão de crédito:
📌 A Regra de Negócio (O que o PO definiu):
"O cliente poderá solicitar um empréstimo pessoal no aplicativo a qualquer hora do dia. O sistema deve validar os dados com o parceiro bancário e, se aprovado, depositar o valor imediatamente na conta."
O Problema da Limitação Técnica (O que o Dev enfrentou):
Ao iniciar o desenvolvimento, o desenvolvedor descobriu uma limitação técnica relevante: o banco de dados do parceiro bancário passa por uma janela de manutenção diária obrigatoriamente à meia-noite, tornando a API de consulta indisponível por 30 minutos.
O Desalinhamento (O que o Dev fez por conta própria):
Em vez de chamar o PO para alinhar a regra de negócio diante da limitação, o desenvolvedor tomou uma decisão isolada na arquitetura: colocou um tratamento simples no código que retorna uma mensagem genérica de erro ("Erro 500: Erro interno no servidor") caso o cliente tente solicitar o empréstimo à meia-noite.
A Atuação do QA e as Consequências:
- Impacto no Negócio: Clientes frustrados achando que o aplicativo do banco está quebrado, gerando chamados no suporte e abandono do fluxo.
- Retrabalho na Sprint: O QA identificou o comportamento nos testes, abriu o bug e a tarefa teve que ser retrabalhada para criar uma mensagem de alerta amigável e um fluxo de agendamento — algo que poderia ter sido definido em 5 minutos na reunião dos Three Amigos antes da primeira linha de código ser escrita.
📋 Checklist Prático de Refinamento Técnico (Three Amigos)
Para evitar que a sua equipe passe por situações semelhantes, utilize este checklist nas reuniões de refinamento antes de iniciar qualquer desenvolvimento:
| Categoria | Item a Validar no Refinamento | Ação do QA na Reunião |
|---|---|---|
| 1. Regras de Negócio | Objetivo claro, critérios de aceite e fluxos de exceção definidos. | Perguntar: "O que acontece quando o fluxo principal falha?" |
| 2. Limitações Técnicas | Janelas de manutenção, limites de APIs parceiras, timeouts e concorrência. | Questionar os Devs: "Existe alguma limitação de infraestrutura ou serviço externo nesse horário/recurso?" |
| 3. UX / UX State | Estados de Loading, Tela Vazia (Empty State), Mensagens de Erro e Alertas. | Garantir que mensagens de erro sejam amigáveis e orientem o usuário. |
| 4. Testabilidade e Massa | Identificadores na tela (data-testid), mocks de APIs e massa no BD. |
Acordar com o Dev a criação de seletores para automação do teste. |
💡 Como aplicar no dia a dia da equipe de QA
- Analise a estória com antecedência: Leia o card antes da reunião de refinamento e anote as lacunas de especificação.
- Não aceite suposições técnicas isoladas: Se o time de desenvolvimento identificar uma limitação técnica, exija que a regra de negócio seja reajustada junto ao PO.
- Documente as exceções no card: Atualize os critérios de aceite com todos os cenários alternativos e limites identificados na conversa.
"Identificar uma limitação técnica e ajustar a regra de negócio no papel custa zero. Corrigir o mesmo problema depois do código pronto custa horas de retrabalho do time."
🔗 Conteúdos Relacionados do QA Prática
🧠 Conclusão
A cultura de **Shift-Left** consiste em antecipar os testes para o momento da concepção do requisito. Quando PO, Dev e QA se alinham na reunião de Three Amigos, o time evita surpresas técnicas, melhora a experiência do usuário e garante entregas muito mais estáveis em produção.
Você já passou por alguma situação em que o desenvolvedor mudou a regra de negócio por conta de uma limitação técnica? Conte como foi a experiência nos comentários!
Comentários
Postar um comentário