Como lidar com um bug que parece ter se consertado? [fechadas]

Fechado . Esta questão é baseada em opiniões . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela possa ser respondida com fatos e citações editando esta postagem .

Fechado há 4 anos .

Sou desenvolvedor de aplicativos da web para um sistema interno. Um usuário relata que há um erro.

O problema era que algumas palavras não podiam ser exibidas. O relatório contém uma captura de tela que mostra claramente o erro. Mas o relatório tem quase um mês e o bug não pode mais ser reproduzido em nosso ambiente de produção.

Como devo responder ao cliente e ao usuário?

issue-tracking defect

— Ben Cheng
fonte

Aqui temos várias perguntas relacionadas aos programadores: Afaste um erro se não houver um caso de teste reproduzível? Como isolar bugs difíceis de reproduzir? Como efetivamente depurar código? Erros inexplicáveis? O que fazer com os bugs que não se reproduzem?

— Thomas Owens

Descubra como torná-lo repetível.

— Wyatt Barnett

Quanto tempo você pode pagar por essa investigação? Quão crítico foi o bug e seus efeitos negativos? Se as respostas forem muito pequenas e insignificantes, eu diria que marcá-lo como corrigido com uma nota das circunstâncias em que não é realmente corrigido e esperar que ele volte é um uso perfeitamente aceitável dos recursos da sua empresa.

— Newtopian

Isso exige apenas uma resposta padrão bastante padronizada: " Prezado [usuário], o problema com o X que você informou no Yth parece ter sido resolvido com a versão mais recente do Z. Marque o problema como resolvido, se esse for realmente o caso. Caso contrário, envie-o de volta para mim com detalhes sobre como você o encontrou. "

— Lilienthal

@ Lilienthal Só porque um erro não pode ser reproduzido não significa que foi resolvido. Você nem sabe que houve um novo lançamento no último mês.

— Paparazzo

Respostas:

Reverta o seu ambiente de desenvolvimento para a versão em que o bug foi detectado e verifique se o bug existe.

Se estiver lá, você poderá investigar o bug e verificar se a versão atual não o possui. Em seguida, feche o relatório de bug com o comentário de que uma alteração não relacionada o corrigiu. Adicione um teste de regressão, se necessário.

Se você não conseguir reproduzir o bug nessa versão, as estratégias apresentadas em muitas outras perguntas aqui serão úteis (Obrigado Thomas pela lista inicial):

— catraca arrepiante
fonte

Na minha experiência, a maioria das equipes apenas verifica a opção "não é possível reproduzir" no sistema de emissão de bilhetes e fecha-a. Testar o código "then" e "now" para garantir que o problema existisse e não seja mais parece uma solução melhor. Mas também consome mais tempo do que dizer "não é possível reproduzir" e fechá-lo; portanto, pode não ser uma opção para todos os erros.

— Paul J Abernathy

Depende da gravidade do bug. Se é apenas uma brincadeira de layout, na verdade não se pode reprovar e ser feito, mas se pudesse ser mais sinistro, algumas horas para terminar com um teste de regressão podem valer a pena.

— Ratchet freak #

@ratchetfreak Como alternativa, depende da gravidade desse cliente em particular. Se eles estão financiando singlehandedly seus contracheques, talvez o seu valor humoring-los ;-)

— Cort Ammon - Reintegrar Monica

Os problemas que desaparecem por si mesmos voltam por si mesmos.

— Pete Becker

É tudo uma questão de carga de trabalho. Se você tem um bug que foi reproduzível há um mês e não é mais, e outro bug que é reproduzível agora , você corrige o que é reproduzível agora primeiro. Se você chegar a um estado em que está totalmente entediado, poderá investigar. E quando o problema vem de volta, por si só, então é claro que é um erro reproduzível e você começar a corrigi-lo :-)

— gnasher729

Vou assumir que você realmente fez tudo o que pôde para reproduzir o bug, mas não pode.

Em um caso como esse, geralmente é melhor adicionar algum código em torno da área do aplicativo que não conseguiu registrar o trabalho que está sendo feito, para que, com sorte, você tenha mais dados para trabalhar se isso acontecer novamente. Pense nas informações que você precisa e que atualmente não possui. Por exemplo, talvez isso ocorra apenas quando um conjunto específico de parâmetros de entrada é enviado e você os registra sempre que o processo é executado. No entanto, verifique com seu chefe antes de fazer isso, dependendo da importância do bug e da frequência com que ele ocorreu, ele pode não querer gastar tempo para fazer isso.

Em seguida, você é a pessoa que relatou o erro (você pode fazer isso no aplicativo de rastreamento de erros, se tiver um, não precisa ir pessoalmente) e diz que não conseguiu reproduzir o erro, mas adicionou algumas informações adicionais. para obter mais detalhes sobre o que o processo está fazendo, caso o bug ocorra novamente. Então feche o bug.

Se você não pode fazer log adicional. basta relatar que o bug não era reproduzível e que, se o encontrar novamente, essas são as informações necessárias para reproduzi-lo e diga o que você precisa. Frequentemente, solicitamos que eles nos digam exatamente quais parâmetros de entrada estavam inserindo quando obtiveram o erro. Só uma captura de tela do erro ajuda, mas saber exatamente quais etapas eles estavam tomando e quais informações eles tentaram usar no momento em que o erro ocorreu são mais úteis. Então, basicamente, você está colocando o ônus de volta neles para fornecer mais informações quando eles reportarem o erro, se ocorrer novamente.

No seu rastreador de erros, certifique-se de explicar quais etapas você tentou, de modo que, se o erro ocorrer novamente, a pessoa que o manipular terá algum conhecimento sobre o que foi feito antes.

— HLGEM
fonte

Sacos não reproduzíveis são os piores! Enquanto isso, pode ter sido corrigido ou ainda pode estar lá, mas é esporádico ou as etapas a serem reproduzidas não são especificadas de maneira suficiente. Você deve fazer um julgamento sobre qual é o risco de alto risco e quanto você expandirá para investigá-lo. Você está criando um gerenciador de receitas on-line ou um software de controle de direção para mísseis nucleares?

Se for um bug de baixo impacto e você souber que foram feitas alterações que poderiam resultar na correção involuntária do bug, pode ser aceitável encerrá-lo com a nota de que ele não é reproduzível e você assume que foi corrigido .

Se você estiver mais preocupado, você pode fazer algumas teorias sobre o que causou o bug e, em primeiro lugar, examinar o log de alterações e o histórico de fontes para ver se consegue identificar onde foram corrigidos.

Para um bug mais sério, você precisará reverter a fonte até o ponto da última versão e, em seguida, tentar se reproduzir. Se você reproduzir com êxito, poderá escrever testes para garantir que seja corrigido nas confirmações posteriores.

— JacquesB
fonte