O que fazer com os bugs que não se reproduzem?

Eu tenho um testador que, durante o teste, ocorrerá um erro (ok até agora), mas ele frequentemente o relata imediatamente. Mais tarde, nós (os desenvolvedores) descobrimos que o testador não tentou reproduzir o problema e (quando solicitado) não conseguiu encontrar uma maneira de fazê-lo acontecer novamente.

Agora, esses ainda são erros, não quero ignorá-los. Mas sem as etapas de reprodução, estou meio que preso. Às vezes, há um rastreamento de pilha (embora freqüentemente não seja útil porque essa é uma estrutura compacta e não há números de linha). Mas quando existe uma, posso pegar o rastreamento da pilha e abrir o código e começar a adivinhar, mas isso não leva a "correções" testáveis.

O que você faz em cenários como este?

Um bug sem contexto não é um bug, é um acaso. O problema pode ser o seu código, uma biblioteca de terceiros, o hardware ou a radiação solar, fazendo com que um único bit seja ativado por conta própria. Se você não pode reproduzi-lo com pelo menos alguma regularidade (mesmo que apenas "isso aconteça uma vez a cada 10 ou 20 vezes eu faça X"), não é muito melhor do que o seu testador dizendo "Algo em algum lugar deu errado de alguma forma - conserte" .

Talvez você precise explicar ao testador que o trabalho dele não é apenas gerar informações até que algo quebre. Se fosse, você poderia substituí-lo por um gerador de números aleatórios. Parte de seu trabalho é identificar bugs, o que implica identificar como produzi-los.

Por fim, se nem o desenvolvedor nem o testador puderem reproduzir o bug, ele deverá ser fechado, mas marcado como tal.

No entanto, quanto tempo você leva para chegar a esse ponto é discutível.

Algumas pessoas argumentam que, se não for reproduzível imediatamente, deve ser fechado imediatamente.

Eu geralmente me esforço para tentar obter mais informações do autor do problema. Pode haver algo que eles tenham esquecido no relatório original. Conversar sobre as etapas necessárias geralmente pode revelar as informações ausentes.

Um pensamento final - fechado como "não reprodução" não significa fixo. Se houver um problema real, ele se revelará mais cedo ou mais tarde e, com todas as informações que você pode ajudar, poderá finalmente reproduzir o problema.

Mais algumas sugestões:

1. Adicione registro (e não apenas um keylogger:}) ao código do seu produto. Os erros "sem repetição" podem ser desastres, mas podem ser corrupção de memória ou estado que ocorre apenas em um sistema sujo usado de maneiras imprevistas (ou seja, como o computador de um cliente). As informações de registro ou rastreamento podem ajudá-lo a descobrir o que pode estar errado quando o testador encontrou o acaso.

2. Examine o restante dos bugs "no repro" no banco de dados (ou o que você usar para rastrear bugs). Freqüentemente, os flukes se agrupam em uma área do produto. Se parecer que um componente está com falha, revise o componente para verificar se há possíveis falhas, adicione registro adicional a esse componente - ou a ambos.

3. Demore meia hora ou mais e assista ao teste do seu testador. A abordagem deles pode lhe dar uma idéia do que deu errado (por exemplo, "interessante - eu não sabia que você poderia chegar a esse diálogo dessa maneira"). Você também pode achar que eles pulam uma caixa de diálogo ou configuração acidentalmente. Vale a pena o investimento de tempo para entrar um pouco na cabeça deles.

Eu faço controle de qualidade em um grande código comercial, esse cenário irritante surge com muita frequência. Normalmente, é indicativo de não haver procedimentos rígidos para a construção do binário em todas as plataformas suportadas. Portanto, se o desenvolvedor criar seu próprio código (que ele precisa fazer para depurar e corrigir) e não seguir o mesmo procedimento de criação, é possível que os erros dependentes do sistema pareçam desaparecer magicamente (ou apareçam) . É claro que essas coisas geralmente são encerradas com "funciona para mim" no banco de dados de erros e, se falharem na próxima vez em que o problema for executado, o bug poderá ser reaberto. Sempre que suspeito que um bug possa depender do sistema, tento testá-lo em várias plataformas e relato sob quais condições ele ocorre. Muitas vezes, aparece um problema de corrupção de memória onlt se os dados corrompidos forem de magnitude suficientemente grande para causar um travamento. Algumas plataformas (combinações de HW e OS) podem falhar mais perto da fonte real da corrupção, e isso pode ser muito valioso para o pobre coitado que precisa depurá-la.

O testador precisa agregar algum valor agregado, além de apenas relatar que seu sistema mostra uma falha. Eu gasto muito tempo examinando falsos positivos - talvez a plataforma em questão esteja sobrecarregada ou a rede tenha tido uma falha. E sim, às vezes você pode obter algo realmente afetado por eventos de cronometragem aleatórios, os erros de hardware costumam ser como exemplo proto: se duas solicitações de dados retornam exatamente o mesmo período de tempo e a lógica do hardware para lidar com o conflito em potencial está com defeito, então o bug só aparecerá intermitentemente. Da mesma forma com o processamento paralelo, a menos que, por um design cuidadoso, você restrinja a solução a ser independente de qual processador é mais rápido, você pode obter bugs que acontecem apenas uma vez na lua azul, e sua importância estatística torna a depuração um pesadelo.

Além disso, nosso código está sendo atualizado, geralmente muitas vezes ao dia, rastreando um número exato de revisão de código fonte para quando foi para o sul, podendo ser uma informação muito útil para o esforço de depuração. O testador não deve estar em um relacionamento adversário com os depuradores e desenvolvedores, ele está lá como parte de uma equipe para melhorar a qualidade do produto.

Existem dois tipos de erros que não são reproduzíveis:

1) Aqueles que um testador (ou usuário) viu uma vez, mas não conseguiu ou não tentou reproduzir.

Nessas situações, você deve:

• Verifique muito brevemente o curso básico das ações que mostraram o defeito para garantir que ele não seja reproduzível.

• Fale com o testador / usuário para ver se há outras informações que possam ajudar.

• Faça uma referência cruzada com outros defeitos que possam estar relacionados para verificar se você possui informações suficientes para procurá-los com base em várias instâncias. Você pode achar que esse problema não fornece informações suficientes para prosseguir; no entanto, quando associado a vários outros problemas, pode sugerir algo incorreto que vale a pena investigar.

• Se você ainda não tiver o suficiente para continuar, precisará explicar ao usuário / testador que não possui informações suficientes. Descreva-lhes educadamente como seriam as informações suficientes e por que elas são necessárias.

2) Aqueles em que eles não podem ser reproduzidos de maneira confiável, no entanto, existem evidências suficientes (em termos de ocorrências repetidas) para sugerir que o defeito existe, então eu tendem a ver que esses são problemas do desenvolvedor e que o desenvolvedor é suportado pelo testador / user - precisa investigar.

É provável que isso seja lento e doloroso; é provável que você precise percorrer o código, adicionar mais registros, examinar os dados e falar com os testadores / usuários em profundidade, mas se houver evidência suficiente para sugerir que é provável que exista é um problema em que você precisa se apropriar dele e fazer o que for necessário para corrigi-lo.

Parece que isso acontece com relativa frequência - o que me faz pensar, é porque a maioria dos bugs é realmente difícil de reproduzir, ou é por algum outro motivo que ele não está tentando? Você sabe por que ele não está tentando reproduzir o problema? É porque ele não percebe o quanto é importante para você? Ou talvez ele tenha outras pressões - um gerente de testes que apenas quer que ele faça os testes alocados rapidamente e jogue os bugs por cima do muro, por exemplo? Ou talvez ele não tenha certeza de como fazer isso?

Concordo com outras pessoas que trabalhar em um melhor registro é uma prioridade. Enquanto isso, se você suspeitar que a falta de habilidade / confiança do testador possa ser um problema, eu realmente gosto deste artigo de Danny Faught sobre o isolamento de bugs - você pode apontá-lo para começar.

Se o problema for devido à pressão da gerência - você tem minhas simpatias, pois é difícil resolver isso, especialmente se testadores e programadores se reportam a diferentes gerentes e os gerentes não estão dispostos a "ajudar" outra equipe.

Normalmente, observo que não é reproduzível, mas deixo em aberto até que esse lote de testes ou iteração seja concluído.

Se não tiver sido reproduzido nesse ponto, será fechado, mas poderá ser reaberto se for encontrado novamente.

coloque um keylogger na estação de trabalho deste testador!

Bem, a primeira tarefa é ter um sistema de teste reproduzível. Seu testador deve ter um processo bem definido - automático, se possível.

Tenha estas três condições:

• Mesmo binário
• Mesmos passos
• Mesma máquina

Se o bug aparecer esporadicamente com as três condições acima, comece a isolar ainda mais. Considere cada nível da pilha do sistema e sua configuração.

Uma maneira de detectar erros de gerenciamento de memória é executar o programa em vários sistemas operacionais com vários compiladores. Valgrind também pode ajudar.

No entanto, sistemas tipicamente paralelos são suscetíveis de induzir erros não reproduzidos. Coisas como tamanhos de buffer e velocidades de processamento, assíncrono io, bloqueios de banco de dados, intercalações de gravação de memória variável; tudo isso pode gerar problemas. E assim por diante e assim por diante.

Antes de tudo, você deve ter um procedimento de teste rigoroso (mas eu entendo que, na minha empresa, o que você descreveu acontece com frequência).

Dependendo da gravidade do bug, você pode investir algum tempo nele (ou melhor) ignorá-lo até que sejam fornecidas etapas de reprodução.