-
Endereço original: Por que os bugs não são corrigidos
Autor: Alan Page, Diretor de Excelência em Engenharia de Teste da Microsoft, coautor do livro How We Test Software at Microsoft (traduzido em chinês como "Microsoft's Software Testing Way").
Tradução: Lu Yueli, Lu Mengyan, Wang Hong
Ultimamente tenho encontrado cada vez mais pessoas que estão surpresas com o lançamento de um produto com bugs. O que me surpreendeu foi que muitas dessas pessoas eram testadores de software e pensei que já soubessem disso. Sugiro que você leia primeiro o artigo anterior (mas excelente) de Eric Sink. Não tenho certeza de quanto mais posso contribuir para este tópico, mas quero tentar.
Muitos bugs não valem a pena consertar. “Você é um testador?”, você gritará para mim, “Os testadores são os guardiões da qualidade do produto”. Posso repetir novamente (se necessário), muitos bugs não valem a pena consertar. "Deixe-me dizer por quê. Na maioria dos casos, consertar um bug requer alterar o código. E alterar o código requer um investimento de recursos (tempo) e introduz riscos. Isso é uma droga, mas é verdade. Às vezes, se o risco e o investimento forem distantes superam o valor de consertar os bugs, então não vamos corrigi-los.
Nossa decisão sobre consertar um bug não é, e não deveria ser, baseada na "sensação". Gosto de usar o conceito de “dor do usuário” para me ajudar a tomar decisões. Eu uso três fatores principais para considerar e identificar a "dor do usuário":
1. Gravidade - Que impacto esse bug terá - travará todo o programa? Isso fará com que as informações do usuário sejam perdidas? Ou não é tão sério? Existe uma solução mais fácil? Ou é apenas uma questão irrelevante?
2. Frequência – Os usuários encontram esse problema com frequência? Faz parte do fluxo de trabalho principal do programa? Ou está oculto em um recurso que não é comumente usado? Pequenos problemas que existem nas partes mais usadas do programa provavelmente precisarão ser corrigidos, enquanto alguns grandes problemas que existem nas partes menos usadas do programa podem ser deixados de lado.
3. Impacto nos clientes – Se você fez bem sua lição de casa, já deve saber quem são seus clientes e quantos (ou quantos você espera ter) usuários haverá em cada um de seus grupos de clientes. Então você precisa avaliar se esse problema afetará todos os usuários ou apenas algumas pessoas. Se você puder acompanhar como os clientes usam seu produto, poderá obter dados mais precisos.
Os três fatores acima constituem uma fórmula. Atribua uma faixa de valores a cada um dos fatores acima e faça alguns cálculos – você pode somar, multiplicar ou adicionar pesos diretamente com base em sua aplicação e fatores de mercado. Por exemplo, precisamos apenas realizar a adição e atribuir um intervalo numérico de 10 pontos para cada bug.
Bug nº 1: Por exemplo, é um bug que trava o programa (10 pontos), existe na maior parte do programa (10 pontos) e afeta 80% dos clientes (8 pontos), então esse bug causa "user pain" "O volume é de 28 pontos e apostamos que vamos consertar.
Bug #2: É apenas um bug de arranjo (2 pontos), aparece na janela secundária (2 pontos), e a parte do programa onde o bug está localizado só será usada em versões mais antigas (2 pontos). Portanto, o valor de "dor do usuário" desse bug é de 6 pontos e provavelmente não iremos corrigi-lo.
Infelizmente, muitas situações não são tão simples como as acima. O bug nº 3 é um problema de perda de dados (10 pontos) que existe na maior parte de um aplicativo, mas só falha sob certas circunstâncias (5 pontos) (a propósito, os dados são subjetivos). A pesquisa do cliente prova que raramente é usado (2 pontos). Portanto, seu valor de “dor do usuário” é de 17 pontos. Este é um dado ambíguo, que pode ser modificado ou não. Por um lado, o investimento necessário para corrigi-lo pode não valer a pena, mas desde que o problema seja compreendido e não tenha pontos cegos, ignorar o bug é provavelmente a abordagem correta.
Por outro lado, você deve compará-lo com outros bugs do sistema. Aplicamos o efeito "Janela Quebrada" aqui - se houver muitos bugs de limite médio no aplicativo, a qualidade do produto (ou pelo menos a percepção de qualidade) será bastante afetada. Ao considerar cada bug no sistema, você também deve considerar outros bugs (conhecidos) no sistema e usar isso para analisar e decidir quais bugs precisam ser corrigidos e quais não valem a pena consertar.
Na verdade, é uma coisa muito ruim ter bugs em software lançado oficialmente - mas com base em nossas ferramentas e linguagens de desenvolvimento existentes, ainda não encontramos uma solução mais razoável.
Reabastecer:
Enquanto escrevo isto, acho que estou perdendo um quarto fator na fórmula: data de lançamento. Este fator também desempenha um papel fundamental na decisão de corrigir ou não corrigir um bug conforme a data de lançamento se aproxima. No entanto, não tenho certeza se esse é o quarto fator, nem qual é o limite para a quantidade de "dor do usuário" necessária para corrigir um bug próximo ao lançamento.