Resolvendo quais erros fornecerão o maior custo benefício [fechado]

Eu queria ter uma idéia de categorizar os bugs com base em quão fácil é resolver e quanto benefício isso me proporcionará. por exemplo, se houver um erro que levará, por exemplo, uma hora (fechamento de arquivo duplo etc.) para resolver vs outro que demore um dia (falha de segmentação). Mas se a solução do primeiro bug não for muito importante, provavelmente vou trabalhar no segundo.

Existem trabalhos de pesquisa que categorizam bugs com base no custo-benefício ou métrica semelhante?

Digamos que seja possível categorizar os bugs com base nas características dos bugs, por exemplo, vulnerabilidade de segurança, erro de memória, erro lógico etc. Na outra dimensão, pode haver parâmetros como dificuldade (fácil, médio, difícil). Existem outras dimensões que eu deveria estar procurando. Para simplificar, posso assumir duas coisas:

1. Todo programador da equipe é igualmente capaz de resolver qualquer erro
2. Não há prazo

O sistema típico de rastreamento de bugs possui dois, talvez três campos, que identificam a relação custo-benefício:

1. Prioridade (atribuída pelo proprietário da empresa)
2. Gravidade (classificação do erro - crítico para baixo)
3. Horas estimadas (um palpite sobre quanto tempo levará para fazer)

Como você observa, isso identifica qual bug é o mais importante para se trabalhar.

O sistema apresentado em PEF / REV: Uma métrica multidimensional de rastreamento de bugs adiciona mais informações sobre os componentes de negócios e desenvolvedores ao custo-benefício dos bugs.

Todos os valores estão em uma escala de 1 .. N (o mesmo valor superior para cada um).

O PFE é identificado pela empresa:

• P ain - Quão doloroso é o bug
• E ffort - Quanto esforço é necessário para contornar o bug
• F requência - Quantas vezes o erro ocorrer

REV vem do desenvolvedor:

• R isk - Qual o risco da correção para o sistema
• E ffort - Quanto esforço está lá para corrigir o erro
• V erifiabilidade - Como é fácil verificar a correção de bug

Se, por exemplo, você tiver uma falha raramente ocorrida e fácil de solucionar (ative o salvamento automático), pode ser um PFE de 7,1,1 (pontuação 9). A fixação pode envolver uma alteração no módulo principal e um REV de 9,3,2 (pontuação 14).

Por outro lado, você pode ter um aborrecimento que está sempre lá (3,3,9 - escore 15) que possui uma correção trivial (1,1,3 - escore 5).

Neste exemplo, o aborrecimento parece ser uma coisa melhor em termos de custo / benefício.

O problema que você está descrevendo é muito comum e a melhor resposta pode ser "use seu instinto".

Normalmente, divido os bugs em três categorias: Falha, Irritante, Cosmético (eles podem ser chamados 1, 2, 3 - isso realmente não importa) e, em seguida, faço uma estimativa geral do tempo necessário para corrigir todos os bugs (todos os bugs devem tenha uma estimativa atualizada aproximada em todos os momentos).

Ao resolver bugs, Crashing> Annoying> Cosmetic e, em seguida, simplesmente faço um "trabalho mais curto primeiro" para obter o máximo de rendimento inicial possível.

Acho MUITO difícil calcular qualquer tipo de benefício financeiro direto para solucionar qualquer bug - a menos que seja um trabalho pago com escopo muito restrito.

Uma observação que você pode precisar é que você realmente cumpra o quinto ponto no The Joel Test - isso pode ser influenciado pelo tamanho da equipe e distribuição entre várias outras questões "locais" - mas geralmente é um sinal de boas práticas.

Outra consideração pode ser o tipo de organização de teste ou teste que descobre o bug ao tentar determinar o impacto e o custo do bug e correção. Os testes unitários ou funcionais podem apontar para algo no projeto que precisa ser alterado e, portanto, a correção precoce seria mais fácil e menos onerosa do que posteriormente. Os testes de sistema ou integração podem apontar para algo que afeta uma variedade maior de clientes. E o teste de padrões, embora geralmente não seja crítico para um grande subconjunto de clientes, pode levar a uma perda de certificação se não for corrigido e ter um impacto negativo nos negócios.

Dito isto, apenas porque uma organização de teste específica tem uma falha no teste não deve automaticamente tornar um bug "crítico". Por exemplo, pode haver uma tentação de dizer algo como "todos os testes do sistema devem passar antes do envio, portanto, qualquer teste do sistema que falha automaticamente resulta em um erro crítico / de alta gravidade". Esperamos que nenhuma organização faça essa afirmação (bons critérios de saída de teste são uma discussão diferente), mas o ponto é que a "gravidade" do bug deve ser julgada por seu impacto na imagem do cliente, produto ou empresa em vez de onde ou quando é descoberto.

Uma maneira possível de abordar isso é fazer uma distinção entre "severidade" e "urgência". Por exemplo, à medida que a data de lançamento se aproxima, pode haver pressão de tempo para determinar se um bug aparentemente de menor gravidade pode afetar um grande subconjunto de clientes, dando ao bug uma "urgência" maior e elevando o trabalho nesse bug acima de (alguns) outros em menos até que essa determinação possa ser feita. Um equilíbrio adequado entre os dois, juntamente com a experiência e o bom senso, ajudaria a direcionar onde tempo e esforço são gastos.

Além do que os outros disseram sobre a classificação de bugs, etc., considere também a possibilidade de verificar o acoplamento aferente (Ca) para determinar o nível de criticidade que um determinado bug pode representar. Se você tiver um bug em um módulo com uma alta contagem de Ca, talvez eu esteja tentando corrigi-lo primeiro, pois isso pode beneficiar outros componentes do sistema. O Ca ajuda a determinar o nível de responsabilidade, e os módulos responsáveis ​​com bugs prejudicam todo o aplicativo (leia mais sobre o Ca aqui: http://www.ibm.com/developerworks/java/library/j-cq04256/index.html )

Com isso em mente, tendemos a categorizar os bugs e colocá-los em prioridade com base em seu impacto no cliente. Seu cliente variará, mas tê-los envolvidos na discussão acabará determinando quais erros devem ser corrigidos em relação aos outros. Não é realmente científico, mas como uma equipe inteira, tendemos a chegar a um consenso sobre a prioridade e a categorização dos bugs, todo mundo tem uma opinião sobre os "grandes" (todos os participantes podem dar sugestões), e nós empilhamos e acumulamos a partir daí.

Você não pode determinar o custo real de todos os bugs. Alguns você pode, para muitos, é muito difícil quantificar. Por exemplo, digamos que você tenha um erro que resulta em todo o texto dos botões ligeiramente desalinhados. Isso faz com que o seu produto 1.0 pareça um pouco desleixado. Isso não causa uma falha no seu programa ou seus usuários perdem dados. Provavelmente um bug bem barato, certo?

Agora, e se todos os seus clientes perceberem esse problema e todos os revisores o mencionarem nas análises do seu produto. E se esse bug persistir da versão 1.0 para 1.1 e 1.2. Sua empresa agora pode ter a reputação de ser um pouco desleixada no controle de qualidade. Qual o custo desse bug simples em termos de possíveis perdas de vendas para sua empresa em futuros produtos? Ou como isso pode afetar uma revisão que seu produto recebe - ele pode atender perfeitamente às necessidades de seus clientes, mas recebe apenas 9 em 10 porque parece um pouco desleixado.

Portanto, você precisa não apenas considerar o custo de um bug específico em termos de quanto custa corrigir e seu impacto direto no usuário, mas também considerá-lo no contexto mais amplo de como isso afeta a percepção do seu produto. no mercado e como essa percepção afeta as vendas futuras.

Isso pode parecer absurdo, mas não é. No momento em que escrevo isso, você pode acessar outro site da Web que possui um artigo sobre como a Apple moveu o "1" no ícone do calendário por um pixel ou dois. Se você fizer uma pesquisa, verá vários artigos negativos sobre esse pequeno bug. Obviamente, isso não afetou diretamente a linha de fundo da Apple, mas eles se promoveram como o auge do bom design; portanto, ter um bug no design afeta essa percepção, mesmo que apenas um pouco.