Este tutorial apresenta os sete princípios básicos de teste de software que todo testador de software e profissional de QA deve conhecer.
7 princípios de teste de software
- O teste mostra a presença de defeitos
- O teste exaustivo não é possível
- Teste inicial
- Agrupamento de defeitos
- Paradoxo de pesticidas
- O teste depende do contexto
- Ausência de falácias de erros
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
Fundo
É importante que você obtenha os melhores resultados de teste durante a realização de testes de software sem se desviar do objetivo. Mas como você determina que está seguindo a estratégia certa para o teste? 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 usuais, 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ê fosse testar todas as combinações possíveis, o TEMPO E CUSTOS DE EXECUÇÃO aumentaria exponencialmente. Precisamos de certos princípios e estratégias para otimizar o esforço de teste
Aqui estão os 7 princípios:
1) O teste exaustivo não é possível
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 do aplicativo.
E a pergunta de um milhão de dólares é: como você determina esse risco?
Para responder a isso, vamos fazer um exercício
Em sua opinião, qual operação tem maior probabilidade de causar falha no sistema operacional?
Tenho certeza de que a maioria de vocês teria adivinhado, abrindo 10 aplicativos diferentes, todos ao mesmo tempo.
Portanto, se você estivesse testando este sistema operacional, perceberia que é provável que os defeitos sejam encontrados na atividade multitarefa e precisam ser testados exaustivamente, o que nos leva ao nosso próximo princípio Cluster de Defeitos
2) Clustering de defeitos
Clustering de defeitos, que indica que um pequeno número de módulos contém a maioria dos defeitos detectados. Esta é a aplicação do Princípio de Pareto para teste de software: aproximadamente 80% dos problemas são encontrados em 20% dos módulos.
Por experiência, você pode identificar esses módulos arriscados. Mas essa 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 de Pesticidas
O uso repetitivo da mesma mistura de pesticidas para erradicar insetos durante a agricultura irá, com o tempo, fazer com que os insetos desenvolvam resistência ao pesticida. Portanto, os pesticidas são ineficazes para os insetos. O mesmo se aplica ao teste de software. Se o mesmo conjunto de testes repetitivos for realizado, o método será inútil para descobrir novos defeitos.
Para superar isso, os casos de teste precisam ser regularmente revistos e revisados, 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 em testes, você nunca pode afirmar que seu produto está livre de bugs. Para esclarecer este 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 travar durante o lançamento público!
4) O teste mostra a presença de defeitos
Portanto, o princípio de teste afirma que - O teste fala sobre a presença de defeitos e não fala sobre a ausência de defeitos. Por exemplo, o Teste de Software reduz a probabilidade de defeitos não descobertos permanecerem no software, mas mesmo se nenhum defeito for encontrado, não é uma prova de correção.
Mas e se, você trabalhar muito duro, tomando todas as precauções e tornando 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 o software 99% livre de bugs ainda esteja inutilizável. Esse pode ser o caso se o sistema for testado exaustivamente quanto ao requisito errado. O teste de software não é apenas encontrar defeitos, mas também 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 Inicial
6) Teste Inicial
Teste Inicial - O teste deve 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 consertar um Defeito nos estágios iniciais de teste. Mas quão cedo se deve começar o teste? Recomenda-se que você comece a encontrar o bug no momento em que os requisitos forem definidos. Mais sobre este 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 e-commerce será diferente da maneira como você testa um aplicativo comercial disponível no mercado. Todos os softwares desenvolvidos não são idênticos. Você pode usar uma abordagem, metodologias, técnicas e tipos de teste diferentes, dependendo do tipo de aplicativo. Por exemplo, testar, qualquer sistema POS em uma loja de varejo será diferente de testar uma máquina ATM.
Mito: "Os princípios são apenas para referência. Não os usarei na prática."
Isso é muito falso. Os Princípios de Teste o ajudarão a criar uma Estratégia de Teste eficaz e esboçar casos de teste de detecção de erros.
Mas aprender os princípios de teste é como aprender a dirigir pela primeira vez.
Inicialmente, enquanto você aprende a dirigir, você presta atenção a tudo e cada um, como mudanças de marcha, velocidade, manuseio da embreagem, etc. Mas com a experiência, você apenas se concentra em dirigir o resto vem naturalmente. De forma que você até mantém conversas com outros passageiros do carro.
O mesmo é verdade para os 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 usados na prática simplesmente não é verdade.