É razoável insistir em reproduzir todos os defeitos antes de diagnosticá-los e corrigi-los?

Eu trabalho para uma empresa de produtos de software. Temos grandes clientes corporativos que implementam nosso produto e fornecemos suporte a eles. Por exemplo, se houver um defeito, fornecemos patches, etc. Em outras palavras, é uma configuração bastante típica.

Recentemente, um ticket foi emitido e atribuído a mim referente a uma exceção encontrada por um cliente em um arquivo de log relacionado ao acesso simultâneo ao banco de dados em uma implementação em cluster de nosso produto. Portanto, a configuração específica desse cliente pode muito bem ser crítica na ocorrência desse bug. Tudo o que recebemos do cliente foi o arquivo de log.

A abordagem que propus à minha equipe foi tentar reproduzir o bug em uma configuração semelhante à do cliente e obter um log comparável. No entanto, eles discordam da minha abordagem, dizendo que não preciso reproduzir o bug, pois consome muito tempo e exigirá a simulação de um cluster de servidores nas VMs. Minha equipe sugere que eu simplesmente "siga o código" para ver onde está o código inseguro de thread e / ou transação e coloque a mudança em funcionamento em um desenvolvimento local simples, que não é uma implementação de cluster como o ambiente no qual a ocorrência do bug se origina.

Para mim, elaborar um plano abstrato (código do programa) em vez de uma manifestação visível e tangível (reprodução em tempo de execução) parece difícil, então eu queria fazer uma pergunta geral:

É razoável insistir em reproduzir todos os defeitos e depurá-los antes de diagnosticá-los e corrigi-los?

Ou:

Se eu sou um desenvolvedor sênior, devo ler um código multithread e criar uma imagem mental do que ele faz em todos os cenários de casos de uso, em vez de exigir a execução do aplicativo, testar diferentes cenários de casos de uso de maneira prática e percorrer as código linha por linha? Ou sou um desenvolvedor ruim por exigir esse tipo de ambiente de trabalho?

A depuração para mariquinhas?

Na minha opinião, qualquer correção enviada em resposta a um ticket de incidente deve ser testada em um ambiente simulado para estar o mais próximo possível do ambiente original. De que outra forma você pode saber que isso realmente solucionará o problema? É como lançar um novo modelo de veículo sem colidir com um manequim para demonstrar que os airbags realmente funcionam.

Por último, mas não menos importante, se você concorda comigo:

Como devo conversar com minha equipe para convencê-los de que minha abordagem é razoável, conservadora e mais à prova de balas?

É razoável insistir em reproduzir todos os defeitos e depurá-los antes de diagnosticá-los e corrigi-los?

Você deve fazer o seu melhor esforço. Sei que, às vezes, existem condições e ambientes tão complexos que não podem ser reproduzidos exatamente , mas você certamente deve tentar se puder.

Se você nunca reproduziu o bug e o viu por si mesmo, como pode ter 100% de certeza de que realmente o corrigiu? Talvez sua correção proposta introduza algum outro bug sutil que não se manifestará, a menos que você tente reproduzir o defeito original.

Se eu sou um desenvolvedor sênior, devo ler um código (multithread) e criar uma imagem mental do que ele faz em todos os cenários de casos de uso, em vez de exigir a execução do aplicativo, testar diferentes cenários de casos de uso e seguir adiante o código linha por linha? Ou sou um desenvolvedor ruim por exigir esse tipo de ambiente de trabalho? A depuração para mariquinhas?

Eu não confiaria em alguém que executa o código "na cabeça", se essa for a única abordagem. É um bom lugar para começar . Reproduzindo o bug, corrigindo-o e demonstrando que a solução impede que o bug se repita - é aí que deve terminar .

Como devo conversar com minha equipe para convencê-los de que minha abordagem é razoável, conservadora e mais à prova de balas?

Porque se eles nunca reproduziram o bug, eles não podem ter certeza de que ele foi corrigido. E se o cliente voltar e reclamar que o bug ainda está lá, isso não é uma coisa boa. Afinal, eles estão pagando um grande $$$ (suponho) para lidar com esse problema.

Se você não conseguiu resolver o problema corretamente, quebrou a fé com o cliente (até certo ponto) e, se houver concorrentes em seu mercado, eles podem não ser seu cliente.

Como eles pretendem verificar se o bug em questão foi corrigido? Eles querem enviar código não testado para o usuário e deixá-lo descobrir? Qualquer configuração de teste que nunca foi mostrada para reproduzir o erro não pode ser usada para mostrar a ausência do erro. Você certamente não precisa reproduzir todo o ambiente do cliente, mas precisa o suficiente para reproduzir o erro.

Eu não acho razoável tentar reproduzir todos os erros antes de corrigir. No entanto, se você tentar reproduzi-lo e não puder, torna-se mais uma decisão de negócios sobre se os remendos cegos são ou não uma boa idéia.

Idealmente, você deseja reproduzir cada bug para que, no mínimo, possa testar se ele foi corrigido.

Mas ... Isso nem sempre é possível ou mesmo fisicamente possível. Especialmente com o software do tipo 'corporativo', onde cada instalação é única. Há também a avaliação de custo / benefício. Algumas horas examinando o código e fazendo algumas suposições informadas sobre um problema não crítico podem custar muito menos do que ter uma equipe de suporte técnico passando semanas tentando configurar e duplicar o ambiente de um cliente exatamente na esperança de poder duplicar o problema. Na época em que eu trabalhava no mundo 'Enterprise', muitas vezes simplesmente copiávamos os codificadores e os corrigiam no local, porque não havia como duplicar a configuração do cliente.

Portanto, duplique quando puder, mas se não puder, aproveite seu conhecimento do sistema e tente identificar o culpado no código.

Eu não acho que você deva tornar um erro de reprodução um requisito para analisar o bug. Como você mencionou, existem várias maneiras de depurar o problema - e você deve usá-las. Você deve considerar-se com sorte porque eles foram capazes de fornecer um arquivo de log! Se você ou alguém da sua empresa conseguir reproduzir o bug, ótimo! Caso contrário, você ainda deve tentar analisar os logs e encontrar as circunstâncias nas quais o erro ocorreu. Pode ser possível, como sugeriram seus colegas, ler o código, descobrir quais condições o bug poderia acontecer e tentar recriar o cenário por conta própria.

No entanto, não libere a correção real não testada. Qualquer alteração feita deve passar pela rotina padrão de desenvolvimento, teste de controle de qualidade e teste de integração. Pode ser difícil de testar - você mencionou o código multithread, que é notoriamente difícil de depurar. É aqui que concordo com sua abordagem para criar uma configuração ou ambiente de teste. Se você encontrou um problema no código, deve ser muito mais simples criar o ambiente, reproduzir o problema e testar a correção.

Para mim, isso é menos um problema de depuração e mais um problema de serviço ao cliente. Você recebeu um relatório de bug de um cliente; você tem a responsabilidade de fazer a devida diligência para encontrar o problema e corrigi-lo.

Na minha opinião ... como tomador de decisão, você deve ser capaz de justificar sua posição. Se o objetivo do departamento de suporte da 3ª linha for corrigir bugs no menor tempo possível com o esforço aceitável do cliente, qualquer abordagem deve estar em conformidade com esse objetivo. Além disso, se for possível provar que a abordagem fornece os resultados mais rápidos esperados, não deve haver problema em convencer a equipe.

Tendo trabalhado no suporte, sempre esperei razoavelmente que o cliente fosse capaz de fornecer algum "script" de ações que eles executaram para reproduzir consistentemente o erro e, se não consistentemente, exemplos de candidatos que o produziram.

Se eu fosse novo no sistema e não tivesse experiência com o código, meus primeiros passos seriam tentar identificar as possíveis fontes do erro. Pode ser que o registro seja insuficiente para identificar um código candidato. Dependendo do cliente, posso estar inclinado a fornecer uma versão de depuração para que eles possam devolver arquivos de log que fornecem mais pistas sobre a posição do código incorreto.

Se eu conseguir identificar rapidamente o bloco de código, o mapeamento visual do fluxo pode ser suficiente para identificar o código. Caso contrário, a simulação baseada em teste de unidade pode ser suficiente. Pode ser que a configuração de um ambiente de replicação do cliente leve menos tempo, especialmente se houver uma grande replicabilidade do problema.

Acho que você pode achar que sua abordagem deve ser uma combinação das soluções propostas e que saber quando sair de uma e seguir para a próxima é essencial para realizar o trabalho com eficiência.

Tenho certeza de que a equipe apoiará a noção de que, se houver uma chance de sua solução encontrar o bug mais rapidamente, fornecendo um prazo adequado para provar que não afetará muito o tempo necessário para corrigir o bug, o que ocorrer rota que você toma.

É razoável insistir em reproduzir todos os defeitos e depurá-los antes de diagnosticá-los e corrigi-los?

Eu digo que sim, com algumas ressalvas.

• Acho que é bom ler o código e tentar encontrar lugares que parecem problemáticos. Crie um patch e envie-o ao cliente para ver se isso resolve o problema. Se essa abordagem continuar falhando, talvez seja necessário investigar outras opções. Lembre-se de que, embora você possa estar corrigindo um bug, pode não ser o bug relatado.
• Se você não conseguir reproduzi-lo dentro do razoável e não encontrar sinalizadores vermelhos no código, isso poderá exigir uma coordenação mais próxima com o cliente. Eu já voei para sites de clientes antes para fazer a depuração no site. Não é o melhor ambiente para desenvolvedor, mas às vezes, se o problema for ambiental, encontrar a causa exata será mais fácil quando você puder reproduzi-lo de forma consistente.

Estive do lado do cliente na tabela neste cenário. Eu estava trabalhando em um escritório do governo dos EUA que usava um cluster de banco de dados Oracle incrivelmente grande (vários terabytes de dados e processando milhões de registros por dia).

Tivemos um problema estranho que era muito fácil de reproduzir. Relatamos o bug para a Oracle e voltamos com eles por semanas, enviando logs para eles. Eles disseram que não foram capazes de reproduzir o problema, mas nos enviaram alguns patches que o esperado poderia resolver. Nenhum deles fez.

Eventualmente, eles levaram alguns desenvolvedores para o nosso local para depurar o problema no local. E foi aí que a causa raiz do bug foi encontrada e um patch posterior resolveu o problema corretamente.

Se você não é positivo sobre o problema, não pode ser positivo sobre a solução. Saber reproduzir o problema de maneira confiável em pelo menos uma situação de caso de teste permite provar que você sabe como causar o erro e, portanto, também provar que, por outro lado, o problema foi resolvido devido à falta subsequente de erro no mesmo caso de teste após aplicar a correção.

Dito isso, condições de corrida, problemas de concorrência e outros bugs "não determinísticos" estão entre os mais difíceis para um desenvolvedor identificar dessa maneira, porque ocorrem com pouca frequência em um sistema com carga mais alta e mais complexidade do que a cópia de qualquer desenvolvedor. o programa e desaparecem quando a tarefa é executada novamente no mesmo sistema posteriormente.

Na maioria das vezes, o que originalmente parece um bug aleatório acaba tendo uma causa determinística que resulta na reprodutibilidade determinística do bug quando você sabe como. Os que desafiam isso, os verdadeiros Heisenbugs (erros aparentemente aleatórios que desaparecem ao tentar testá-los em um ambiente estéril e monitorado), são 99,9% relacionados ao tempo e, depois que você entende isso, seu caminho a seguir se torna mais claro; procure por coisas que poderiam falhar se alguma outra coisa contivesse uma palavra durante a execução do código e, quando você encontrar essa vulnerabilidade, tente explorá-la em um teste para ver se exibe o comportamento que você está tentando reproduzir.

Geralmente, é necessária uma quantidade significativa de inspeção detalhada do código nessas situações; você precisa examinar o código, abandonando quaisquer noções preconcebidas de como o código deve se comportar e imaginar cenários nos quais ele pode falhar da maneira que seu cliente observou. Para cada cenário, tente desenvolver um teste que possa ser executado com eficiência no seu ambiente de teste automatizado atual (ou seja, sem precisar de uma nova pilha de VMs apenas para esse teste), que provaria ou refutaria que o código se comporta conforme o esperado ( que, dependendo do que você esperava, provaria ou refutaria que esse código é uma possível causa dos problemas dos clientes). Este é o método científico para engenheiros de software; observe, faça hipóteses, teste, reflita, repita.

É razoável insistir em reproduzir todos os defeitos e depurá-los antes de diagnosticá-los e corrigi-los?

Não, definitivamente não é. Isso seria uma política estúpida.

O problema que vejo com sua pergunta e sua proposta é que eles não fazem distinção entre

• relatório de erros
• falhas ( erros )
• bugs (também chamados de erros )

Um relatório de bug é uma comunicação sobre um bug. Diz que alguém acha que algo está errado. Pode ou não ser específico sobre o que deveria estar errado.

Um relatório de erro é evidência de uma falha.

Uma falha é um incidente de algo dando errado. Um mau funcionamento específico, mas não necessariamente com pistas sobre o que pode ter causado.

Uma falha pode ser causada por um bug.

Um bug é uma causa de falhas; algo que pode (em princípio) ser alterado para impedir que as falhas causadas ocorram no futuro.

Às vezes, quando um bug é relatado, a causa é imediatamente clara. Nesse caso, reproduzir o erro não faria sentido. Em outros momentos, a causa não é clara: o relatório de erro não descreve nenhuma falha específica, ou descreve, mas a falha é de tal ordem que não fornece uma pista sobre qual pode ser a causa. Nesses casos, sinto que o seu conselho é justificado - mas nem sempre: não se insiste em travar um segundo foguete espacial de US $ 370 milhões antes de aceitar investigar o que causou o travamento do primeiro (um bug específico no software de controle).

E também existem todos os tipos de casos no meio; por exemplo, se um relatório de bug não provar, mas apenas sugerir que um problema em potencial que você já estava ciente pode desempenhar um papel, isso pode ser um incentivo suficiente para você dar uma olhada mais de perto.

Portanto, embora insistir na reprodutibilidade seja prudente para os casos mais difíceis, não é aconselhável aplicá-la como uma política estrita.

Como em todo o resto no desenvolvimento de software, a resposta correta é um compromisso.

Em teoria, você nunca deve tentar corrigir um erro se não puder provar que ele existe. Fazer isso pode fazer com que você faça alterações desnecessárias no seu código que não resolvem nada. E provar isso significa reproduzi-lo primeiro, depois criar e aplicar uma correção e depois demonstrar que isso não acontece mais. Seu intestino aqui está direcionando você na direção certa - se você quer ter certeza de que resolveu o problema do seu cliente, precisa saber o que o causou em primeiro lugar.

Na prática, isso nem sempre é possível. Talvez o bug ocorra apenas em grandes grupos, com dezenas de usuários acessando simultaneamente seu código. Talvez haja uma combinação específica de operações de dados em conjuntos específicos de dados que acionam o bug e você não tem idéia do que é isso. Talvez seu cliente tenha executado o programa interativamente sem interrupções por centenas de horas antes que o bug se manifestasse.

Em qualquer um desses casos, há uma grande chance de que seu departamento não tenha tempo ou dinheiro para reproduzir o bug antes de começar o trabalho. Em muitos casos, é muito mais óbvio para você, o desenvolvedor, que há um bug no código que indica a situação correta. Depois de diagnosticar o problema, você poderá voltar e reproduzi-lo. Não é o ideal, mas, ao mesmo tempo, parte do seu trabalho como desenvolvedor sênior é saber ler e interpretar códigos, em parte para localizar esse tipo de erro oculto.

Na minha opinião, você está se concentrando na parte errada da pergunta. E se você não conseguir reproduzir o bug em questão? Nada é mais frustrante para um cliente do que ouvir "sim, sabemos que você travou o programa, mas não podemos reproduzi-lo, por isso não é um bug". Quando seu cliente ouve isso, ele o interpreta como "sabemos que nosso software é defeituoso, mas não podemos nos dar ao trabalho de consertar e consertar os erros, basta cruzar os dedos". Se é melhor fechar um bug relatado como "não reproduzível" ou fechá-lo como "não reproduzível, mas fizemos algumas alterações razoáveis ​​para tentar melhorar a estabilidade"?

A menos que o erro seja evidente, óbvio e trivial, com uma mensagem de erro muito específica etc., muitas vezes é muito difícil corrigir um erro se o usuário ou o mantenedor não conseguir replicá-lo.

Além disso, como você provaria a eles que o bug foi corrigido se você não pode replicar as etapas?

O problema com o seu caso é que o usuário também não sabe como ocorreu o erro, ou seja, em que tela de execução de operação. Eles simplesmente têm o log.

Eu acho que seu ponto de vista é razoável. Se você tivesse poderes psíquicos , provavelmente não estaria trabalhando por um salário.

Acho que você deveria dizer aos seus chefes que, sem conseguir replicar o erro, levaria um tempo desconhecido para descobrir, e não há garantia de que você irá.

O problema será quando algum colega de trabalho encontrar o bug por pura sorte e corrigi-lo.

Vamos levá-lo ao extremo e supor que você encontrou o bug muito antes: no seu código, enquanto você o escrevia. Então você não teria nenhum escrúpulo em corrigi-lo ali mesmo - você vê uma falha lógica no código que acabou de escrever, mas não faz o que você queria. Você não sentiria a necessidade de configurar um ambiente inteiro para mostrar que é realmente um bug.

Agora chega um relatório de erro. Existem várias coisas que você pode fazer. Uma delas é voltar ao código e relê-lo. Agora, suponha que nesta segunda leitura, você encontre imediatamente o erro no código - ele simplesmente não faz o que você pretendia que ele fizesse e não percebeu quando o escreveu. E , explica perfeitamente o bug que acabou de chegar! Você faz a correção. Você levou vinte minutos.

Isso corrigiu o erro que causou o relatório? Você não pode ter 100% de certeza (pode haver dois erros causando a mesma coisa), mas provavelmente ocorreu.

Outra coisa que você pode fazer é reproduzir a configuração do cliente da melhor maneira possível (alguns dias de trabalho) e, eventualmente, reproduzir o bug. Em muitos casos, existem problemas de tempo e simultaneidade que significam que você não pode reproduzir o erro, mas pode tentar bastante tempo e, às vezes, ver a mesma coisa acontecer. Agora você inicia a depuração, encontra o erro no código, coloca-o no ambiente e tenta várias vezes novamente. Você não vê mais o erro.

Isso corrigiu o erro que causou o relatório? Você ainda não pode ter 100% de certeza - um, você pode realmente ter visto um bug completamente diferente do que o cliente fez, dois, talvez você não tenha experimentado o suficiente e três, talvez a configuração ainda seja um pouco diferente e seja fixo neste sistema, mas não no cliente.

Portanto, é impossível ter certeza de qualquer maneira. Mas o primeiro método é muito mais rápido (você pode fornecer um patch ao cliente mais rápido também), é muito mais barato e, se você encontrar um bug de codificação claro que explica o sintoma, é mais provável que encontre o problema também.

Então depende. Se for barato configurar um ambiente de teste (ou melhor: um teste automatizado que mostre o problema), faça isso. Mas se é caro e / ou as circunstâncias em que o erro mostra são imprevisíveis, é sempre melhor tentar encontrar o erro lendo o código primeiro.

Lendo a pergunta, não vejo nenhuma oposição fundamental entre sua posição e a de sua equipe.

• Sim, você deve se esforçar ao máximo para reproduzir o problema que ocorre na configuração do cliente. Porém, o melhor esforço significa que você deve definir uma caixa de tempo para isso e talvez não haja dados suficientes no log para reproduzir o problema.

  Nesse caso, tudo depende do relacionamento com esse cliente. Pode acontecer que você não tenha mais nada dele, pois você pode enviar um desenvolvedor no local com ferramentas de diagnóstico e capacidade de executá-las no sistema com falha. Normalmente, estamos no meio do caminho e, se os dados iniciais não forem suficientes, existem maneiras de obter mais.

• Sim, um desenvolvedor sênior deve poder ler o código e provavelmente encontrará o motivo do problema após o conteúdo do log. Realmente, muitas vezes é possível escrever alguns testes de unidade que apresentam o problema após a leitura cuidadosa do código.

  Superar escrever esses testes de unidade é quase tão bom quanto reproduzir o ambiente funcional que quebra. Obviamente, esse método também não garante que você encontrará algo. Pode ser realmente difícil entender a sequência exata de eventos que levam à falha em algum software multiencadeado apenas lendo o código, e a capacidade de depurar ao vivo provavelmente se tornará crítica.

Resumidamente, eu tentaria ambas as abordagens simultaneamente e pediria um sistema ativo exibindo o problema (e mostrando que ele foi corrigido posteriormente) ou algum teste de unidade de interrupção que quebra no problema (e também mostrando que ele é corrigido após a correção).

Tentar apenas consertar o código e enviá-lo na natureza parece realmente muito arriscado. Em alguns casos semelhantes que me ocorreram (onde falhamos em reproduzir o defeito internamente), deixei claro que, se uma correção ocorresse na natureza e falhasse em resolver o problema do cliente, ou tivesse outras consequências negativas inesperadas, o cara que propôs teria que ajudar a equipe de suporte a encontrar o problema real. Incluindo lidar com o cliente, se necessário.

Parece-me que você precisa de um log mais detalhado.

Embora adicionar mais logs não possa garantir que você não precisará depurar (ou, nesse caso, reproduzir a situação), ele fornecerá uma visão muito melhor do que realmente deu errado.

Especialmente em situações complicadas / de encadeamento, ou qualquer coisa em que você não possa usar um depurador, recorrer a "debug by printf ()" pode ser seu único recurso. Nesse caso, registre o máximo que puder (mais do que você espera) e tenha algumas boas ferramentas para filtrar o joio do trigo.

É razoável insistir em reproduzir todos os defeitos e depurá-los antes de diagnosticá-los e corrigi-los?

Como ninguém disse isso em termos claros ainda: Absolutamente não!

Como tudo no desenvolvimento de software, a correção de bugs significa ter em mente tempo, risco e custo. Encontrar um equilíbrio entre eles é metade da descrição do trabalho de um desenvolvedor.

Alguns erros não são importantes o suficiente para passar 2 dias, mas importantes o suficiente para gastar 10 minutos em corrigi-los. Outros erros não são determinísticos e você já sabe que um ambiente de teste não pode provar que foi corrigido. Se a configuração do ambiente de teste demorar 2 dias, você não fará isso para esses erros. Em vez disso, você gasta tempo com coisas mais inteligentes, como encontrar maneiras de configurar um ambiente de teste em 5 minutos, em vez de 2 dias.

E, é claro, existem erros nos quais, se você os enganar, um cliente perderá US $ 100.000 +. E erros nos quais o cliente perde US $ 100.000 + a cada hora em que o erro não é corrigido. Você precisa olhar para o bug e tomar uma decisão. Instruções gerais para tratar todos os erros da mesma forma não funcionam.

Muito boa pergunta! Minha opinião é que, se você não pode reproduzir o problema, não poderá 100% com certeza dizer que a correção feita não será:

a) realmente corrija o problema. b) criar outro bug

Há momentos em que um erro ocorre e eu o corrigo e não me importo em testá-lo. Eu sei 100% com certeza que funciona. Mas até que nosso departamento de controle de qualidade diga que está funcionando, ainda considero uma possibilidade que ainda exista um bug ... ou um novo bug criado a partir da correção.

Se você não pode reproduzir o bug e, em seguida, instalar a nova versão e confirmar que ele está corrigido, não é possível, com 100% de certeza, dizer que o bug se foi.

Tentei por alguns minutos pensar em uma analogia para ajudá-lo a explicar aos outros, mas nada realmente me ocorreu. A vasectomia é um exemplo engraçado, mas não é a mesma situação :-)

[bug relacionado a] acesso simultâneo ao banco de dados, implementação em cluster, multithread

É razoável insistir em reproduzir todos os defeitos e depurá-los antes de diagnosticá-los e corrigi-los?

Eu não gastaria muito tempo tentando reproduzi-lo. Isso parece um problema de sincronização e é mais frequentemente encontrado pelo raciocínio (a partir de logs como o que você precisa identificar no subsistema em que o problema ocorre) do que por encontrar uma maneira de reproduzi-lo e atacá-lo com um depurador . Na minha experiência, reduzir o nível de otimização do código ou, às vezes, e até ativar a instrumentação adicional pode ser suficiente para adicionar atraso suficiente ou a primitiva de sincronização ausente para impedir que o bug se manifeste.

Sim, se você não tiver uma maneira de reproduzir o bug, não poderá ter certeza de corrigi-lo. Mas se o seu cliente não lhe der a forma de reproduzi-lo, você também poderá procurar algo semelhante com a mesma consequência, mas com uma causa raiz diferente.

Ambas as atividades (revisão e teste de código) são necessárias, nem suficientes.

Você poderia passar meses construindo experimentos tentando reproduzir o bug e nunca chegar a lugar algum se não examinasse o código e formou uma hipótese para restringir o espaço de pesquisa. Você pode passar meses olhando para o seu umbigo tentando visualizar um bug no código, pode até pensar que o encontrou uma vez, duas, três vezes, apenas para que o cliente cada vez mais impaciente diga: "Não, o bug ainda está lá. "

Alguns desenvolvedores são relativamente melhores em uma atividade (revisão de código x testes de construção) do que na outra. Um gerente perfeito avalia esses pontos fortes ao atribuir bugs. Uma abordagem de equipe pode ser ainda mais proveitosa.

Por fim, pode não haver informações suficientes para reprogramar o bug, e você deve deixá-lo em espera por algum tempo, esperando que outro cliente encontre um problema semelhante, fornecendo mais informações sobre o problema de configuração. Se o cliente que viu o bug realmente deseja corrigi-lo, ele trabalhará com você para coletar mais informações. Se esse problema surgir apenas uma vez, provavelmente não é um bug de alta prioridade, mesmo que o cliente seja importante. Às vezes, não trabalhar com um bug é mais inteligente do que gastar horas de trabalho em busca de um defeito realmente obscuro, com informações insuficientes.