O arquivo QA deve conter 5 bugs separados ou um bug com várias partes nele?

4

A questão pode não ser tão simples quanto parece, já que lutamos um pouco com isso. Se houver 5 bugs separados, que podem ser resolvidos com uma única correção, é um desperdício usar essa abordagem. Um bug pode escorregar pelas rachaduras e tirar uma foto completa, ou ficar oculto por algum tempo (temos vários anos de bugs pendentes, e nosso rastreador de bugs é ruim em pesquisar :().

Agora, se você arquivar um bug de 100 + partes (como dicas de ajuda estão faltando em todos os 234 diálogos), então ele deve ser tratado como um projeto e ser dividido. No entanto, se for um bug de 3-4 partes, o desenvolvedor tentará corrigir todos os 3 ou 4 de uma só vez. É aqui que fica interessante. E se o codificador só consertar 3 ou 3,5 de 4? Após o teste, um novo bug deve ser arquivado e o antigo fechado? Se sim, então isso convida a práticas de programação desleixadas, onde perto o suficiente é bom o suficiente. Se o erro falhar, tudo terá que ser refeito e testado novamente. Agora ... e se a parte 1 é o tamanho de uma breadbox em termos de tamanho e risco, a parte 2 é mais parecida com um carro, a parte 3 é como uma casa e assim por diante:)

Ao dimensionar e priorizar esse bug (devo mencionar que usamos o Scrum), a parte da casa não foi notada - quem lê qualquer coisa além de um título de bug? Então, foi considerado um fruto fraco - baixo esforço, baixo risco, feliz usuário = alta recompensa. Mas nós fomos mordidos com um deles recentemente. O que parecia ser logicamente a mesma área, era na verdade código em estado de transição, onde estamos tentando depreciar um método de fazer as coisas, ou uma biblioteca para criar widgets com outro, novo e melhor. O problema é que nós tivemos que liberar a conversão média, então fizemos duas bestas muito diferentes parecidas. Nosso pessoal de QA não sabia disso, não se espera que eles saibam disso e, assim, em sua mente, esses são os mesmos problemas.

Precisamos ser amigáveis com o controle de qualidade - não para forçar demais ou com muita frequência, mas também para tentar dar um conjunto de heurísticas que ajudariam a decidir se um bug seria ou não arquivado. Suponho que o problema esteja nas ferramentas fracas, em que é difícil dividir e mesclar bugs. No entanto, como você lida com essas coisas em geral?

P.S. No Scrum - uma vez que você se comprometeu a consertar algo, provavelmente deve ser corrigido. Quebre essa regra muitas vezes e a disciplina será degradada.

    
por Job 11.12.2010 / 00:14
fonte

4 respostas

23

5 bugs = 5 relatórios de bugs; o fato de que todos eles podem ser consertados de uma só vez não é uma preocupação da QA.

em outras palavras, adivinhando que todos os 5 erros se originam do mesmo problema é colocar o carrinho à frente do cavalo.

    
por 11.12.2010 / 00:20
fonte
2

Em geral, eu concordo com @Steven Lowe, mas por outro lado eu não quero receber 10 relatórios de bugs, um para cada coisa que está errada. Eu acho que a abordagem correta é para o QA usar suas cabeças - se eles acham que é provável que as coisas sejam um grande bug, eles devem ter permissão para colocá-los em um relatório de bug. Quando o desenvolvedor os obtém, e descobre que alguns deles são um bug, e outros são outros, o desenvolvedor pode emitir um novo relatório de bug nas partes que ele não deseja corrigir agora e atualizar o antigo relatório de bug para cobrir apenas os bits que estão fixos.

Você terá que ir e voltar um pouco com o controle de qualidade sobre isso (porque eles realmente não sabem ao certo quando as coisas estão relacionadas e quando não estão), mas eu acho que você obterá o melhor resultado (sobrecarga administrativa mínima) fazendo com que o departamento de controle de qualidade use seu melhor julgamento e faça o preenchimento do desenvolvimento conforme necessário.

    
por 11.12.2010 / 19:14
fonte
1

Eu usaria um bug, mas se a correção inicial cobrir apenas parte dele, então a pergunta se tornará caso haja um novo bug aberto para essa parte, pois pode ser que o que se pensava ser corrigido de uma vez não seja realista ou algo novo pode ser introduzido e, portanto, deve ser um novo bug. A chave é tentar descobrir onde é que, "Neste caso, vamos fazer um novo bug", linha como não deveria ser que cada correção gera um novo bug, mas em alguns casos que podem fazer sentido para minha mente.

Meu problema com 5 relatórios de bugs é que isso pode significar muita sobrecarga administrativa que não vale a pena, pois alguns podem querer que cada correção seja feita em uma ramificação separada, o que pode ser um desperdício de tempo para minha mente . Uma vez que haja experiência suficiente, deve haver uma boa dose de precedência para ver onde está essa linha.

Para dar um exemplo mais específico, imagine um formulário com vários problemas de estilo, por exemplo, a borda não se alinha apropriadamente no IE7, no Firefox outra parte do formulário não se alinha corretamente e algumas outras coisas que são mais cosméticas, mas fazem com que o formulário não atenda à especificação. Cada questão deve ser registrada como um bug separado, o que poderia significar muito trabalho duplicado para QA e desenvolvimento, já que cada bug tem que ser criado, capturas de tela anexadas, etc. que não me parecem valer a pena se agrupadas em conjunto. Um bug pode ser melhor ao redor. Isso não tem nada a ver com saber o que é ou não está no código, mas sim como finamente dividir as coisas. Algumas pessoas podem gostar de dividir as coisas em pequenos pedaços, mas isso pode ser passivo-agressivo se a pessoa fizer isso apenas para irritar um desenvolvedor. Por exemplo, se alguém tiver que redefinir sua senha para "senha", você preferiria ter uma etapa para digitar cada caractere, uma a uma, ou é melhor assumir que a pessoa sabe como digitar caracteres consecutivos para que, em vez de 8 etapas? para digitar a nova senha, é apenas uma.

    
por 11.12.2010 / 00:25
fonte
0

Concordo que o QA não deve tentar adivinhar a natureza da relação entre os bugs. Se eles encontrarem 5 bugs, abra 5 bugs. Se eles provarem ter uma causa subjacente comum e consertarem, eles podem ser fundidos, ou pode-se fazer a referência canônica e os outros serem fechados, seja qual for.

    
por 11.12.2010 / 19:14
fonte