Como saber quando parar de testar?

Eu sei que esta é uma pergunta muito, muito básica. Para alguns aplicativos de software, há um grande número quase infinitamente alto de casos de teste para um aplicativo. Não é prático testar todos esses casos de teste. Como decidimos quando parar o teste? (exceto "quando o dinheiro acabar").

O livro de Glenford Myers, The Art of Software Testing, tem uma regra simples, mas bem baseada em princípios, para isso: O teste é concluído quando você para de encontrar bugs. Ou, mais praticamente, quando a taxa na qual você encontra novos bugs diminui bastante.

Os bugs tendem a "agrupar" em certos módulos e certas funções: no momento em que você encontra um bug em um, você sabe que deve procurar mais por ele. Para encontrar erros, você pode usar as técnicas de teste de caixa preta, teste de caixa branca e teste de mutação. Enquanto você encontrar bugs, você sabe que seu processo de teste está funcionando!

Para visualizar seu progresso, faça um gráfico do número de bugs que sua equipe encontrou por dia. Se o gráfico estiver inclinado para baixo, você saberá que as técnicas que sua equipe está usando não as encontrarão de qualquer maneira. Obviamente, se você acredita que suas técnicas não estão à altura, leia o livro de Myers e aplique os princípios.

Agora, há uma chance de você perder um novo patch de bugs, e a taxa de localização de bugs teria aumentado muito se você continuasse testando um pouco mais. No entanto, se você acredita que suas técnicas são sólidas, isso é improvável.

A resposta simples é que depende do sistema. Se você está escrevendo software incorporado para um monitor cardíaco ou ferramentas de monitoramento de segurança para um reator nuclear, o padrão é muito mais alto do que se você estiver escrevendo uma plataforma de blog.

Esta é realmente uma pergunta para um bom testador de sistema (e eu não sou um), mas vou tentar.

Sua medida básica será a cobertura do teste: quanto do aplicativo foi realmente testado (por teste de unidade e funcionalmente).

Você precisa avaliar cada caso de uso em potencial (e parâmetros para esse caso de uso) quanto à probabilidade de ele realmente ser usado (para que você possa descartar casos extremos), complexidade (coisas mais simples são menos propensas a conter bugs ou menos propensas a conter problemas físicos) para encontrar bugs), custo para testar (em termos de tempo) e impacto potencial de um defeito se descoberto nessa área (é aqui que entra a plataforma de reator nuclear vs. blogging).

Com base nessa avaliação, você precisa descobrir quais deles serão testados e em quantos detalhes. Depois de ter uma lista como essa, a equipe (incluindo um gerente de produto / gerente de projeto / representante do usuário) pode passar por essa lista e priorizar com base nas restrições existentes.

Uma técnica útil para se pensar é que você também pode variar os casos de uso que são testados a cada release. Por exemplo, você pode ter uma lista de casos de teste não críticos e testar metade deles com um release e metade com o próximo (depois alternar). Dessa forma, você está aumentando a cobertura total de teste obtida pelo esforço (embora com o risco de erros de regressão sendo introduzidos).

Isso também pode se estender ao teste da plataforma - se você oferecer suporte a dois back-ends do banco de dados (ou vários navegadores), teste metade do aplicativo em um, a outra metade no outro e depois troque a próxima versão.

(Acho que isso é chamado de striping, mas não me cite nisso.)

E a última coisa a se pensar não é o que você testa, mas o que você corrige quando os problemas são descobertos. É comum dizer "corrigir todos os bugs", mas a realidade é que existem pressões no tempo e nem todos os bugs são iguais. Novamente, a limpeza regular de bugs com todas as partes relevantes é o melhor caminho a seguir. Isso é particularmente relevante quando uma correção de bug pode ser particularmente intrusiva, pois o trabalho adicional nos testes de teste e regressão que gera pode compensar os benefícios da correção.

Quando o risco associado ao uso do software foi reduzido para um nível aceitável.

"O teste do programa pode ser usado para mostrar a presença de bugs, mas nunca para mostrar sua ausência!" --Edsger Dijkstra

Algo bom para se ter em mente ao fazer qualquer teste, automatizado ou não. Você só pode provar que não encontrou mais erros, não que não haja mais.

Porém, quanto mais olhos você coloca em uma seção de código, mais confiante pode estar em seu funcionamento adequado. É muito parecido com a citação de Knuth sobre otimização nesse sentido: você pode testar as coisas erradas com muita facilidade e nos momentos errados do seu desenvolvimento.

Essencialmente, você quer ser coberto em dois grandes lugares:

1. O software passa nos testes BDD que demonstram que atende aos requisitos especificados. O software nem pode ser chamado de concluído, se isso não for verdade.

2. Os segmentos mais críticos, complexos e inseguros têm testes adequados para fornecer confiança? Se for um loop principal, ou algo que você precise otimizar ou invadir: faça um teste. Se for complicado e tiver muitas divisões lógicas: faça muitos testes. Se você não puder testá-lo em unidade, ou ele estiver incorporado muito fundo para praticamente testar diretamente: verifique se o código foi revisado e o código indiretamente testado manualmente.

Se você esperar até que o projeto termine, você realmente terá um número muito grande de casos de teste. Se você entregar continuamente, concentrando-se em pequenas entregas, terá menos casos de teste a cada iteração e poderá testar tudo. Se você não pode fazer pequenas entregas, priorize e comece os testes com a maior prioridade e faça os testes até ter que parar.

Se você está falando sobre testes de unidade e está fazendo TDD (escrevendo os testes primeiro), isso não é um problema: você apenas para de testar quando os recursos são concluídos.

No TDD incremental, você escreve um teste que falha, implementa a menor quantidade de código que pode fazê-lo passar e depois refatora. Continue adicionando testes dessa maneira até que o método esteja completo.

Aqui está um ótimo exemplo.

Os estatísticos também analisaram essa questão - na verdade, já nos anos 1970-80. Dadas as suposições apropriadas sobre como os bugs são descobertos, eles tentam estimar o número de bugs a partir dos dados do teste. Isso é usado para determinar quando parar com base na otimização de uma função de perda. Veja, por exemplo, https://rpubs.com/hoehle/17920 ... para um breve tratamento de um dos artigos sobre esse assunto, incluindo o código R sobre como fazer isso na prática.

Obviamente, uma questão sempre será as suposições sobre o processo de descoberta de erros. Por exemplo, no tratamento acima, supõe-se que os erros sejam descobertos independentemente um do outro. Na prática, consertar um grande erro pode, por exemplo, causar novos erros, etc.

Quando a data do envio chegar. Não há fim para o teste de um software. Mas, novamente, há algo conhecido como cronograma. Você terá que testar a maior parte de sua funcionalidade no horário agendado e corrigir os erros que encontrar. Não há como garantir que o software seja perfeito.

As primeiras coisas a serem testadas seriam o "caminho feliz", casos extremos e entradas inválidas. Se houver mais de um usuário simultâneo, você precisará testar problemas de simultaneidade, como bloqueio e condições de corrida. Se o aplicativo usar recursos externos, você precisará testar como o aplicativo se comporta quando esses recursos não estão disponíveis. Depois disso, você pode usar o código para procurar por coisas que possam causar sua quebra e testá-las. Quando todos esses testes passam, a relação custo / benefício de mais testes começa a subir, por isso é razoável parar nesse ponto.

Tudo se resume a uma questão de confiança. Você se sente confiante de que o sistema foi testado o suficiente?

Obviamente, o "nível de confiança" é altamente subjetivo, pois você nunca pode se sentir completamente certo, mas com certeza - e é isso que estamos procurando. Para isso, é necessário criar uma lista de indicadores, comumente conhecida como definição de done e deve ser algo com o qual toda a sua equipe concorda.

Aqui estão alguns "indicadores concluídos" relacionados ao teste:

• Sua construção e instalação são totalmente automatizadas e todos os testes (unidade, GUI, integração) são executados automaticamente?
• Você escreve seus testes enquanto (ou de preferência antes) escreve o código, e não depois?
• Você se sente seguro o suficiente para fazer refatoração de código grande sem introduzir bugs?
• O seu nível de cobertura de código é alto o suficiente?
• Você tem um testador dedicado em sua equipe? Ele / ela está envolvido diariamente durante todo o desenvolvimento e não apenas no final?
• Seu testador manualmente (exploratório) tentou quebrá-lo sem sucesso?

Se você pode verificar esses pontos, provavelmente pode dizer que testou o suficiente.

Nunca, acho que você nunca terminará os testes em um sistema .. existem tantas variáveis ​​que você não pode gerenciar.

Mas, como sabemos, você não pode testar "para sempre", então acho que o limite depende basicamente de:

• Quando o risco associado ao uso do software foi reduzido para um nível aceitável. (como @Graham Lee diz)
• Quem é o usuário do sistema? pode ser você ou o presidente dos estados unidos. No primeiro caso, você não se importa muito se um bug aparecer porque você o resolve e pronto. No segundo caso, você não deseja que QUALQUER bug apareça.
• Qual é o seu relacionamento com seu cliente? Talvez o cliente seja seu pai, então não é tão terrível, ou talvez seja uma grande empresa.
• Quão sério é para os usuários do sistema um bug? Causará a terceira guerra mundial ou apenas uma mensagem feia?

Quando as pessoas que precisam assinar a implantação estão satisfeitas.

ou, em alguns casos, a maioria das partes responsáveis ​​está satisfeita.