Os desenvolvedores devem inserir erros no sistema de acompanhamento de bugs?

Se você descobrir um bug, não consigo pensar em nenhuma boa razão não para inseri-lo no sistema de acompanhamento de bugs, quer você o corrija ou não. É para isso que serve o sistema de rastreamento de bugs, afinal.

Em alguns casos, pode ser mais sensato denunciá-lo a uma pessoa de controle de qualidade que tenha mais experiência em lidar com o sistema, mas, em qualquer caso, o bug deve ser rastreado.

É possível que haja algum motivo, válido ou não, para que os desenvolvedores não digam bugs. Um possível motivo pode ser que o sistema de acompanhamento de bugs esteja visível para pessoas de fora, e ter muitos bugs relatados parece ruim. Essa é uma razão muito ruim, que deve ser abordada de alguma outra maneira que ainda permita que os bugs sejam rastreados. Pergunte ao seu chefe.

(Claro que se há um bug no código em que você ainda está trabalhando, e ele não aparece em nada liberado, não há necessidade de rastreá-lo no sistema, apesar de um comentário TODO na fonte código pode ser uma boa idéia.Para um caso extremo, "Este código não irá compilar porque eu ainda não digitei o ponto-e-vírgula no final desta linha" não é um bug reportável.)

Por que outros desenvolvedores não inserem bugs, você precisará perguntar a eles. Eles provavelmente deveriam.

Você deve inserir os erros no sistema de acompanhamento de bugs nos dois casos:

• quando o erro se refere diretamente ao código em que você está trabalhando,

• quando o erro está relacionado ao código no qual você não está trabalhando no momento ou à parte em que outro desenvolvedor trabalha.

Isso é essencial, já que o sistema de rastreamento de bugs é feito para ... rastrear bugs. Cada bug. Se você descobrir algo errado, não conserte. Documente-o através do sistema de rastreamento de bugs. Quando mais tarde, um cliente que estiver executando uma versão anterior do software informar um bug que seja uma duplicata exata, você poderá vinculá-lo ao seu relatório. Se você não tem nada para vincular, você perderá seu tempo (ou seu colega) procurando pelo bug em revisões anteriores, então tentará resolvê-lo e, finalmente, descobrirá que o bug já foi resolvido magicamente.

Isso também explica por que os freelancers devem usar o controle de versão e o sistema de acompanhamento de bugs: essas duas ferramentas não são apenas para equipes.

Não há motivo válido para não inserir um defeito no sistema de rastreamento de defeitos. Os únicos lugares em que vi correções de bugs aplicadas sem acompanhamento são porque o processo foi fundamentalmente quebrado. Se este for o caso, corrija o processo.

razões para não entrar são:

• O processo mede e pune com base no relatório de defeitos - não relate, não seja punido. Neste caso, deixe a organização
• O processo é um fardo - é preciso muito esforço e tempo para inserir um defeito e chegar ao ponto de corrigi-lo. O processo deve ser alterado para permitir que os desenvolvedores rastreiem rapidamente um bug leve através do processo de triagem / aceitação / correção.
• Alguns desenvolvedores são preguiçosos / desleixados / hackers que não se importam com o impacto das coisas que eles fazem nos outros. Recrute desenvolvedores profissionais.
• Eu sou uma banda de um homem, não vejo o ponto. Vá trabalhar para uma banda de 2 homens e você vai ...

Corrigir o erro imediatamente é provavelmente uma má ideia. Primeiro, alguém pode estar trabalhando na mesma correção, resultando em esforço duplicado, e também, dependendo da metodologia de desenvolvimento que você está seguindo, priorizar o que trabalhar em seguida (corrigir um bug ou implementar um novo recurso) é mais um decisão de gestão, em seguida, uma decisão de desenvolvimento.

A decisão não é clara e envolve compensações.

(alguns) PROS

O acompanhamento de erros é essencial para a comunicação, especialmente em grandes equipes. Um dos melhores benefícios de ter vários olhos no código é a capacidade de detectar problemas mais cedo, e esse benefício é perdido se os erros não forem registrados ou controlados enquanto você estiver desenvolvendo.

• Geralmente, os bugs são corrigidos com mais facilidade enquanto você já está em uma parte do código, trabalhando para compreendê-lo.
• Mesmo em equipes menores, há muitos benefícios a serem obtidos quando se pode listar bugs e progredir para corrigi-los - às vezes, o benefício moral é crucial mesmo em projetos de um homem.
• A detecção precisa de bugs pode ser muito difícil depois do fato - ver um bug no código pode economizar muito trabalho posterior no detetive, tentando descobrir onde o problema ocorreu originalmente.
• É bom para o seu desenvolvimento geral, como desenvolvedor, prestar atenção aos bugs que você vê, e adquirir o hábito de melhorar / limpar / ler criticamente o código

Registrar os erros como você os encontra é, em geral, um bom hábito de ter.

(alguns) CONS

Inserir bugs em um sistema de rastreamento de bugs pode ser oneroso e consome muito tempo, e pode ser realmente prejudicial para o trabalho de desenvolvimento - mais frequentemente, quando se trabalha em equipes grandes. Você pode ser esperado para:

• verifique se sua entrada é uma duplicata antes de inserir (isso pode até ser implícito, é desanimador inserir o bug na fila apenas para que ela seja fechada)
• fornecer casos de teste repetíveis para seu relatório
• aceite interrupções posteriores com perguntas sobre detalhes do bug, para aceitar / verificar uma correção quando escrita
• pense em informações não relacionadas que costumam ser coletadas em sistemas de acompanhamento de bugs, como qual produto é mais afetado, a prioridade do bug, etc.

Por vezes, o acompanhamento de erros não é o uso mais eficiente do seu tempo.

Estes são dois princípios gerais que podem ser difíceis de equilibrar - encontrar uma boa estratégia é um pouco de arte. Em situações como essas, eu acho que é melhor adotar uma heurística flexível, que eu ajuste conforme necessário para um determinado projeto, equipe, ambiente de trabalho e suas habilidades gerais. Minha estratégia geralmente segue um padrão como aproximadamente o seguinte:

• Sempre registre os problemas conforme você os vê ao longo do dia, em algum lugar. Talvez em um sticky, talvez em um arquivo ao lado. Talvez tudo que você registre seja um nome de arquivo e um número de linha, talvez mais. Não deixe que o problema interrompa demais sua atual linha de pensamento.

• Reserve um tempo no início de cada novo dia de trabalho, como parte de seu aquecimento para o trabalho, para lidar com os problemas. Eu levo de 10 a 15 minutos para analisar minha lista de problemas detectados no dia anterior e fazer qualquer um dos itens a seguir é o mais rápido:

  • Corrija o problema e confirme-o (provavelmente para correções ou erros de digitação de um liner). Se você não tem permissão para se comprometer sem um relatório de bug, crie um projeto paralelo para pequenos commits. Quando correções suficientes se acumulam no projeto paralelo, reserve as poucas horas necessárias para documentá-las e confirmá-las.
  • Registre o problema em um sistema de acompanhamento de bugs (para problemas óbvios que demoram mais para serem corrigidos, mas sem sobrecarga onerosa)
  • Registre o problema em um documento "para ver quando não está ocupado" (normalmente, adiciono um comentário do tipo "// TODO - este parece estar quebrado, corrija-o" na origem). Regularmente, tire um dia (eu tento uma vez por mês) para percorrer a lista e registrá-la conforme apropriado - solicitação de recurso, relatório de bug, discussão com o gerente, etc ...

Com o passar do tempo, achei todos os tipos de ajustes úteis. Por exemplo:

• Em ambientes mais rígidos, eu poderia apenas transferir o trabalho de relatório de erros para a equipe de testes - fazer com que um testador se reúna comigo por uma hora de vez em quando, entregar a lista de problemas e fazê-los exploração madeireira. Em ambientes onde os testes de registro são um grande negócio, geralmente o testador ficará satisfeito com o aumento gratuito de sua produtividade.
• Algumas equipes se recusam a permitir correções que não tenham um relatório de bug do cliente por trás delas. Eu manteria um projeto cheio de correções ao lado e, instantaneamente, os comprometeria quando o problema relevante fosse relatado por um cliente, para obter pontos de brownie gratuitos.
• Algumas equipes exigem que a pessoa que "possui" uma parte do código seja a única que executa as correções. Eu trataria o código "proprietário" como um líder de teste e se reuniria informalmente para entregar problemas ocasionalmente

Descobri que, em geral, à medida que você segue esse tipo de estratégia, cada vez mais seus colegas e outros membros da empresa passam a respeitar seu trabalho e o compromisso com a qualidade. Depois de bastante tempo, você terá o respeito e a autoridade necessários para otimizar todo o processo ao seu gosto. Fique atento a essas oportunidades e tome-as conforme apropriado.

Acredito que, se um desenvolvedor encontrar um bug que não esteja relacionado ao que ele está trabalhando e que ele não consertará, ele deverá ser inserido no sistema apenas para ter algum registro dele . Dessa forma, quando o controle de qualidade começa a testar (e eles ainda não estão consertados), você pode dar a eles os bugs da lista como "defeitos conhecidos", para que eles não comecem a relatar os mesmos erros.

Talvez outros desenvolvedores que acham que os bugs acompanhem o sistema por conta própria, caso planejem consertá-lo, mas, nesse caso, eles correm o risco de dois desenvolvedores encontrarem e consertarem o mesmo bug independentemente.

Gostaria de acrescentar que, mesmo que o bug já tenha sido corrigido (o que não deveria ter acontecido antes de gravá-lo em um rastreador de problemas), é uma boa ideia rastreá-lo.

Dessa forma, se a questão surgir novamente no futuro (as regressões acontecem!), é relativamente fácil reconhecer a questão como "já tratada" e ler como ela foi corrigida na primeira vez.

Por que isso? Como a maioria dos desenvolvedores analisa o problema que precisam levantar e o código que precisam escrever, é mais fácil não se incomodar.

Mas, se essa é a coisa certa a fazer depende do seu processo. Você tem uma equipe de QA? Você acha que eles se importam se você simplesmente mudar o código que não será rastreado? E quanto às revisões de código? Será que vai pular por essa rachadura? E o negócio? Eles precisam saber que você corrigiu um bug para que eles não criem o mesmo mais tarde?

E os outros desenvolvedores? E se eles consertarem isso de uma maneira diferente ao mesmo tempo? E se eles encontrarem um bug semelhante mais tarde e tudo que você pode fazer é dizer "oh, caramba, eu sei que nós tivemos algo assim antes - agora o que foi?"

Existem cerca de um milhão de razões para registrar bugs no sistema de rastreamento de bugs. Se tiver certeza de que você não acertou nenhum desses problemas, não se incomode. Mas se você não tiver certeza, você deve gravá-lo, mesmo que a maioria das pessoas não o faça.

A programação é um trabalho complexo fundamentalmente. Os bugs são complexos. então eu costumava avaliar um bug por dois fatores:

1. Com que frequência esse tipo de bug pode aparecer novamente no futuro? Se esta estimativa é exata ou não, mantenha a estimativa.
2. Quando esse tipo de bug aparece novamente, é fácil de entender? Isso é preciso quando você analisa esse bug e conserta-o.

Eu classificaria um bug em um dos seguintes tipos:

1. É provável que apareça novamente no futuro e seja fácil de entender
2. É provável que apareça novamente no futuro, mas difícil de entender
3. Raramente aparecem novamente no futuro e são fáceis de entender
4. Raramente aparecem novamente no futuro, mas difíceis de entender

No caso 1, um livro de receitas ou FAQ é um bom dispositivo para a equipe corrigir esses erros no futuro.

No caso 2, um registro elaborado e compreensível é o necessário para a equipe porque é um desperdício de esforço se outro programador suportar esses erros novamente. Por exemplo: vazamento de memória.

No caso 3, eu acho que não é grande coisa que não há nada para ser gravado porque você não vai gastar muito tempo para consertar um bug fácil. Por exemplo, um erro de digitação para o id do elemento em HTML.

No caso 4, esses bugs criam um dilema. É necessário algum tempo para escrever um registro elaborado e compreensível para descrever esses erros. Mas esse registro raramente é usado no futuro. Sem um registro, no entanto, a aparição desses bugs seria uma luta novamente. Por exemplo, esses bugs aparecem por causa do vírus de computador no computador de alguém.

Claro que você deve entrar. Ou, pelo menos, denuncie ao seu pessoal de QA se esse é o seu processo normal.

Mesmo que você conserte o bug sozinho, será necessário um registro da alteração para que ela possa ser testada para garantir que a correção realmente funcione e que não houve uma regressão. Também é possível que um usuário relate o bug em algum momento, e se ele estiver no sistema e marcado como fixo, as pessoas de suporte poderão informá-lo de que ele já foi corrigido.

Na verdade, você deve gravá-los no sistema e, caso não seja praticado, é bom começar.

No passado eu fazia parte de uma equipe de produtos e estávamos na versão beta de um novo produto e às vezes encontramos ocasionalmente bugs que, naquele momento, anotávamos e remetíamos para as respectivas pessoas que manipulavam os módulos (nós tínhamos um sistema de rastreamento de bugs, mas não pensávamos em empurrá-los para lá). Mais tarde, quando os dias foram passando, os itens no correio começaram a ser ignorados por causa de outras prioridades e, eventualmente, levaram a algumas noites sem dormir.

Então, bum dia, Nirvana! Por que não estamos usando o rastreador de bugs, mesmo que você encontre algo que pareça um bug e que seja possível que não seja um (seu pensamento sobre o processo está errado / falho). Ele, pelo menos, faz parte da lista que poderia então ser testado e mais importante de todos os um feedback sobre o porquê é crítico ou por outro lado é perfeito e é assim que deve funcionar por razões 1 ... 2 ....

Agora você tem a lista e também para aqueles que não entenderam algumas partes do aplicativo, eles têm o feedback com base no qual podem esclarecer seus pensamentos. Uma situação ganha-ganha.

Assumindo o código já testado (e particularmente se lançado) de maneira absoluta.

Existem várias razões para isso:

Memory - É muito improvável que o sistema esqueça o bug, qualquer desenvolvedor pode.

Métricas - O número de bugs encontrados, fechados e o tempo gasto podem ser boas métricas fáceis de capturar para informar como a qualidade do seu código está progredindo

Urgência - Pode parecer a coisa mais importante do mundo para o desenvolvedor, entretanto o tempo gasto corrigindo esse problema pode ser melhor gasto em algo que os usuários finais querem primeiro (veja também memória ).

Duplicação - Talvez ele já tenha sido visto e esteja sendo examinado / consertado por outra pessoa. Alternativamente, talvez tenha caído na falta da regra de urgência e sido adiada. É claro que o fato de você tê-lo encontrado novamente não significa apenas que não deveria ser feito, isso pode significar que (como continua aparecendo) isso é agora mais urgente para corrigir.

Análise de causa raiz - O erro mais fácil de corrigir é aquele que nunca esteve lá. Pode ser que a equipe esteja analisando esse bug para descobrir como ele surgiu. Isso é definitivo, não para punir o responsável (que nunca ajuda), mas para descobrir como a situação pode ser evitada no futuro.

Análise de impacto mais ampla - O bug mais barato para encontrar é o que você conhecia antes de encontrá-lo. Observando esse bug (particularmente após a análise da causa raiz), pode ficar claro que esse problema pode existir em outros locais do código. Como resultado, a equipe pode optar por encontrá-lo antes que ele levante sua cabeça feia em um momento mais embaraçoso.

A quantidade de tempo gasto com eles (se houver) depende muito da maturidade e do nível de qualidade do código. É provável que a análise de causa raiz seja exagerada para uma pequena equipe que trabalha com o código de demonstração, mas uma equipe grande em desenvolvimento crítico para os negócios provavelmente precisará aprender as lições de maneira eficaz e eficiente.

A partir da experiência, existem dois motivos amplos pelos quais os desenvolvedores evitam usar a ferramenta:

1. A ferramenta de manipulação de bugs e / ou processo é percebida como muito pesada para o desenvolvimento
2. Os desenvolvedores acham o desafio mental de consertar o bug mais interessante do que o material em que estão trabalhando atualmente.

O item 1 implica que um sistema melhor / mais simples pode ser necessário; ou, alternativamente, uma justificativa mais convincente do sistema existente pode estar em ordem.

O item 2 deve ser um sinal de alerta útil para o líder de desenvolvimento sobre alocações de tarefas atuais.

Concordo principalmente com o FrustratedWithFormsDesign, mas acho que é ainda mais claro se a questão for dividida em duas áreas:

• Relatório de bugs.
• Correção de erros.

Estes são frequentemente tratados como sendo os mesmos e separá-los quase certamente ajudarão muito.

Estes podem ser manipulados com: Relatório de bugs: - coloque-o no sistema, como todos dizem.

Correção de erros: - A cada semana ou duas (ajuste ao seu cronograma de desenvolvimento, etc.) todos se reúnem no projeto e decidem o que deve ser corrigido, por quem, etc. Isso foi todo mundo na mesma página e pode ver O que precisa ser feito. Em Agile Development, esta é a reunião de Planejamento da Sprint.

Uma boa ferramenta que as pessoas querem usar também faz uma grande diferença. Eu gosto do Pivotal Tracker e ele passou no meu teste de 'ferramenta realmente útil' quando comecei a usá-lo apenas para acompanhar as coisas que eu quero fazer ou corrigir em meus próprios projetos privados!

Se você vir alguma coisa, diga alguma coisa!

Eu até insiro relatórios de bugs sobre meus próprios módulos porque não quero interromper minha tarefa atual. E eu posso garantir que todos os passos para se reproduzir estão incluídos: -)

E é ainda melhor quando alguém pode ver que você listou algo como um bug conhecido. Eles gostam de saber que alguém o encontrou também.

Acho que isso é mais uma questão política do que uma pergunta sobre a melhor prática.

• a entrada do bug culpa alguém?
• o cliente pode ler as entradas de bugs e vê que existem erros adicionais. Isso é um problema de reputação para sua empresa?
• esse é realmente um bug ou um recurso que você não conhece?
• quem pagará a correção de erros?

Na minha opinião, é uma boa prática adicionar erros não triviais ao sistema de acompanhamento, mas a gerência precisa decidir como lidar com isso.

Para casos não triviais, você não deve corrigir o problema sem consultar outra pessoa para garantir que

• isso é realmente um bug e não um recurso
• mais alguém pode testar a correção e fazer com que a correção não introduza um novo bug, caso contrário (regressão)