Quando você para de testar?

Question

Na sua prática, que medidas você usa para saber quando é hora de parar de testar um aplicativo e movê-lo para produção?

Answer 1

Para projetos na minha organização, as medidas que normalmente utilizo são as seguintes:

• Sem problemas de Gravidade 1 (interruptor de exibição)
• Sem problemas de Gravidade 2 (funcionalidade principal prejudicada)
• Número aceitável de problemas de gravidade 3 (funcionalidade secundária)

"Número aceitável" é naturalmente um número muito fraco, dependendo do tamanho do aplicativo, etc.etc.

Assim que essas pré-condições forem atendidas, realizarei uma reunião com todas as partes interessadas (líder de controle de qualidade, líder de desenvolvimento, líder de suporte de aplicativo, etc.) e analisarei a lista de problemas pendentes e garantirei que haja acordo sobre a gravidade atribuída a questões pendentes.Depois de confirmar que não há problemas pendentes de Sev 1 e Sev 2, receberei chamadas "Aprovado/Não Avançado" de cada parte interessada.Se todos disserem "Vá", sinto-me confortável em passar para a Produção.Se pelo menos uma parte interessada disser “Não avançar”, examinamos as razões para “Não avançar” e, se necessário, tomamos medidas para resolver os problemas por trás disso.

Em projetos menores, o processo pode ser mais simplificado e, se for apenas uma operação individual, seu conjunto de pré-condições pode ser muito mais simples, ou seja,"o aplicativo oferece um benefício razoável, embora tenha um número (aparentemente) aceitável de bugs - vamos divulgá-lo!".Contanto que o benefício fornecido pelo aplicativo supere o incômodo dos bugs, especialmente se você estiver seguindo a diretriz de "lançar cedo e com frequência", isso pode funcionar para você.

Answer 2

Primeiro, você nunca para de testar.Quando você terminar o teste e você lançá-lo, tudo isso significa que seus usuários estão testando em vez de você.

Segundo, quando seus scripts de teste abrangentes passarem com um nível aceitável de falha, você estará pronto para seguir em frente.

Finalmente, isso é altamente específico para o seu caso.Em alguns projetos, temos um período de teste beta de 3 semanas, onde muitas pessoas invadem o sistema antes que a menor das alterações possa ser implementada.Em outras áreas (menos críticas), pequenas alterações podem ser implementadas apenas com a aprovação de outro desenvolvedor.

Answer 3

Uma metodologia de teste interessante que sempre quis experimentar é a 'propagação de erros'.A ideia é que uma pessoa insira bugs intencionais no sistema que se enquadram em diferentes categorias.

Por exemplo:

• Erros cosméticos, ortográficos, etc.
• Erros não críticos
• Erros críticos e falhas
• Problemas de dados.Nenhum erro ocorre, mas algo mais profundo está errado com os resultados.
• etc.

O 'semeador' documenta exatamente o que foi alterado para inserir esses bugs para que possam ser revertidos rapidamente.À medida que a equipe de teste encontra os bugs propagados, eles também encontram bugs reais, mas não sabem a diferença.Em teoria, se a equipe de teste encontrar 90% dos erros críticos propagados, então provavelmente encontrará um número proporcional de erros críticos reais.

A partir dessas estatísticas, você pode começar a fazer julgamentos sobre quando é aceitável ter uma liberação.É claro que isso não seria nem de longe infalível devido à natureza aleatória dos bugs encontrados (reais ou propagados), mas provavelmente é melhor do que não ter ideia de quantos bugs você pode estar lançando.

Answer 4

No meu local de trabalho, uma métrica que às vezes é usada é que testamos o suficiente quando começamos a encontrar bugs antigos e não relatados que estiveram presentes nas últimas versões do nosso produto.A ideia é que se esses são os bugs que encontramos durante os testes, e esses bugs estão presentes há anos sem que um cliente reclame deles, então provavelmente estaremos seguros para enviá-los.

Claro, você também tem todos os testes manuais, testes automatizados, fazendo com que os desenvolvedores usem o produto, betas e testes contínuos, mas usando quantos bugs estamos encontrando agora que estiveram presentes, mas não relatados, em versões anteriores era uma ideia nova para mim quando a ouvi pela primeira vez.

Answer 5

Quando todos os principais obstáculos do show tiverem desaparecido.

Sério, você deve fazer um teste de aceitação do usuário e permitir que seus usuários usem seu sistema e descubra se está tudo certo para eles.Se isso não for prático, faça um beta fechado com usuários selecionados que se assemelhem ao seu público-alvo.

É impossível encontrar realmente todos os bugs no seu sistema, então às vezes a única regra real é apenas envie.

Answer 6

mharen,

Acho que se você tiver testes automatizados abrangentes, é totalmente irresponsável enviar software, a menos que todos deles passam.Testes automatizados significam que essas são áreas que são funcionalidades essenciais ou bugs que ocorreram no passado e que você conhece e que podem ser corrigidos para passar no teste.Será irresponsável enviar software que não passe 100% em seus testes automatizados.

Answer 7

Jon,

Eu não quis dizer que os scripts de teste implicam automatizado testando.Eu estava me referindo à abordagem mais tradicional de uma lista passo a passo do que testar e como testar.

Dito isto, não concordo que todos os testes automatizados devam ser aprovados.Tudo depende da gravidade e prioridade.Em um projeto grande, podemos ter desenvolvedores escrevendo testes que falham com base em problemas relatados pelos usuários.Como não podemos corrigir todos os bugs em todas as versões, é fato que alguns testes simplesmente não serão aprovados.

Answer 8

Medir a quantidade de tempo de teste gasto no produto entre "empecilhos" ou grandes bugs de funcionalidade pode permitir que você saiba que está quase lá.Em momentos de rápido fluxo no produto com novas funcionalidades sendo introduzidas, é comum que uma equipe de testes descubra que a maioria dos bugs que estão relatando são bugs graves de funcionalidade.À medida que eles são resolvidos, muitas vezes há uma grande quantidade de problemas menores, de ajuste e de acabamento, destinados a melhorar a suavidade e a clareza da interação;em conjunto, eles fazem uma grande diferença na qualidade do produto, mas cada um deles não é muito importante.À medida que eles são corrigidos e os testes continuam, você provavelmente continuará recebendo relatórios de bugs à medida que os testadores avançam em casos de erros e padrões de uso incomuns.Nesse ponto, depende de quando você vê o valor comercial do lançamento versus o risco de obstáculos não detectados.