Prática recomendada para marcar um bug como resolvido no Bugzilla?

5

Eu estou querendo saber qual é a melhor maneira de lidar com a situação de marcar um bug como resolvido e fornecer uma versão do componente / produto na qual essa correção pode ser encontrada.

Contexto

Para um projeto em que estou trabalhando, estamos usando o Bugzilla para rastreamento de problemas e temos o seguinte:

  • Um produto "A" com um número de versão como vA.B.C.D,

Este produto "A" tem os seguintes componentes:

  • Componente "C1" com um número de versão como vA.B.C.D,
  • Componente "C2" com um número de versão como vA.B.C.D,
  • Componente "C3" com um número de versão como vA.B.C.D.

Internamente, rastreamos quais versões de componentes foram usadas para gerar o produto. Uma versão vA.B.C.D.

Exemplo: O produto "A" versão v1.0.0.0 foi produzido a partir do componente "C1" v1.0.0.3, componente "C2" v1.3.0.0 e componente "C3" v2.1.3.5. / p>

E o produto "A" versão v1.0.1.0 foi produzido a partir do componente "C1" v1.0.0.4, componente "C2" v1.3.0.0 e componente "C3" v2.1.3.5.

Cada componente é um repositório SVN.

O responsável por gerar o produto "A" só tem acesso à pasta de tags de componentes diferentes no SVN, e não ao tronco de cada repositório de componentes.

Problema

Agora, o problema é o seguinte, quando um bug é encontrado no produto "A" e o bug está relacionado ao Componente "C1", a versão do produto "A" é escolhida (por exemplo, v1.0.0.0 ), e esta versão permite que o desenvolvedor saiba qual versão do componente "C1" tem o bug (aqui será v1.0.0.3). Um relatório de bug é criado.

Agora vamos dizer que o desenvolvedor responsável pelo componente "C1" corrige o bug, então quando o bug parece ser corrigido e após algum teste e validação, o desenvolvedor gera uma nova tag para o componente "C1", com a versão v1 .0.0.4. No momento, o desenvolvedor do componente "C1" precisa atualizar o relatório de erros, mas o que é melhor fazer:

  1. Marque o bug como resolvido / corrigido e adicione um comentário dizendo "Este bug foi corrigido nas tags v1.0.0.4 do componente C1"?
  2. Mantenha o bug como atribuído, adicione um comentário dizendo "Este bug foi corrigido nas tags v1.0.0.4 do componente C1, atualize este status de bug para resolvido para a próxima versão do produto que será gerada com o versão mais recente (v1.0.0.4 do C1) "?
  3. Outra maneira possível de lidar com esse problema.

Neste momento, o problema é que, quando um componente do produto CX é corrigido, não é certo em qual versão futura do produto A ele será incluído; portanto, não é possível dizer em qual versão do produto ele será resolvido, mas é possível dizer em qual versão do Component CX ele foi resolvido. Então, quando precisamos marcar um bug como resolvido, quando a versão do produto A inclui a versão fixa do CX ou apenas quando o componente CX foi corrigido?

Obrigado pelo seu feedback pessoal e ideias sobre isso!

    
por Vincent B. 05.07.2012 / 04:18
fonte

1 resposta

2

A correção no componente e a integração do componente fixo no produto são duas atividades diferentes.

Poderia haver muitas maneiras de lidar com isso, mas não importa o que você escolher, é melhor você tomar cuidado para que a diferença acima seja fácil de entender por aqueles que usam o bug tracker.

Uma solução simples poderia ser simplesmente usar bugs separados para essas atividades separadas.

  • ticket 1234. Corrija o problema > no componente "C1".
  • Ticket 1235. Integre a correção do < ticket 1234 > no produto "A".

Dessa forma, você obtém uma descrição clara do que deve ser feito, pode atribuir, priorizar e agendar os tickets independentemente, levando em consideração que integração pode ser iniciada após a conclusão da correção do componente .

Além disso, essa maneira permite lidar com mais "dependências de vários níveis", como primeiro é necessário corrigir um componente de biblioteca X, integrar e ajustar o componente C1 e, depois disso, integrar-se ao produto A.

That is a good idea indeed, however it means more process and overhead for "one" bug. Providing a specific format for the bug summary could make the management simpler ([INT. FIX] "summary of the bug previously reported")...

Para completar, note que a abordagem acima ("um bug, duas fases") também pode ser viável - especialmente se a grande maioria de seus bugs se integrar dessa forma (versão específica de component - > versão particular do product ).

Eu já vi isso em pelo menos dois projetos diferentes e funcionou bem. Normalmente demorava algum tempo para que os recém-chegados da equipe se acostumassem ao fluxo de trabalho e, em casos de integração mais complicada, usamos bugs separados para rastrear isso, mas isso é insignificante.

  • Além do estado adicional ( INT.FIX na citação acima), os pontos que valem a pena considerar para "ciclo de vida de bugs em duas fases" são campos dedicados para versões de componentes e produtos, bem como para engenheiros responsáveis. No entanto, isso não é uma questão de vida ou morte - se não houver campos dedicados, os dados relevantes podem ser extraídos do histórico de alterações de bugs ou colocados em comentários.

E, como você mencionou sobrecarga , minha firme convicção é que qualquer sobrecarga substancial que possa estar relacionada ao rastreamento de erros significa que algo está errado no rastreador de erros ou no gerenciamento de projetos, ou ambos.

    
por 05.07.2012 / 09:25
fonte