Por que código sem bugs é o alvo errado
Todo sistema tem defeitos que ninguém encontrou ainda, e o custo de achar o próximo sobe rapidamente conforme os óbvios vão sendo removidos. Passado certo ponto, a hora adicional gasta caçando defeitos vale menos do que a mesma hora gasta tornando as falhas baratas de detectar e corrigir.
O segundo problema é cultural. Quando "sem bugs" é a meta declarada, um bug vira uma falha a ser justificada em vez de uma informação sobre a qual agir, e as pessoas passam a falar menos deles.
Três alvos que funcionam
Sem repetições
Um determinado bug acontece uma única vez. Toda correção deixa uma verificação para trás.
Alcançável, e os ganhos se acumulam.
Encontrado antes dos usuários
Mova a detecção da produção para o pull request.
Mensurável: que fração foi detectada internamente.
Barato de corrigir
O tempo entre a falha e a correção, que depende principalmente da qualidade do relatório de falha.
Por que o primeiro importa mais
Um time que nunca entrega o mesmo bug duas vezes melhora todo mês por construção. Isso exige exatamente um hábito: ao corrigir algo, deixe uma verificação para trás. A maioria dos times corrige o bug, fecha o ticket e não guarda nenhum registro de que aquele comportamento algum dia precisou de proteção.
A medição
Acompanhe a proporção de defeitos encontrados antes do release e o tempo entre a falha e a correção. Os dois se movem quando algo real melhora, e nenhum deles pode ser manipulado escrevendo mais testes — é essa a propriedade útil. Número de testes e percentual de cobertura sobem sob demanda e não dizem quase nada.
Por que os times continuam perseguindo isso mesmo assim
Saber que o alvo está errado não impede as pessoas de mirar nele, e vale entender o motivo, porque ele é estrutural e não ingênuo.
Bugs são visíveis; prevenção não. Um defeito que chegou ao cliente tem ticket, nome e responsável. Os doze que foram pegos antes do release não têm nada, porque nada aconteceu. Assim, o registro visível de um trimestre é uma lista de falhas, e a reação natural a uma lista de falhas é exigir menos falhas.
O contraponto é tornar a prevenção visível também. Informe quantos defeitos foram pegos antes do release ao lado de quantos escaparam. O primeiro número costuma ser muito maior, e vê-lo muda a conversa de "por que continuamos tendo bugs" para "a proporção está mudando", que é a pergunta com uma resposta útil.
Como isso fica na prática
Todo bug ganha uma verificação. As verificações rodam a cada mudança, e não antes dos releases. As falhas chegam em um formato sobre o qual quem vai corrigir consegue agir sem precisar reconstruir a história.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
O dashboard cobre o mesmo terreno para quem não quer uma instalação local, e o conjunto completo de comandos está no repositório da CLI.
O gatilho importa mais do que o mecanismo. Apontá-lo para o seu evento de deploy faz com que toda mudança seja verificada sem que ninguém precise decidir por isso; o GitHub App faz isso pelo dashboard, e um passo do GitHub Actions faz isso de dentro do seu workflow.
Como o TestSprite sustenta os três alvos
Sem repetições é o alvo que ele atende de forma mais direta. O caso que reproduziu um bug fica no projeto e roda a cada mudança, então a correção deixa uma verificação para trás sem que ninguém precise lembrar de escrever uma.
Encontrado antes dos usuários é uma questão de cadência. A cobertura é gerada a partir do seu produto e roda no pull request, o que traz a detecção da produção de volta para a mudança que deu origem ao problema.
Barato de corrigir depende do relatório de falha. Uma execução volta como o que foi tentado, o que a aplicação fez e onde essas duas coisas divergiram, de modo que quem corrige — cada vez mais um agente de código — começa a partir de evidências em vez de reconstruir a história.
Código sem bugs é alcançável em algum caso?
Para sistemas pequenos e formalmente especificados, chega perto, a um custo que quase ninguém consegue justificar. Para um produto comum, não.
Qual é uma taxa de defeitos razoável?
Compare com a sua própria tendência, e não com um número da indústria. A direção importa mais do que o nível.
Testar mais significa menos bugs?
Até certo ponto. Passado ele, testes adicionais acrescentam manutenção sem acrescentar sinal, especialmente se duplicam o que você já cobre.
Devemos acompanhar a contagem de bugs?
Acompanhe os defeitos que escaparam e o tempo até a correção. Contagens brutas sobem quando o registro melhora, o que as torna um sinal ruim.
Qual é o único hábito de maior alavancagem?
Deixe uma verificação para trás toda vez que você corrigir algo. É o único hábito cujos ganhos se acumulam.
Mire em nenhuma repetição, não em zero.
Código sem bugs não é alcançável e distorce as prioridades. Mire em sem repetições, encontrado antes dos usuários e barato de corrigir. Deixe uma verificação para trás depois de cada correção e meça os defeitos que escaparam, em vez da contagem de testes.