7 princípios de teste de software com exemplos

Este tutorial apresenta os sete princípios básicos de teste de software que todo testador de software e profissional de controle de qualidade deve conhecer.

Vamos aprender os princípios de teste com o seguinte exemplo de vídeo-

Clique aqui se o vídeo não estiver acessível

Contexto

É importante que você obtenha resultados de teste ideais ao conduzir testes de software sem se desviar do objetivo. Mas como você determina se está seguindo a estratégia certa para testes? Para isso, você precisa seguir alguns princípios básicos de teste. Aqui estão os sete princípios de teste comuns amplamente praticados na indústria de software.

Para entender isso, considere um cenário em que você está movendo um arquivo da pasta A para a pasta B.

Pense em todas as maneiras possíveis de testar isso.

Além dos cenários habituais, você também pode testar as seguintes condições

• Tentando mover o arquivo quando ele está aberto
• Você não tem direitos de segurança para colar o arquivo na Pasta B
• A pasta B está em uma unidade compartilhada e a capacidade de armazenamento está cheia.
• A pasta B já possui um arquivo com o mesmo nome, aliás a lista é infinita
• Ou suponha que você tenha 15 campos de entrada para testar, cada um com 5 valores possíveis, o número de combinações a serem testadas seria 5^15

Se você testasse todas as combinações possíveis do projeto, o TEMPO DE EXECUÇÃO E OS CUSTOS aumentariam exponencialmente. Precisamos de certos princípios e estratégias para otimizar o esforço de teste

Aqui estão os 7 Princípios:

1) Testes exaustivos não são possíveis

Sim! Testes exaustivos não são possíveis. Em vez disso, precisamos da quantidade ideal de testes com base na avaliação de risco da aplicação.

E a pergunta de um milhão de dólares é: como determinar esse risco?

Para responder isso vamos fazer um exercício

Na sua opinião, qual operação tem maior probabilidade de causar o seu Operasistema falhar?

Tenho certeza de que a maioria de vocês deve ter adivinhado, abrindo 10 aplicativos diferentes ao mesmo tempo.

Então, se você estava testando isso Operasistema de trabalho, você perceberia que é provável que defeitos sejam encontrados em atividades multitarefa e precisam ser testados minuciosamente, o que nos leva ao próximo princípio Defeito Clustering

2) Defeito Clustering

Defeito Clusterque afirma que um pequeno número de módulos contém a maioria dos defeitos detectados. Esta é a aplicação do Princípio de Pareto aos testes de software: aproximadamente 80% dos problemas são encontrados em 20% dos módulos.

Pela experiência, você pode identificar esses módulos arriscados. Mas esta abordagem tem seus próprios problemas

Se os mesmos testes forem repetidos continuamente, eventualmente os mesmos casos de teste não encontrarão mais novos bugs.

3) Paradoxo dos Pesticida

O uso repetitivo da mesma mistura de pesticidas para erradicar insectos durante a agricultura levará, com o tempo, a que os insectos desenvolvam resistência ao pesticida. Deste modo, os pesticidas são ineficazes nos insectos. O mesmo se aplica aos testes de software. Se o mesmo conjunto de testes repetitivos for realizado, o método será inútil para a descoberta de novos defeitos.

Para superar isso, os casos de teste precisam ser revisados ​​e revisados ​​regularmente, adicionando novos e diferentes casos de teste para ajudar a encontrar mais defeitos.

Os testadores não podem simplesmente depender das técnicas de teste existentes. Ele deve procurar continuamente melhorar os métodos existentes para tornar os testes mais eficazes. Mas mesmo depois de todo esse suor e trabalho duro nos testes, você nunca poderá afirmar que seu produto está livre de bugs. Para esclarecer esse ponto, vamos ver este vídeo do lançamento público do Windows 98

Você acha que uma empresa como a MICROSOFT não teria testado seu sistema operacional completamente e arriscaria sua reputação apenas para ver seu sistema operacional travando durante seu lançamento público!

4) O teste mostra a presença de defeitos

Portanto, o princípio do teste afirma que – O teste fala sobre a presença de defeitos e não fala sobre a ausência de defeitos. ou seja Teste de software reduz a probabilidade de defeitos não descobertos permanecerem no software, mas mesmo que nenhum defeito seja encontrado, não é uma prova de correção.

Mas e se você trabalhar duro, tomando todas as precauções e tornar seu produto de software 99% livre de bugs. E o software não atende às necessidades e requisitos dos clientes.

Isso nos leva ao nosso próximo princípio, que afirma que- Ausência de Erro

5) Ausência de Erro – falácia

É possível que um software 99% livre de bugs ainda esteja inutilizável. Este pode ser o caso se o sistema for testado exaustivamente para o requisito errado. O teste de software não consiste apenas em encontrar defeitos, mas também em verificar se o software atende às necessidades do negócio. A ausência de erro é uma falácia, ou seja, encontrar e corrigir defeitos não ajuda se a construção do sistema estiver inutilizável e não atender às necessidades e requisitos do usuário.

Para resolver este problema, o próximo princípio de teste afirma que o Teste Antecipado

6) Testes iniciais

Testes iniciais – Os testes devem começar o mais cedo possível no ciclo de vida de desenvolvimento de software. Para que quaisquer defeitos nos requisitos ou na fase de design sejam capturados nos estágios iniciais. É muito mais barato corrigir um defeito nos estágios iniciais do teste. Mas com que antecedência se deve começar os testes? É recomendado que você comece a encontrar o bug no momento em que os requisitos forem definidos. Mais sobre esse princípio em um tutorial de treinamento posterior.

7) O teste depende do contexto

O teste depende do contexto, o que basicamente significa que a maneira como você testa um site de comércio eletrônico será diferente da maneira como você testa um aplicativo comercial pronto para uso. Todos os softwares desenvolvidos não são idênticos. Você pode usar abordagens, metodologias, técnicas e tipos de testes diferentes, dependendo do tipo de aplicativo. Por exemplo, o teste de qualquer sistema POS em uma loja de varejo será diferente do teste de um caixa eletrônico.

Mito: “Os princípios são apenas para referência. Não vou usá-los na prática.”

Isso é muito falso. Os Princípios de Teste ajudarão você a criar um Estratégia de Teste e rascunhar casos de teste de captura de erros.

Mas aprender os princípios dos testes é como aprender a dirigir pela primeira vez.

Inicialmente, enquanto você aprende a dirigir, você presta atenção a tudo e a cada um, como mudanças de marcha, velocidade, manuseio da embreagem, etc. Mas com a experiência, você se concentra apenas em dirigir, o resto vem naturalmente. De tal forma que você até conversa com outros passageiros do carro.

O mesmo se aplica aos princípios de teste. Testadores experientes internalizaram esses princípios a um nível que os aplicam mesmo sem pensar. Daí o mito de que os princípios não são utilizados na prática simplesmente não é verdade.