Por que não é recomendável postar vários defeitos no mesmo problema / ticket?

Não tenho certeza se este é o lugar para fazer a seguinte pergunta conceitual (o Stackoverflow definitivamente não é).

Vi essa pergunta em um exame de múltipla escolha (resposta única), semelhante aos exames ISTQB :

Por que não é recomendável relatar vários defeitos no mesmo problema / ticket?

uma. Para manter o relatório conciso e claro.

b. Porque os desenvolvedores podem corrigir apenas um bug.

c. Como os testadores do grupo de teste são classificados pela quantidade de bugs encontrados.

d. Os sistemas de gerenciamento de bugs não suportam esse recurso de vários bugs.

Minha única opinião é que essa aé a resposta correta.

b- não pode ser porque o fix-feedback-resolvido-fechado deve evitar esse caso. cObviamente errado.

d - Os plugins Redmine / Trac suportam vários campos.

A resposta de acordo com a folha de respostas é b.

Alguém pode explicar o porquê? Comentários com opinião sobre respostas são bem-vindos.

Imagine se o Stack Overflow tivesse uma orientação: em vez de fazer uma pergunta, você vem e faz, na mesma pergunta, o que lhe vier à mente, todos os problemas que você teve nas últimas duas semanas. O que significaria voto positivo e voto negativo? Quais seriam os títulos das perguntas? Como aceitar a melhor resposta? Como marcar a pergunta?

O sistema de rastreamento de bugs é feito para ... rastrear bugs. Rastrear um bug significa:

1. Criando um registro dizendo que um bug pode existir, com informações sobre como reproduzi-lo,

2. Confirmando que, de fato, o bug existe e é um bug, não algo por design,

3. Afirmando que o bug está resolvido,

4. Confirmando que o erro foi resolvido.

Em um modelo muito simplista, 1 e 4 serão feitos pelo cliente e 2 e 3 - pelo desenvolvedor.

Imagine o seguinte log:

• Dia 1 [Cliente] Ao pressionar o botão “Remover” na janela “Detalhes do produto”, o aplicativo trava. Reiniciar o aplicativo mostra que o produto não foi removido. O comportamento esperado é remover o produto.

• Dia 4 [Desenvolvedor] <Problema reproduzido>

• Dia 5 [Desenvolvedor] <Problema resolvido na revisão 5031>

• Dia 12 [Cliente] <Ticket fechado: problema resolvido>

O log é simples e claro . Você pode rastrear facilmente o que foi feito e quando , qual revisão resolveu qual erro, etc. Por exemplo, se o sistema de rastreamento de erros estiver integrado ao controle de versão, quando você visualizar uma revisão específica, poderá verificar quais erros foram resolvidos.

É fácil encontrar informações . É fácil ver seu estado (é reproduzido? Se o ticket foi fechado, por quê?). É fácil filtrar tickets (quero exibir tickets que dizem respeito apenas à interface do usuário dos plug-ins, pois quero apenas tickets abertos, com mais de uma semana e designados a mim pelo nosso designer de interação e com prioridade média ou alta).

É fácil reatribuir um ticket ou determinar originalmente qual é a pessoa que deve ser responsável pelo bug.

Agora imagine o seguinte log:

• Dia 1 [Cliente] O aplicativo trava quando pressiono o botão "Remover" na janela "Detalhes do produto". Além disso, a cor de fundo do painel esquerdo é azul escuro, enquanto deve ser roxa. Também observei que o texto da janela "Detalhes do produto" não está bem traduzido para o alemão; isso é esperado? Quando a tradução final estaria disponível? BTW, você recebeu o novo ícone que enviei para a ação "Publicar produto"? Não o vejo na janela "Sincronizar dados".

• Dia 6 [Desenvolvedor] Mudei a cor para roxo.

• Dia 7 [Desenvolvedor] Sim, é normal que a tradução para o alemão esteja incompleta.

• Dia 8 [Cliente] Ok para alemão. E o italiano? Lucia enviou a você o arquivo XML há dois dias.

• Dia 9 [Desenvolvedor] Está tudo bem agora.

• Dia 10 [Cliente] Ok para o botão "Remover"? Estranho, no meu computador, ainda trava.

• Dia 11 [Desenvolvedor] Não, eu queria dizer que está ok para a tradução em italiano.

• Dia 12 [Cliente] Entendo. Obrigado. Mas há um problema com a cor. Você mudou para roxo escuro, mas deve ser roxo claro, como o painel superior na janela principal.

• Dia 13 [Desenvolvedor] Atualizei o ícone.

• Dia 14 [Cliente] O ícone? Que ícone?

• Dia 15 [Desenvolvedor] O ícone que você me pediu para atualizar.

• Dia 16 [Cliente] Eu nunca pedi para você atualizar qualquer ícone.

• Dia 17 [Desenvolvedor] Claro que você perguntou. Veja este ingresso. Você escreveu que o ícone de publicação do produto deve ser atualizado. Eu fiz isso.

  ⁞

• Dia 100 [Cliente] E as entradas no log?

• Dia 101 [Desenvolvedor] Não faço ideia do que você está falando. Não está nem neste bilhete, mas em 6199. Estou fechando este como resolvido. <Ticket fechado: problema resolvido>

• Dia 102 [Cliente] Desculpe reabri-lo, mas o problema não está resolvido. Eu estou falando sobre as entradas no log: eu disse na semana passada que o texto às vezes é inválido quando contém caracteres unicode. Você se lembra? <Bilhete reaberto>

• Dia 103 [Desenvolvedor] Lembro-me vagamente de algo assim, mas depois de pesquisar as últimas três páginas deste ticket, não consigo encontrar nenhum vestígio. Você pode escrever novamente qual foi o problema?

  ⁞

• Dia 460 [Desenvolvedor] Passei duas horas procurando um rastro do que você disse sobre os arquivos enviados criptografados pela rede. Não tenho certeza de encontrar o pedido preciso.

• Dia 460 [Cliente] Vocês deveriam realmente ser mais organizados. Eu o avisei quatro vezes sobre esse problema nas últimas duas semanas. Por que você está esquecendo tudo?

  ⁞

Sobre o que é esse registro? Foi resolvido 43 vezes e reaberto 43 vezes. Isso significa que o desenvolvedor é tão estúpido que não consegue resolver o mesmo problema por 460 dias? Ah, não, espere, esse ticket foi atribuído a 11 desenvolvedores enquanto isso. Qual é o problema? Como procurar um problema específico? Na verdade, ela é atribuída a Vanessa, mas seus cinco colegas também estão preocupados com sete dos onze assuntos deste ticket. Quando o bilhete deve ser fechado? É quando metade dos problemas é resolvida? Ou talvez dez das onze?

Nota: Você pode acreditar que esses logs não existem. Acredite, eu já vi mais de uma vez.

Apenas para comentar sua declaração:

não pode ser porque o fix-feedback-resolvido-fechado deve evitar esse caso

Isso pressupõe que todos os erros gerados serão corrigidos ao mesmo tempo. Imagine um cenário em que um ticket seja gerado na v1 do produto com dois problemas:

1. Na verdade, um botão de redefinição de formulário envia o formulário, em vez de limpar os valores
2. O tamanho da fonte no botão é 110% quando deveria ser 115%.

Ambos estão corretos para um testador aumentar, pois ambos são falhas na implementação. Mas digamos que o proprietário do produto decida que a primeira subtarefa é um bloqueador a ser liberado (ou seja, precisa ser corrigido antes que o produto seja lançado), mas a segunda tarefa é um problema menor (ou seja, pode ser corrigido em uma v1). 1 release).

Nesse caso, não temos escolha a não ser dividir o número 2 em seu próprio ticket (ou correr o risco de esquecê-lo). Se pudermos fazer isso, significa que eles podem ser implementados, testados e implantados independentemente um do outro; nesse caso, faz sentido ter problemas individuais desde o início.

Escopo:

Essa resposta (e a pergunta) parece aplicável apenas ao rastreamento de defeitos de código, onde o código fonte não funciona de acordo com a especificação ou as intenções dos programadores.

Pelo contrário, é comum que os tickets de defeitos da GUI contenham várias especificações, porque cada ticket da GUI é efetivamente um "reprojeto" (defeito de design), uma "especificação revisada" ou uma "solicitação de recurso" (falta de funcionalidade).

Um objetivo importante do rastreamento de defeitos é comunicar e coordenar entre várias funções (programadores, testadores, clientes e gerentes).

Em projetos em que a qualidade do código tem alto significado (em comparação com a facilidade de uso, por exemplo), o rastreamento de defeitos pode consistir em várias facetas, uma das quais se concentraria no rastreamento de defeitos de código , separadamente do rastreamento de aprimoramentos e solicitações de suporte ao cliente.

O objetivo do sistema de rastreamento de defeitos de código é:

• Para permitir o rastreamento independente e inequívoco de defeitos reproduzíveis independentemente , e
• Fornecer a melhor aproximação (correspondência um a um) à causa raiz de cada defeito.

Ao fazê-lo, deve maximizar as seguintes qualidades desejáveis:

• Escale com eficiência à medida que o número de defeitos aumenta com o tempo.
• Evite a síndrome do alvo em movimento.

Disclaimer: esta reformulação é da minha experiência pessoal. Pode ser insuficiente ou incorreto para fins de exame de certificação.

Rastreamento independente e inequívoco significa que:

1. Cada defeito válido pode ser resolvido ou não , sem ambiguidade.

   • Razão 1: para simplificar o gerenciamento,
     • Exemplo: permite o uso de "número de tickets não resolvidos" como uma métrica.
   • Razão 2: traduzir em item acionável
     • Exemplo: se não for resolvido, a responsabilidade recai sobre o programador atribuído. Se for resolvido, mas não fechado, a responsabilidade recai sobre o testador designado (verificador).
   • Consequência: Nesta metodologia, um defeito parcialmente resolvido merece ser dividido em vários defeitos dependentes.

2. Defeitos reproduzíveis independentemente devem ser rastreados de forma independente.

   • "Independentemente reproduzível" significa que eles podem ter estados diferentes. Um pode parecer estar consertado enquanto o outro permanece quebrado.
   • Razão: para minimizar a incompatibilidade entre o rastreamento de defeitos e a análise de causa raiz.
     • Acredita-se que cada causa raiz que possa ser rastreada para um defeito de código exija pelo menos uma alteração de código.
     • Se dois defeitos forem reproduzíveis independentemente, serão necessárias várias alterações de código.
     • Se dois defeitos são reproduzíveis de forma independente, ambos devem ser testados (verificados), porque a aprovação de um teste não implica que o outro será aprovado.
   • Exemplo 2: se inicialmente se acreditava que dois sintomas tinham a mesma causa raiz e, portanto, eram classificados no mesmo ticket, e mais tarde eles mostraram ser reproduzíveis independentemente, então deveriam ser divididos em dois tickets.

Olhe para ele da perspectiva de outra pessoa usando o sistema, aparecendo alguns meses depois. Eles encontram um erro no programa. Eles pesquisam e veem que há um tíquete de suporte que corresponde ao problema que eles estão tendo. E ei, está fechado! Impressionante! Foi corrigido na versão mais recente! Então, eles atualizam ... e o bug ainda está lá? O que há de errado com esses desenvolvedores estúpidos?!?

Nada, na verdade. Acontece que há algo errado com a pessoa que envia o relatório de erro. Eles enviaram dois erros no mesmo ticket. Um era fácil de consertar e era consertado rapidamente, e o outro não. Mesmo se você usar algo como corrigir-feedback-resolvido-fechado, ainda pode ser menos do que claro o que está acontecendo, especialmente para um observador externo.

É muito melhor atribuir a cada bug seu próprio ticket e, se você tiver vários erros relacionados, mas aparentemente distintos, a maioria dos sistemas de rastreamento de erros possui um recurso que permite vincular um bug a outro. (E se não, você pode apenas colocá-lo no relatório. "Veja também o bug # 12345".)