Os desenvolvedores devem inserir bugs no sistema de rastreamento de bugs?

Durante o desenvolvimento (recursos ou correções de erros), às vezes descubro bugs que não estão diretamente relacionados ao que estou trabalhando. O que devo fazer nessa situação. Apenas conserte? Tente se lembrar de corrigi-lo mais tarde? Escreva em algum lugar? Ou inseri-lo no sistema de rastreamento de bugs?

Geralmente, eu o insiro no sistema de rastreamento de bugs e deixo o processo se desenvolver (por exemplo, triagem, atribuição, etc.). No entanto, eu quase nunca vi outro desenvolvedor inserir um bug. (Por que é que?)

Se você descobrir um bug, não consigo encontrar um bom motivo para não inseri-lo no sistema de rastreamento de erros, corrigido ou não. Afinal, é para isso que serve o sistema de rastreamento de bugs.

Em alguns casos, pode fazer mais sentido denunciá-lo a uma pessoa com QA com mais experiência em lidar com o sistema, mas, em qualquer caso, o bug deve ser rastreado.

É possível que exista algum motivo, válido ou não, para que os desenvolvedores não estejam inserindo bugs. Um possível motivo pode ser o fato de o sistema de rastreamento de bugs ser visível para quem está de fora, e ter muitos bugs relatados parece ruim. Esse é um motivo muito ruim, que deve ser tratado de alguma outra maneira que ainda permita o rastreamento de bugs. Pergunte ao seu chefe.

(É claro que, se houver um bug no código em que você ainda está trabalhando, e ele não aparecer em nada que foi lançado, não será necessário rastreá-lo no sistema, embora um comentário TODO no código-fonte possa ser uma boa idéia. Para um caso extremo, "Este código não será compilado porque ainda não digitei o ponto e vírgula no final desta linha" (não é um bug reportável))

Quanto ao motivo pelo qual outros desenvolvedores não inserem bugs, você precisará perguntar a eles. Eles provavelmente deveriam.

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

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

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

Isso é essencial, pois o sistema de rastreamento de bugs é feito para ... rastrear bugs. Todo bug. Se você descobrir algo errado, não conserte. Documente através do sistema de rastreamento de bugs. Quando mais tarde, um cliente executando uma versão anterior do software relatará um erro duplicado exato, você poderá vinculá-lo ao seu relatório. Se você não tiver nada com o qual vincular, perderá seu tempo (ou seu colega) procurando pelo bug nas revisões anteriores, tente 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 rastreamento de erros: 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 onde vi correções de erros aplicadas sem rastreamento são porque o processo foi fundamentalmente interrompido. Se for esse o caso, corrija o processo.

Os motivos 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. Nesse 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 fazem nos outros. Recrute desenvolvedores profissionais.
• Eu sou uma banda de um homem, não entendo o ponto. Vá trabalhar para uma banda de 2 homens e você irá ....

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

A decisão não é clara e envolve trocas.

(alguns) PROS

O rastreamento de bugs é essencial para a comunicação, especialmente em equipes grandes. Um dos melhores benefícios de ter vários olhos no código é a capacidade de detectar problemas mais cedo, e esse benefício será perdido se os bugs não forem registrados ou rastreados durante o desenvolvimento.

• Freqüentemente, os bugs são corrigidos com mais facilidade enquanto você já faz parte do código, trabalhando para entendê-lo.
• Mesmo em equipes menores, há muitos benefícios em termos de moral, ao ser capaz de listar bugs e progredir na correção deles - às vezes o benefício de moral é crucial, mesmo em projetos individuais.
• A detecção precisa de erros pode ser muito difícil após o fato - ver um erro no código pode economizar muito trabalho posterior como detetive, tentando descobrir onde o problema ocorreu originalmente.
• É bom que o seu desenvolvimento geral, como desenvolvedor, preste atenção aos bugs como você os vê e adquira o hábito de melhorar / limpar / ler o código de forma crítica

Registrar erros como você os encontra é, geralmente falando, um bom hábito.

(alguns) CONS

A inserção de bugs em um sistema de rastreamento de bugs pode ser onerosa e demorada, e pode ser realmente prejudicial ao trabalho de desenvolvimento - mais frequentemente quando se trabalha em grandes equipes. Você pode:

• verifique se sua entrada é duplicada antes de entrar (isso pode até estar implícito, é desencorajador inserir seu bug na fila apenas para fechá-lo)
• forneça casos de teste repetíveis para o seu relatório
• aceite interrupções posteriores com perguntas sobre detalhes de erros, para aceitar / verificar uma correção quando escrita
• pense em informações não relacionadas que geralmente são coletadas em sistemas de rastreamento de bugs, como qual produto é provavelmente o mais afetado, a prioridade do bug, etc.

Às vezes, o rastreamento de bugs não é apenas o uso mais eficiente do seu tempo.

Esses 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, acho melhor adotar uma heurística flexível, que ajusta conforme necessário para um determinado projeto, equipe, ambiente de trabalho e suas habilidades gerais. Minha estratégia geralmente segue um padrão semelhante ao seguinte:

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

• 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. Levo de 10 a 15 minutos para percorrer minha lista de problemas detectados no dia anterior e fazer o que for mais rápido:

  • Corrija o problema e confirme-o (provavelmente para correções ou erros de digitação). Se você não puder confirmar sem um relatório de erro, crie um projeto paralelo para pequenas confirmações. Quando correções suficientes se acumulam no projeto paralelo, leve as poucas horas necessárias para documentá-las e confirmar.
  • Registre o problema em um sistema de rastreamento de erros (para problemas óbvios que demoram mais para serem corrigidos, mas sem sobrecarga onerosa)
  • Registre o problema em um documento "para olhar quando não estiver ocupado" (normalmente adiciono um comentário do tipo "// TODO - isso parece quebrado, corrija-o" à fonte). Tire um dia regularmente (eu tento uma vez por mês) para percorrer a lista e registrá-la conforme apropriado - solicitação de recurso, relatório de bug, discutir com o gerente, etc.

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

• Em ambientes mais rígidos, eu posso simplesmente descarregar o trabalho de relatório de erros para a equipe de teste - fazer com que um testador se encontre comigo por uma hora de vez em quando, entregue a lista de problemas e faça o registro. Em ambientes em que os testes de registro são muito importantes, 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 erro do cliente. Eu mantinha um projeto cheio de correções paralelas e as comprometia instantaneamente quando o problema relevante era relatado por um cliente, para pontos de brownie gratuitos.
• Algumas equipes exigem que a pessoa "proprietária" de um pedaço de código seja a que executa as correções. Eu tratava o código "proprietário" como um líder de teste e me encontrava informalmente para resolver problemas ocasionalmente

Acho que, geralmente, à medida que você segue esse tipo de estratégia, mais e mais colegas e outros membros da empresa começam a respeitar seu trabalho e o compromisso com a qualidade. Depois de um tempo suficiente, você terá o respeito e a autoridade necessários para otimizar todo o processo ao seu gosto. Fique atento a essas oportunidades e leve-as conforme apropriado.

Acredito que, se um desenvolvedor encontrar um bug que não esteja relacionado ao que está funcionando e que não consertará, ele deve inseri-lo no sistema apenas para ter algum registro dele. Dessa forma, quando o controle de qualidade começa a testar (e eles ainda não foram corrigidos), você pode atribuir a eles os erros desta lista como "defeitos conhecidos" para que eles não comecem a relatar os mesmos erros.

Talvez outros desenvolvedores que encontrem bugs o acompanhem por conta própria se planejarem consertá-lo, mas nesse caso correm o risco de 2 desenvolvedores encontrarem e corrigirem o mesmo bug independentemente.

Eu acrescentaria 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 controlá-lo.

Dessa forma, se o problema surgir novamente no futuro (ocorrem regressões!), É relativamente fácil reconhecer o problema como "já tratado" e ler como ele foi corrigido pela primeira vez.

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

Mas, se é a coisa certa a fazer, depende do seu processo. Você tem uma equipe de controle de qualidade? Você acha que eles se importam se você mudar o código que não será rastreado? E as revisões de código? Será que vai pular por esse crack? E o negócio? Eles precisam saber que você corrigiu um bug para que eles não aumentem o mesmo posteriormente?

E os outros desenvolvedores? E se eles o corrigirem de uma maneira diferente ao mesmo tempo? E se eles encontrarem um bug semelhante mais tarde e tudo o que você puder fazer é dizer "oh, droga, eu sei que já 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 você tem certeza de que não encontrou nenhum desses problemas, não se preocupe. Mas se você não tiver certeza, deve gravá-lo, mesmo que a maioria das pessoas não o faça.

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

1. Quantas vezes esse tipo de erro pode aparecer novamente no futuro? Se essa estimativa é precisa ou não, continue fazendo estimativas.
2. Quando esse tipo de erro aparece novamente, é fácil entender? Isso é preciso quando você analisa esse bug e o corrige.

Eu classificaria um bug em um dos seguintes tipos:

1. É provável que apareça novamente no futuro e fácil de entender
2. É provável que apareça novamente no futuro, mas difícil de entender
3. Raramente apareça novamente no futuro e fácil de entender
4. Raramente apareça novamente no futuro, mas difícil 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 é necessário para a equipe, pois é um desperdício de esforço se outro programador suportar esses erros novamente. Por exemplo: vazamento de memória.

No caso 3, acho que não é grande coisa que não resta nada para registro, porque você não gasta muito tempo para consertar um bug fácil. Por exemplo, um erro de digitação para a identificação do elemento em HTML.

No caso 4, esses erros 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, o aparecimento de tais erros seria uma luta novamente. Por exemplo, esses erros aparecem devido a vírus de computador no computador de alguém.

Claro que você deve inseri-lo. Ou, pelo menos, relate ao seu pessoal de controle de qualidade se esse é seu processo normal.

Mesmo se você apenas corrigir o bug, desejará um registro da alteração para que possa ser testada para garantir que a correção realmente funcione e que não tenha ocorrido uma regressão. Também é possível que um usuário possa relatar o bug em algum momento e, se ele estiver no sistema e marcado como corrigido, seu pessoal de suporte poderá dizer a ele que ele já foi solucionado.

Na verdade, você deve gravá-los no sistema e, caso isso 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, encontrávamos bugs que, naquele momento, costumávamos anotar e enviar para as respectivas pessoas que manipulavam os módulos (tínhamos um sistema de rastreamento de bugs, mas não pensamos em empurrá-los para lá). Mais tarde, quando os dias passaram, os itens no correio começaram a ser ignorados por causa de outras prioridades e que acabaram levando a algumas noites sem dormir.

Então, bata um dia, Nirvana! Por que não estamos usando o rastreador de bugs, mesmo se você encontrou algo que parece um bug e pode ser possível que não seja um (seu pensamento sobre o processo está errado / com defeito). Pelo menos, faz parte da lista que poderia ser testada e, o mais importante, é um feedback sobre por que é crítico ou, por outro lado, é perfeito e é assim que deve funcionar devido às 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.

Supondo absolutamente seu código já testado (e particularmente se lançado).

Há várias razões para isso:

Memória - É improvável que o sistema esqueça o bug, qualquer desenvolvedor pode.

Métricas - O número de bugs encontrados, encerrados 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. No entanto, o tempo gasto corrigindo esse problema pode ser melhor gasto em algo que os usuários finais desejam primeiro (consulte também memória).

Duplicação - Talvez já tenha sido detectado e esteja sendo examinado / corrigido por outra pessoa. Como alternativa, talvez tenha infringido a regra de urgência e tenha sido adiada. É claro que o fato de você ter encontrado novamente não significa apenas que não deve ser feito, pode significar que (à medida que o processo avança) agora é mais urgente de corrigir.

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

Análise de impacto mais amplo - O bug mais barato a ser encontrado é o que você conhecia antes de encontrá-lo. Observando esse bug (principalmente depois de fazer a análise da causa raiz), pode ficar claro rapidamente que esse problema pode existir em outros locais do código. Como resultado, a equipe pode optar por encontrá-lo antes de levantar a cabeça feia em um momento mais embaraçoso.

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

Por experiência, há dois motivos principais que os desenvolvedores evitam usar a ferramenta:

1. A ferramenta e / ou processo de tratamento de erros é percebida como muito pesada para o desenvolvimento
2. Os desenvolvedores acham o desafio mental de corrigir o bug mais interessante do que as coisas em que estão trabalhando atualmente.

O item 1 implica que um sistema melhor / mais simples possa 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 as alocações de tarefas atuais.

Concordo principalmente com FrustratedWithFormsDesign, mas acho que fica ainda mais claro se o problema todo é dividido em duas áreas:

• Relatório de Bug.
• Corrigindo erro.

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

Eles podem ser tratados com: Relatório de erros: - coloque-o no sistema, como todos dizem.

Correção de bug: - 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. ser feito. No Desenvolvimento Ágil, esta é a reunião de Planejamento da Sprint.

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

Se você vir algo, 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 posso garantir que todas as etapas para reproduzir estão incluídas :-)

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.

Eu acho que isso é mais uma questão política do que uma questão de melhores práticas.

• a entrada de bug culpa alguém?
• o cliente pode ler entradas de erros e vê que há erros adicionais. Esse é um problema de reputação para sua empresa?
• isso é realmente um bug ou um recurso que você não conhece?
• quem estará pagando a correção?

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

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

• isso é realmente um bug e não um recurso
• alguém pode testar a correção e deixar claro que ela não introduz um novo bug;