Ideias, tutoriais e novidades da nossa equipe.
A maioria das equipes não é lenta para decidir quais bugs importam; é lenta em tudo o que fica em volta da decisão. Um fluxo de triagem de bugs que elimina a navegação em vez de pedir que você pense mais rápido.
O que separa um relatório de bug que é corrigido de um que é fechado como «não reproduzível»: estrutura, contexto e um checklist prático.
Uma rodada de UAT produz uma planilha de sessenta linhas, metade delas inúteis. O problema raramente são os testers. É o canal de relatório, que joga fora as evidências exatamente no momento em que elas existem.
«Não reproduzível» não é uma propriedade do bug. É uma afirmação sobre a diferença entre duas máquinas. Existem só umas oito diferenças desse tipo, e cada uma deixa uma assinatura própria.
Toda equipe escreve um modelo de relatório de bug. A maioria é ignorada em um mês, porque pede às pessoas um trabalho que o navegador poderia fazer por elas. Aqui está um modelo que vale a pena manter — e o argumento para apagar três quartos dele.
Separar relatórios de tarefas é a pequena decisão estrutural que impede a caixa de entrada de bugs de virar um cemitério — e transforma relatórios duplicados no seu melhor recurso de depuração.