Como fechar um bug que não é mais relevante

21

Atualmente, estou em uma equipe de tamanho médio de desenvolvedores da web. Estamos usando jira para rastreamento de bugs.

Estamos trabalhando em um produto com alterações frequentes no layout. Muitas vezes, os bugs são arquivados sobre um bug no layout em algum navegador. Às vezes, quando resolvemos lidar com um bug de baixa prioridade, o layout já foi alterado e não é mais relevante.

Como devemos fechá-lo?
O que quero dizer é como devemos tratar esses problemas? Embora o Jira seja o software de rastreamento de erros que usamos, estou mais interessado em como lidar com esse tipo de problema em geral.
Isso importa? (Nós pode voltar para o layout mais tarde, mas é muito improvável)

issue-tracking jira

— Benjamin Gruenbaum
fonte

8

Muito localizado;)

— yannis

4

discordo que isso é muito localizado, pode ser mais adequado para o SO, embora seja possivelmente uma ferramenta específica

— jk.

6

@jk. Heh, eu quis dizer "localizado demais" como uma sugestão / resposta para a pergunta, não que a pergunta em si seja "localizada demais". Se eu pensasse no último, teria acabado de fechá-lo.

— yannis

2

@YannisRizos doh! talvez devesse ter sido uma resposta então;)

— jk.

6

@jk. Eu acho que a segunda pergunta é a mais interessante (isso importa?), Mas não tenho tempo agora para respondê-la (e não tenho muita certeza de que a resposta que está se formando na minha cabeça seja boa). Quanto à primeira pergunta, se esse tópico se tornar uma sugestão de "palavra / frase", ele poderá ser fechado como "não construtivo". Portanto, respondedores, não ignore a segunda pergunta, por favor, que é a mais interessante e o tópico.

— yannis

26

Nuances como essa são importantes se você considerar o rastreador de problemas como um meio de comunicar o status dos problemas que foram relatados no projeto. Para esse propósito, faz sentido investir algum esforço para garantir que o relatório de erros seja fácil de ler e entender.

Essa situação fica muito menos confusa se você a examinar da perspectiva de um testador. Se sua equipe não tem um testador, imagine um (ou melhor ainda, contrate um ^{1 , 2 , 3} ).

Ok, então havia um bug era uma vez, testador pode reproduzi-lo usando versões mais antigas de sua aplicação (nota lateral, no caso improvável que você não manter cópias de versões mais antigas, então você tem muito muito mais difícil problemas em seu equipe do que erros obsoletos). O testador pode vê-lo e saber o que está errado, o que faz dele um bug.

Agora, você diz: "o layout já mudou e não é mais relevante" - o ponto alto não é mais relevante transforma a mente do testador em uma afirmação muito mais simples: o problema desapareceu .

É importante observar aqui que o testador profissional deve se sentir confortável pensando no sistema como uma caixa preta . Nessa perspectiva, não importa muito o quão exatamente aconteceu esse problema, pode ser uma mudança de layout ou magia negra ou redesenho total ou alteração concreta de código, qualquer que seja.

Do ponto de vista da caixa preta, sua situação é bem simples. Houve um problema, ele ainda pode ser reproduzido em versões mais antigas, agora você afirma que as versões mais recentes não têm mais esse problema. Para um testador, isso se resume a uma afirmação de que o bug foi corrigido e, respectivamente, à necessidade de verificar se a afirmação é verdadeira.

O testador profissional pegaria sua versão mais antiga, examinaria como o problema está presente lá, pegaria uma versão mais recente e verificaria se ele já foi ou ainda está lá.

Acima, a maneira mais precisa de lidar com erros como você descreve seria fechando-os como resolvidos, corrigidos . É claro que não faria mal se você esclarecesse nos comentários que a correção ocorreu como um efeito colateral não intencional da alteração de layout.

Um dos JIRAs personalizados com os quais trabalhei em um projeto anterior tinha a resolução "Fixed By Design" para comunicar mudanças bastante profundas com muitas consequências, algumas intencionais, outras não. Para o caso descrito, isso também pode ser considerado em vez de simples "Fixo", pois sugere ao leitor de tickets que é mais um efeito colateral do que uma alteração intencional do código.

— mosquito
fonte

2

Fixado pelo Design implicaria, para mim, o completo oposto disso. Na minha opinião, por design significa "intencional" (é o oposto de "por engano").

— TRiG

Eu concordo que "fixo" é suficiente. Não importa se foi intencional ou um efeito colateral de outras mudanças. No entanto, também concordo com o @TRiG que "Fixed by Design" é confuso.

1

@TRiG bem, é por isso que apontei que alguém explica melhor os detalhes exatos nos comentários. Fixed By Design é um pouco amplo; no projeto que vi, ele foi usado para comunicar mudanças bastante profundas, com muitas consequências, algumas intencionais, outras não - cobrindo casos como esse. Note-se também, nem pergunta de texto nem a minha resposta implica "correção por engano" (o erro?) - aqui, "não intencional" é muito muito melhor ajuste

— mosquito

1

Todas as respostas são boas, mas esta parece acertar. Obrigado a todos.

— Benjamin Gruenbaum

6

Que tal "Corrigido pelo redesenho"?

— penguat

47

Resolvemos problemas como 'Obsoleto'. Esta não é uma opção de resolução padrão no JIRA, mas é fácil de adicionar.

— Kris
fonte

+1 se você não pode adicioná-lo, pelo menos, escolher, pois como não um bug e comentar por que

— tgkprog

9

O JIRA (e tenho certeza que outros rastreadores de erros) permite que você especifique resoluções personalizadas para poder configurar uma resolução "Ultrapassada por eventos" ou "Irrelavante" ou similar para permitir que você expresse o fechamento como quiser

Isso importa? isso depende, para nós, eu diria que sim, pois nosso cliente está excessivamente preocupado com o número de problemas em aberto no nosso rastreador; portanto, é útil poder dizer que eles estão fechados porque não são mais relevantes sem excluir totalmente o problema. .

Mesmo sem um cliente preocupado com os números de problemas, a remoção de problemas abertos antigos que não são mais relevantes é definitivamente útil apenas para reduzir a confusão no navegador.

— jk.
fonte

1

"Over Taken By Events" é muito longo (imho), eu usaria uma única palavra (irrelevante / obsoleta) apenas porque é mais fácil pesquisar e ocupa menos espaço (em relatórios, etc.). A única vez em que a quantidade de bugs obsoletos foi útil foi quando eles chegaram em massa e isso apontou para um problema de comunicação. Nossos testadores não estavam em dia com o que nossos desenvolvedores estavam trabalhando, eles perderam o memorando de que as coisas ficarão esquisitas por uma semana ou mais e estavam fazendo barulho (inútil). Então, olhando para o nosso obs. erros nos ajudaram a encontrar e corrigir um buraco em nossos processos de comunicação.

— yannis

3

na verdade, usamos um acrônimo OBE, mas acho que a palavra real usada é o ponto menos interessante aqui, o ponto é escolher algo que funcione para você

— jk.

3

@YannisRizos: Corrigindo meta-bugs usando bugs. Quão legal é isso!

— Jörg W Mittag

A pesquisa @YannisRizos não é um problema, pois as resoluções válidas são escolhidas de uma lista suspensa (no JIRA)

— jk.

2

@Yannis. Eu perderia o sono por causa disso: ultrapassar deveria ser uma palavra.

— TRiG

5

Usamos o FogBugz, mas tenho certeza que o mesmo (ou semelhante) se aplica aqui:

Nós apenas usamos "Resolved (Fixed)" e comentamos na resolução editar algo como "Fixed by case 12345".

O FogBugz corresponde a "case \ d +" e vincula os dois em Casos Relacionados, mas se Jira não fizer isso, deve ser simples adicionar um link.

Isso é IMO melhor do que uma variante "Too Localized" porque era um bug real e melhor do que apenas "Obsolete" porque foi corrigido, esse recurso não foi apenas removido.

— Izkata
fonte

3

Corrigido, sóbrio e checando novamente <- história verdadeira.

— precisa saber é o seguinte

1

Jira também permite essa abordagem. Basta mencionar o número do problema nos comentários da resolução e o Jira o transformará em um hiperlink.

— Marjan Venema