Como convencer os membros da equipe da existência de um "mandelbug"

Estamos desenvolvendo um aplicativo; inclui uma biblioteca desenvolvida por outro codificador, esta biblioteca se comunica com o servidor por meio de várias conexões de rede e envolve vários threads trabalhando juntos. O código do lado do servidor é bastante complicado e não temos acesso ao código fonte.

Recentemente, descobri um bug de mandelbug que causava um travamento de aplicativo. Eu poderia reproduzi-lo uma vez e ter um rastreamento de pilha, então abri um relatório de erro. O bug em si é fácil de corrigir (exceção da Web não capturada em um dos threads de segundo plano, que faz com que o CLR encerre o programa).

O problema é que o desenvolvedor está se recusando a corrigir o erro, porque "ele não está convencido de que existe". Infelizmente para mim, o chefe está do lado dele e diz que esse bug não pode ser corrigido, a menos que eu faça um "sólido caso de teste" para provar a existência do bug e faça um teste de unidade para verificar se ele desapareceu. O que é basicamente impossível devido à natureza do bug.

Algum conselho?

Se possível, pode levar algum tempo para verificar se esse defeito pode ser reproduzido colocando algum sono ou bloqueio no código do aplicativo. Mas não gaste muito tempo. Como esse problema ocorre devido à multithread (e também como você observou), sua ocorrência será rara.

Meu conselho é não suar muito com isso. Continue seu trabalho. Sempre que você encontrar esse travamento, atualize seu relatório de erros com o rastreamento de pilha, dizendo que essa é uma ocorrência repetida e alterando o proprietário para desenvolvedor da biblioteca. Deixe a gerência / líder decidir se conserta ou não, dependendo da frequência.

Tente também entender a mentalidade do desenvolvedor. Você disse "exceção da web não capturada". O desenvolvedor nesse estágio pode não ter certeza de quais serão os outros efeitos dessa captura . Então ele / ela pode estar relutante em tocar no código.

Então, pelos seus comentários mais ou menos esclarecedores, entendi o seguinte:

Você tem certeza de que há apenas uma manipulação de exceção adicional simples ausente e já sabe qual linha de código na lib é problemática e como a lib pode ser corrigida.

Por que, então, você não adiciona as poucas linhas de código ausentes à lib sozinho, pede à equipe para testar a lib com essas mudanças? Certifique-se de que é uma alteração de baixo risco, fácil de entender pelo desenvolvedor responsável pela biblioteca. A pior coisa que pode acontecer é que alguém precise reverter essa alteração no seu VCS se a sua correção causar algum novo comportamento inesperado.

A maioria das pessoas é mais fácil de convencer quando o trabalho já está concluído. Além disso, eles reagem melhor com "aqui está uma solução aprimorada", ao contrário de "este código está errado, corrija-o de alguma forma".

EDIT: quando o desenvolvedor ainda se recusa a adicionar essa alteração, a melhor opção é tentar fazer com que o código problemático funcione dentro de um equipamento de teste isolado onde você simula o erro de rede. Trabalhar efetivamente com o código legado descreve muitas técnicas sobre como lidar com esse tipo de problemas. Por exemplo, você pode criar uma versão de teste da biblioteca, incluindo apenas os módulos e funções problemáticos, e criar um "ambiente simulado" ao redor dela, onde é possível simular a "exceção de rede" sob condições controladas. Isso pode parecer muito esforço à primeira vista, mas quando você tiver um ambiente assim, poderá adicionar muitos testes adicionais (e acho que isso fará sentido, pois quando o autor da lib se recusa a adicionar a falta manipulação de exceção em um só lugar,

Para um bug como esse, o teste de fuzz automatizado (também chamado de teste aleatório) pode ser útil na tentativa de reproduzi-lo. Isso automatiza o processo de encontrar o bug aleatoriamente um conjunto fixo de parâmetros (ou entradas) na coisa que você está testando. A cada execução do teste, os parâmetros são registrados em um arquivo de log, incluindo registros de data e hora, etc., para que, quando ocorrer uma falha, você possa (teoricamente) apenas repetir o teste, usando os mesmos parâmetros, para reproduzi-lo.

Desde a sua automatização, o processo de teste pode executar muitos testes em um curto período de tempo. Geralmente, ele pode ser deixado para funcionar da noite para o dia e, pela manhã, você pode verificar um arquivo de log para ver se ele reproduziu a falha.

O advogado do diabo sugere outro caminho.

O outro desenvolvedor declarou, sem rodeios, que não há nenhum bug lá.

Você pode encontrar uma maneira de estressar o inferno do bug supostamente inexistente e fazer com que ele trave com muito mais frequência?

O rastreamento de pilha é uma evidência clara de que o bug existe ou, pelo menos, existia em uma determinada construção. O que você não tem é evidência de que o bug foi corrigido. Eles são tolos em ignorá-lo. Eu tive bugs "impossíveis de reproduzir" depois de centenas de milhares de tentativas automatizadas em vários sistemas que disparavam todas as vezes no sistema de um cliente.

Eu recebo alguns erros assim por ano, a maioria sem o benefício de um rastreamento de pilha. Em quase todos os casos, mesmo que eu não pudesse reproduzi-lo de antemão, eu poderia facilmente fazer um teste automatizado para ele depois de corrigido.

Por exemplo, alguns meses atrás, corrigi um bug que só ocorria quando o usuário digitava mais de 96 palavras por minuto. Antes de consertar, tudo que eu sabia era que o bug acontecia "às vezes". Nunca me ocorreria escrever um teste de unidade para digitação rápida. No entanto, depois que eu conheci a causa raiz, fazer um teste foi trivial.

Mesmo nos raros casos em que um bug não pode ser reproduzido mesmo depois de corrigido, você pode fechá-lo por inspeção de código.