Como avaliar a qualidade de um produto de software

Question

Eu tenho um produto, X, que entregamos a um cliente, C todos os meses, incluindo correções de bugs, melhorias, novos desenvolvimentos etc.) A cada mês, sou solicitado a errar "garantir" a qualidade do produto.

Para isso utilizamos uma série de estatísticas obtidas nos testes que realizamos, tais como:

• taxa de reabertura (número de bugs reabertos/número de bugs corrigidos testados)
• nova taxa de bugs (número de novos bugs, incluindo regressões, encontrados durante o teste/número de bugs corrigidos testados)
• para cada nova melhoria, a nova taxa de bugs (o número de bugs encontrados para esta melhoria/número de mandays)

e várias outras figuras.

É impossível, por razões que não abordaremos, testar tudo sempre.

Então, minha pergunta é:

Como posso estimar o número e o tipo de bugs que permanecem no meu software?Que estratégias de teste devo seguir para ter certeza de que o produto é bom?

Sei que esta é uma questão em aberto, mas, ei, também sei que não existem soluções simples.

Obrigado.

Answer 1

Não acho que você possa realmente estimar o número de bugs em seu aplicativo.A menos que você use uma linguagem e um processo que permita provas formais, você nunca terá certeza.Provavelmente será melhor gastar seu tempo configurando processos para minimizar bugs do que tentando estimar quantos você tem.

Uma das coisas mais importantes que você pode fazer é ter uma boa equipe de controle de qualidade e um bom rastreamento de itens de trabalho.Talvez você não consiga fazer testes de regressão completos todas as vezes, mas se tiver uma lista das alterações feitas no aplicativo desde o último lançamento, seu pessoal (ou pessoa) de controle de qualidade poderá concentrar seus testes nas partes de o aplicativo que deverá ser afetado.

Outra coisa que seria útil são os testes unitários.Quanto mais você cobrir sua base de código, mais confiante poderá ter de que as alterações em uma área não afetaram inadvertidamente outra área.Achei isso bastante útil, pois às vezes mudo alguma coisa e esqueço que isso afetaria outra parte do aplicativo, e os testes de unidade mostraram o problema imediatamente.Os testes de unidade aprovados não garantem que você não quebrou nada, mas podem ajudar a aumentar a confiança de que as alterações feitas estão funcionando.

Além disso, isso é um pouco redundante e óbvio, mas certifique-se de ter um bom software de rastreamento de bugs.:)

Answer 2

A questão é quem exige que você forneça as estatísticas.

Se forem pessoas não técnicas, falsifique as estatísticas.Por "falso", quero dizer "fornecer números inevitavelmente sem sentido, mas reais" do tipo que você mencionou.

Se forem técnicos sem experiência em CS, eles devem ser informados sobre o problema da parada, que é indecidível e mais simples do que contar e classificar os bugs restantes.

Existem muitas métricas e ferramentas relacionadas à qualidade do software (cobertura de código, complexidade ciclomática, diretrizes de codificação e ferramentas que as aplicam, etc.).Na prática, o que funciona é automatizar o máximo possível de testes, fazer com que testadores humanos façam o máximo possível de testes que não foram automatizados e então orar.

Answer 3

Acho que manter a simplicidade é o melhor caminho a percorrer.Categorize seus bugs por gravidade e resolva-os em ordem decrescente de gravidade.

Dessa forma, você pode entregar a construção da mais alta qualidade possível (o número de bugs significativos restantes é como eu avaliaria a qualidade do produto, em oposição a algumas estatísticas complexas).

Answer 4

A maioria das metodologias ágeis aborda esse dilema com bastante clareza.Você não pode testar tudo.Você também não pode testá-lo um número infinito de vezes antes de liberá-lo.Portanto, o procedimento é confiar no risco e na probabilidade do bug.Tanto o risco quanto a probabilidade são valores numéricos.O produto de ambos fornece um número RPN.Se o número for menor que 15, você envia uma versão beta.Se você conseguir reduzi-lo para menos de 10, você envia o produto e envia o bug para ser corrigido em uma versão futura.

Como calcular o risco?

Se for um acidente, então é um 5 se for um acidente, mas você pode fornecer um trabalho, é um número menor que 5.Se o bug reduzir a funcionalidade, então é 4

Como calcular a probabilidade?

você pode reproduzi-lo toda vez que executar, é um 5.Se a solução alternativa fornecida ainda causar falha, menos de 5

Bem, estou curioso para saber se mais alguém está usando esse esquema e ansioso para saber sua experiência nisso.

Answer 5

Quanto tempo dura um pedaço de barbante?Em última análise, o que torna um produto de qualidade?Bugs dão alguma indicação que sim, mas muitos outros fatores estão envolvidos. A cobertura do teste unitário é um fator chave no IMO.Mas, na minha experiência, o principal fator que determina se um produto pode ser considerado de qualidade ou não é o bom entendimento do problema que está sendo resolvido.Muitas vezes o que acontece é que o 'problema' que o produto pretende resolver não é entendido corretamente e os desenvolvedores acabam inventando a solução para um problema que eles têm na cabeça, e não o problema real, assim 'bugs' são feitos .Eu sou um forte defensor da iteração Ágil desenvolvimento, dessa forma o produto é constantemente acessado contra o 'problema' e o produto não se afasta muito de seu objetivo.

Answer 6

As perguntas que ouvi foram: como faço para estimar os bugs no meu software?e quais técnicas devo usar para garantir que a qualidade seja boa?

Em vez de fazer um curso completo, aqui estão algumas abordagens.

Como faço para estimar os bugs em meu software?

Comece com o histórico, você sabe quantos encontrou durante o teste (espero) e quantos foram encontrados após o fato.Você pode usar isso para estimar o quão eficiente você é em encontrar bugs (DDR - Defect Detection Rate é um nome para isso).Se você puder mostrar que, por um período de tempo consistente, seu DDR é consistente (ou está melhorando), você poderá fornecer alguns insights sobre a qualidade do lançamento, adivinhando o número de defeitos pós-lançamento que serão encontrados quando o produto for lançado.

Que técnicas devo usar para garantir que a qualidade seja boa?

A análise da causa raiz de seus bugs apontará para componentes específicos que apresentam bugs, desenvolvedores específicos que criam códigos com bugs, o fato de que a falta de requisitos completos resulta em uma implementação que não corresponde às expectativas, etc.

Reuniões de revisão do projeto para identificar rapidamente o que foi bom, para que essas coisas possam ser repetidas e o que foi ruim e encontrar uma maneira de não fazer isso novamente.

Esperançosamente, isso lhe dará um bom começo.Boa sorte!

Answer 7

Parece que o consenso é que a ênfase deve ser colocada nos testes unitários.O rastreamento de bugs é um bom indicador da qualidade do produto, mas só é preciso conforme sua equipe de teste.Se você empregar testes unitários, ele fornecerá uma métrica mensurável de cobertura de código e testes de regressão para que você possa ter certeza de que não quebrou nada desde o mês passado.

Minha empresa depende de testes de nível de sistema/integração.Vejo muitos defeitos sendo introduzidos porque faltam testes de regressão.Acho que "bugs" em que a implementação dos requisitos pelo desenvolvedor se desvia da visão do usuário é uma espécie de problema separado que, como Dan e rptony afirmaram, é melhor resolvido pelas metodologias Agile.