7 principles software testing
Sete princípios de teste de software: incluindo mais detalhes sobre agrupamento de defeitos, princípio de Pareto e paradoxo de pesticidas.
Tenho certeza de que todos estão cientes da “ Sete Princípios de Teste de Software ”.
Esses princípios de teste fundamentais ajudam as equipes de teste a utilizar seu tempo e esforço para tornar o processo de teste eficaz. Neste artigo, aprenderemos em detalhes sobre dois princípios, ou seja, Agrupamento de Defeitos, Princípio de Pareto e Paradoxo de Pesticidas .
O que você aprenderá:
- Sete Princípios de Teste de Software
Sete Princípios de Teste de Software
Antes de examinar em profundidade esses dois princípios, vamos compreender brevemente os sete princípios de teste de software.
Vamos explorar!!
# 1) O teste mostra a presença de defeitos
Cada aplicativo ou produto é lançado em produção após uma quantidade suficiente de testes por diferentes equipes ou passa por diferentes fases, como Teste de Integração do Sistema, Teste de Aceitação do Usuário e Teste Beta, etc.
Então você já viu ou ouviu de alguma equipe de teste que eles testaram o software totalmente e não há defeito no software ? Em vez disso, cada equipe de teste confirma que o software atende a todos os requisitos de negócios e está funcionando de acordo com as necessidades do usuário final.
Na indústria de teste de software, ninguém dirá que existe sem defeito no software, o que é verdade, pois os testes não podem provar que o software está livre de erros ou defeitos.
No entanto, o objetivo do teste é encontrar mais e mais defeitos ocultos usando diferentes técnicas e métodos. O teste pode revelar defeitos não descobertos e, se nenhum defeito for encontrado, isso não significa que o software está livre de defeitos.
Exemplo 1 :
Considere um aplicativo de banco, este aplicativo é totalmente testado e passa por diferentes fases de teste como SIT, UAT etc. e atualmente nenhum defeito é identificado no sistema.
No entanto, pode haver a possibilidade de que no ambiente de produção, o cliente real tente uma funcionalidade que raramente é usada no sistema bancário e os testadores ignoraram essa funcionalidade, portanto, nenhum defeito foi encontrado até a data ou o código nunca foi tocado pelos desenvolvedores .
Exemplo 2:
Vimos vários anúncios de sabonetes, pasta de dentes, produtos para lavar as mãos ou sprays desinfetantes, etc. na televisão.
Considere um anúncio de lavagem das mãos que diz na televisão que 99% dos germes podem ser removidos se aquela lavagem específica for usada. Isso prova claramente que o produto não é 100% livre de germes. Portanto, em nosso conceito de teste, podemos dizer que nenhum software está livre de defeitos.
# 2) Teste inicial
Os testadores precisam se envolver em um estágio inicial do Ciclo de Vida de Desenvolvimento de Software (SDLC). Assim, os defeitos durante a fase de análise de requisitos ou quaisquer defeitos de documentação podem ser identificados. O custo envolvido na correção de tais defeitos é muito menor quando comparado aos que são encontrados durante os estágios posteriores de teste.
Considere a imagem abaixo, que mostra como o custo de correção de defeitos aumenta à medida que os testes avançam para a produção ao vivo.
(imagem fonte )
A imagem acima mostra que o custo necessário para consertar um defeito encontrado durante a Análise de Requisitos é menor e continua aumentando à medida que avançamos para a fase de Teste ou Manutenção.
Agora a questão é quão cedo o teste deve começar ?
Depois que os requisitos são finalizados, os testadores precisam se envolver para o teste. O teste deve ser executado em documentos de requisitos, especificações ou qualquer outro tipo de documento para que, se os requisitos forem definidos incorretamente, eles possam ser corrigidos imediatamente, em vez de corrigi-los na fase de desenvolvimento.
# 3) O teste exaustivo não é possível
Não é possível testar todas as funcionalidades com todas as combinações válidas e inválidas de dados de entrada durante o teste real. Em vez dessa abordagem, o teste de algumas combinações é considerado com base na prioridade usando técnicas diferentes.
Testes exaustivos exigirão esforços ilimitados e a maioria desses esforços são ineficazes. Além disso, os cronogramas do projeto não permitirão o teste de tantos números de combinações. Portanto, é recomendável testar os dados de entrada usando métodos diferentes, como particionamento de equivalência e análise de valor de limite.
Por exemplo ,Suponha que temos um campo de entrada que aceita alfabetos, caracteres especiais e números de 0 a 1000 apenas. Imagine quantas combinações apareceriam para teste, não é possível testar todas as combinações para cada tipo de entrada.
Os esforços de teste necessários para testar serão enormes e também impactarão o cronograma e o custo do projeto. Por isso, sempre se diz que testes exaustivos praticamente não são possíveis.
# 4) O teste é dependente do contexto
Existem vários domínios disponíveis no mercado como Banca, Seguros, Médico, Viagens, Publicidade, etc. e cada domínio tem uma série de aplicações. Além disso, para cada domínio, seus aplicativos têm diferentes requisitos, funções, diferentes objetivos de teste, risco, técnicas, etc.
Domínios diferentes são testados de forma diferente, portanto, o teste é puramente baseado no contexto do domínio ou aplicativo.
Por exemplo ,testar um aplicativo bancário é diferente de testar qualquer aplicativo de comércio eletrônico ou de publicidade. O risco associado a cada tipo de aplicativo é diferente, portanto, não é eficaz usar o mesmo método, técnica e tipo de teste para testar todos os tipos de aplicativo.
# 5) Clustering de defeitos
Durante o teste, pode acontecer que a maioria dos defeitos encontrados esteja relacionada a um pequeno número de módulos. Pode haver várias razões para isso, como os módulos podem ser complexos, a codificação relacionada a esses módulos pode ser complicada, etc.
Este é o Princípio de Pareto de teste de software, onde 80% dos problemas são encontrados em 20% dos módulos. Aprenderemos mais sobre o agrupamento de defeitos e o Princípio de Pareto posteriormente neste artigo.
# 6) Paradoxo de Pesticidas
O princípio do Paradoxo dos Pesticidas diz que se o mesmo conjunto de casos de teste for executado repetidamente ao longo do período, então esse conjunto de testes não será capaz o suficiente para identificar novos defeitos no sistema.
Para superar esse “Paradoxo dos Pesticidas”, o conjunto de casos de teste precisa ser regularmente revisado e revisado. Se necessário, um novo conjunto de casos de teste pode ser adicionado e os casos de teste existentes podem ser excluídos se eles não forem capazes de encontrar mais defeitos no sistema.
# 7) Ausência de erro
Se o software for totalmente testado e nenhum defeito for encontrado antes do lançamento, podemos dizer que o software está 99% livre de defeitos. Mas e se esse software for testado em relação a requisitos incorretos? Nesses casos, mesmo encontrar defeitos e corrigi-los a tempo não ajudaria, pois os testes são realizados em requisitos incorretos que não atendem às necessidades do usuário final.
Por exemplo, suponha que o aplicativo esteja relacionado a um site de comércio eletrônico e aos requisitos da funcionalidade “Carrinho de compras ou cesta de compras” que foi interpretada e testada incorretamente. Aqui, mesmo encontrar mais defeitos não ajuda a mover o aplicativo para a próxima fase ou no ambiente de produção.
Estes são os sete princípios do Teste de Software.
Agora vamos explorar Agrupamento de defeitos, princípio de Pareto e paradoxo de pesticidas em detalhe .
Clustering de defeitos
Ao testar qualquer software, os testadores geralmente se deparam com uma situação em que a maioria dos defeitos encontrados está relacionada a alguma funcionalidade específica e o restante das funcionalidades terá um número menor de defeitos.
O agrupamento de defeitos significa um pequeno número de módulos contendo a maioria dos defeitos. Basicamente, os defeitos não são distribuídos uniformemente por todo o aplicativo, em vez disso, os defeitos são concentrados ou centralizados em duas ou três funcionalidades.
Às vezes, isso é possível devido à complexidade do aplicativo, a codificação pode ser complexa ou complicada, um desenvolvedor pode cometer um erro que pode afetar uma funcionalidade ou módulo específico apenas.
O clustering de defeitos é baseado em “ Princípio de Pareto ”Que também é conhecido como Regra 80-20 . Isso significa que 80% dos defeitos encontrados são devido a 20% dos módulos da aplicação. O conceito do Princípio de Pareto foi inicialmente definido por um economista italiano - Vilfrodo Pareto .
Se os testadores observarem 100 defeitos, não ficará claro se há algum significado subjacente a esses 100 defeitos. Mas se esses 100 defeitos forem categorizados em alguns critérios específicos, então pode ser possível para os testadores entender que um grande número de defeitos pertencem a poucos módulos específicos apenas.
Por exemplo ,vamos considerar a imagem abaixo que é testada para um dos aplicativos bancários e mostra que a maioria dos defeitos está relacionada à funcionalidade “Cheque especial”. O restante das funcionalidades, como Resumo da conta, Transferência de fundos, Instrução permanente, etc., têm um número limitado de defeitos.
(imagem fonte )
A figura acima indica que existem 18 defeitos em torno da funcionalidade Cheque especial, de um total de 32 defeitos, o que significa que 60% dos defeitos são encontrados no módulo “Cheque especial”.
Conseqüentemente, os testadores se concentram principalmente nesta área durante a execução para encontrar mais e mais defeitos. Recomenda-se que os testadores tenham um foco semelhante nos outros módulos também durante o teste.
Quando um mesmo código ou módulo é testado, repetidamente, usando um conjunto de casos de teste do que durante as iterações iniciais, então o número de defeitos é alto, no entanto, após alguma iteração, a contagem de defeitos será reduzida significativamente. O agrupamento de defeitos indica que a área propensa a defeitos deve ser testada exaustivamente durante o teste de regressão.
Paradoxo de Pesticidas
Quando um dos módulos apresenta mais defeitos, os testadores fazem alguns esforços adicionais para testar esse módulo.
Depois de algumas iterações de teste, a qualidade do código melhora e a contagem de defeitos começa a cair, já que a maioria dos defeitos é corrigida pela equipe de desenvolvimento, pois os desenvolvedores também são cautelosos ao codificar um módulo específico onde os testadores encontraram mais defeitos.
Portanto, em um ponto, a maioria dos defeitos são descobertos e corrigidos de forma que nenhum novo defeito seja encontrado naquele módulo.
No entanto, às vezes pode acontecer que, embora seja extremamente cauteloso durante a codificação em um módulo específico (aqui, em nosso caso, o “ Cheque especial ”), O desenvolvedor pode negligenciar os outros módulos para codificá-lo corretamente ou as alterações feitas naquele módulo em particular podem ter um impacto negativo em outras funcionalidades como Resumo da Conta, Transferência de Fundos e Instruções Permanentes.
Quando os testadores usam o mesmo conjunto de casos de teste para executar o módulo onde a maioria dos defeitos são encontrados (módulo Descoberto), depois de consertar esses defeitos pelos desenvolvedores, esses casos de teste não são muito eficazes para encontrar novos defeitos. Como o fluxo de ponta a ponta do Descoberto, o módulo é testado exaustivamente e os desenvolvedores também escreveram o código para esse módulo com cautela.
É necessário revisar e atualizar esses casos de teste. Também é uma boa ideia adicionar novos casos de teste para que novos e mais defeitos possam ser encontrados em diferentes áreas do software ou aplicativo.
Métodos preventivos de paradoxo de pesticidas
Existem duas opções através das quais podemos prevenir o Paradoxo dos Pesticidas, conforme mostrado abaixo:
para) Escreva um novo conjunto de casos de teste que se concentrará em diferentes áreas ou módulos (diferente do módulo anterior sujeito a defeitos - Exemplo: “Descoberto”) do software.
b) Prepare novos casos de teste e adicione aos casos de teste existentes.
No ' método A ”, Os testadores podem encontrar mais defeitos nos outros módulos nos quais eles não estavam focados durante o teste anterior ou os desenvolvedores não foram extremamente cautelosos durante a codificação.
Em nosso exemplo acima, os testadores podem encontrar mais defeitos nos módulos Resumo da conta, Transferência de fundos ou Instruções permanentes usando o novo conjunto de casos de teste.
Mas pode acontecer que os testadores negligenciem o módulo anterior ( Exemplo: “Descoberto”), onde a maioria dos defeitos foram encontrados na iteração anterior e isso pode ser um risco, pois este módulo (Descoberto) pode ter sido injetado com os novos defeitos após a codificação dos outros módulos.
No ' método B ”, Novos casos de teste são preparados para que novos defeitos potenciais possam ser encontrados nos demais módulos.
Aqui em nosso exemplo, casos de teste recém-criados serão capazes de ajudar na identificação de defeitos nos módulos como Resumo da conta, Transferência de fundos e Instrução permanente. No entanto, os testadores não podem ignorar os módulos propensos a defeitos anteriores ( Exemplo: “Descoberto”) à medida que esses novos casos de teste são mesclados com os casos de teste existentes.
Os casos de teste existentes foram mais focados no módulo “Descoberto” e os novos casos de teste foram focados nos outros módulos. Portanto, todos os conjuntos de casos de teste são executados pelo menos uma vez, até mesmo uma alteração de código ocorre em qualquer módulo. Isso garantirá que a regressão adequada seja executada e o defeito possa ser identificado devido a essa mudança de código.
Usando a segunda abordagem, a contagem total de casos de teste aumenta significativamente e resulta em mais esforços e tempo necessário para a execução. Obviamente, isso terá um impacto nos cronogramas do projeto e, mais importante, no orçamento do projeto.
Portanto, para superar esse problema, os casos de teste redundantes podem ser revisados e removidos. Existem muitos casos de teste que se tornam inúteis após adicionar novos casos de teste e modificar os casos de teste existentes.
É necessário verificar quais casos de teste falharam a fim de identificar os defeitos nas últimas 5 iterações (vamos supor 5 iterações) e quais casos de teste não são muito importantes. Também pode ser o caso de que o fluxo único coberto em alguns casos de teste possa ser coberto em outros casos de teste de ponta a ponta e aqueles casos de teste com fluxo único possam ser removidos.
Isso, por sua vez, reduzirá a contagem total de casos de teste.
Por exemplo ,temos 50 casos de teste para cobrir um módulo específico e vimos que desses 50 casos de teste, 20 casos de teste não conseguiram detectar um novo defeito nas últimas iterações de teste (vamos supor 5 iterações). Portanto, esses 20 casos de teste precisam ser revisados completamente e precisamos verificar o quão importantes são esses casos de teste e uma decisão pode ser tomada de acordo como manter os 20 casos de teste ou removê-los.
Antes de remover qualquer caso de teste, verifique se o fluxo de funcionalidade coberto nesses casos de teste é coberto em outro caso de teste. Esse processo precisa ser seguido em todos os módulos para que a contagem total de casos de teste seja reduzida significativamente. Isso garantirá que a contagem total de casos de teste seja reduzida, mas ainda haverá 100% de cobertura dos requisitos.
Isso significa que todos os casos de teste restantes cobrem todos os requisitos de negócios, portanto, não há comprometimento da qualidade.
Conclusão
O teste de software é uma etapa essencial no SDLC, pois verifica se o software está funcionando de acordo com as necessidades do usuário final ou não.
O teste identifica o máximo de defeitos possível. Portanto, para realizar o teste de maneira eficaz e eficiente, todos devem estar cientes e, de fato, compreender os sete princípios do teste de software claramente e são conhecidos como os pilares do teste.
A maioria dos testadores implementou e experimentou esses princípios durante os testes reais.
garantia de qualidade e diferença de controle de qualidade
Geralmente, o termo princípio significa as regras ou leis que precisam ser seguidas. Portanto, todos na indústria de teste de software devem seguir esses sete princípios e, se alguém ignorar qualquer um desses princípios, o projeto pode custar muito caro.
Leitura feliz!!
Leitura recomendada
- Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
- Trabalho de assistente de controle de qualidade de teste de software
- Curso de Teste de Software: Qual Instituto de Teste de Software devo ingressar?
- Escolhendo o teste de software como sua carreira
- Trabalho de freelancer de redator de conteúdo técnico de teste de software
- O que é técnica de teste baseada em defeitos?
- Algumas perguntas interessantes da entrevista de teste de software
- Comentários e análises do curso de teste de software