7 Princípios básicos, Estratégias & Abordagens para os Testes de Software

Várias estratégias e princípios sobre testes de software foram

 sugeridos e de certa forma aplicados nos últimos 40 anos. 

Mas será que eles ainda se aplicam nos dias de hoje,

com softwares cada vez mais complexos e com o caráter

de urgência que os projetos de hoje demandam?

Acredito que todos que lerem esse artigo, pelo menos uma vez na vida já leram ou ouviram falar sobre princípios básicos e Estratégias em testes de software – principalmente aqueles que já estudaram para alguma certificação disponível no mercado.

            Esses princípios norteiam, ou deveriam nortear, toda estratégia e processo de testes de qualquer equipe ou profissional da área. Mas será que realmente isso acontece nos dias atuais?

            Apenas destaco aqui esses princípios, até porque todos eles estão listados em inúmeros sites, blogs, materiais de estudos, etc (caso você nunca os tenha visto, acesse http://tmtestes.com.br/os-mais-importantes-principios-do-teste-de-software/.

• I Testes mostram a presença de erros – Apenas Podemos usar os testes para reduzir o número de defeitos não encontrados.
• II Testes Exaustivos são impossíveis – Não é possível testar todas as combinações de inputs de dados, cenários e pré-condições dentro de uma aplicação. 
• III Teste Cedo/Antes – o custo de um erro cresce exponencialmente ao longo do processo de Desenvolvimento
• IV Aglutinação de Defeitos – 80% dos erros são usualmente encontrados em 20% dos módulos do sistema.
• V Paradoxo Pesticida – Rodar o mesmo conjunto de testes de novo e de novo não te ajudará a encontrar mais falhas.
• VI Teste depende do contexto – Dependendo do proposito ou da indústria, diferentes aplicações devem ser testadas diferentemente. 
• VII Falácia da Ausência de erros –  A completa ausência de defeitos no seu produto não significa necessariamente que ele será um sucesso. 

De todos os princípios, gostaria de detalhar o princípio II, “Testes Exaustivos são Impossíveis”.

            Quando este princípio foi escrito (lembre-se, há mais de 40 anos), testar já era uma atividade complexa, pois os softwares da época já eram grandes e complexos. Aliado a esses fatores, existia também a questão do tempo, prazo e esforço associado aos testes, que na maioria esmagadora dos projetos, eram curtos e escassos. Até aí, alguma novidade com os dias de hoje?

            Acredito que a situação atual complicou ainda mais isso, pois as empresas precisam lançar produtos inovadores cada vez mais rápido, com o advento das metodologias ágeis.

            Mas a pergunta inicial ainda persiste: esse princípio é aplicável nos dias de hoje, mesmo com uma abordagem mais ampla, com testes automatizados e equipes multidisciplinares?

            A resposta é sim! Diria que principalmente nos dias de hoje!

            O princípio II diz que testes exaustivos são impossíveis por não termos tempo suficiente, seja por existir uma grande combinação de entradas, saídas e pré-condições no software a ser testado, ou por conta do paradoxo pesticida (princípio V) e vários outros fatores. E, como toda e qualquer organização necessita de produtos com alto nível de qualidade (o famoso desejo por “zero” defeitos), esse princípio deve ser levado em consideração em qualquer estratégia de testes a ser elaborada.

            Então temos um paradoxo, pois se é impossível testar tudo e nos é exigido qualidade nos testes, como resolver essa equação? Ainda existe uma outra variável: Se não é possível testar tudo, como sabemos o que testamos e o que deixamos de testar. Eis a famosa Cobertura dos Testes.

            É possível minimizar esse problema com algumas estratégias e abordagens que podem ser adotadas durante os testes. Vou destacar algumas que fazem toda a diferença na hora de planejar e preparar os testes:

• Faça uma análise baseada em risco, levando em consideração a probabilidade vs risco;
• Priorize seus testes utilizando alguma técnica de priorização, como por exemplo, a técnica MoSCoW, e sempre comece seus testes pelos mais críticos;
• Automatize pelo menos 90% dos seus testes, isso assegura testes regressivos mais amplos nos próximos ciclos (ou sprints);
• Avalie sempre a cobertura dos testes através de algum indicador, como por exemplo, Cob(Rq) – Cobertura dos Requisitos e/ou Cob(Ca) – Cobertura dos Critérios de Aceite;
• Extraia indicadores de confiabilidade como Densidade de Falha (Df) por Kloc e com isso, será possível fazer estimativas bem realistas;

Essas estratégias e outras que podem ser agregadas dependendo do contexto, vão garantir que seus testes sempre serão eficazes, trazendo confiabilidade ao produto e ao trabalho da equipe de testes.

E para encerrar, você pode estar se perguntando como eu utilizo essa técnica MoSCoW? Como eu extraio esses e outros indicadores?

Todos esses e outros temas de imprescindível importância, são abordados durante os treinamentos para Certificação em Engenharia de Testes de Software fornecidos pela TMI e podem ser conferidos aqui https://tmintelligence.com.br/cptf