Os 7 Princípios de Testes em Software

[Kevin Silva]

Nos últimos 50 anos , foram sugeridas diversas boas práticas de testes em software que ofereceram diretrizes gerais comuns que podem ser aplicadas para todos os tipos de testes existentes. Essas boas práticas foram reunidas em 7 princípios que serão abordados logo abaixo.

 

1. O teste mostra a presença de defeitos e não a sua ausência

Um teste reduz a probabilidade de defeitos não descobertos permanecerem no software. Entretanto, mesmo que nenhum defeito seja encontrado durante a execução do teste, isso não significa que o teste é uma prova de correção. Imagine por exemplo, um software que possua uma suíte de testes automatizados que é executada em um determinado momento e, todos os testes dessa suíte não encontraram nenhum defeito durante a execução.

O fato de todos os testes terem passado sem falhar não é uma certeza de que o software esteja livre de outros defeitos, especialmente em partes em que a suíte de testes possa não estar com a cobertura adequada.

 

2. Testes exaustivos são impossíveis

Testar tudo (ou seja, todas as combinações de entradas e pré-condições) não é viável, exceto em casos triviais. Ao invés de tentar testar um software exaustivamente, é mais adequado focar o tempo e o esforço na análise de risco, para decidir onde e quando começar a testar e identificar áreas do software que precisam de mais atenção.

Em adição, usar as técnicas de teste e alinhar as prioridades considerando prazos de entrega e o esforço necessário para a criação e execução dos testes também são importantes e ajudam na obtenção de um custo-benefício adequado.

 

3. O teste inicial economiza tempo e dinheiro

Para encontrar antecipadamente os defeitos, as atividades de teste estático e dinâmico devem iniciar o mais cedo possível no ciclo de vida de desenvolvimento de software. O teste inicial é por vezes referido como shift left. O teste no início do ciclo de vida de desenvolvimento de software ajuda a reduzir ou eliminar alterações dispendiosas. 

A análise estática do código-fonte é um exemplo de teste estático, e ela pode ocorrer durante code reviews manuais ou por meio de ferramentas (Como o SonarQube, por exemplo) sem a necessidade de execução do software. Já exemplos de testes dinâmicos comumente aplicados em shift left podem envolver testes de unidade e integração.

 

4. Defeitos se agrupam

Após a análise dos relatórios de defeitos de um sistema, é possível que a maioria dos problemas esteja relacionada a um ou mais módulos/funcionalidades de um software. Isso seria indício de que os defeitos tendem a se agrupar nessa área específica, sugerindo a necessidade de um foco adicional de teste nessa funcionalidade.

 

5. Cuidado com o paradoxo do pesticida

Se os mesmos testes forem repetidos várias vezes, esses testes não encontrarão novos defeitos. Para detectar novos defeitos, os testes existentes e os dados de teste podem precisar ser atualizados e/ou novos testes precisam ser implementados. Da mesma forma que os pesticidas não são mais eficazes em matar insetos depois de um tempo, os testes não são mais eficazes em encontrar novos defeitos.

Em certos casos, como o teste de regressão automatizado, o paradoxo do pesticida tem um resultado benéfico, que é o número relativamente baixo de defeitos de regressão, impedindo que esses defeitos voltem a acontecer em produção.

 

6. O teste depende do contexto

Um teste pode ser feito de forma diferente em diferentes contextos. Por exemplo, um software de controle industrial de segurança crítica é testado de forma diferente de um aplicativo móvel de comércio eletrônico.

Da mesma maneira, um teste em um projeto ágil (como Scrum ou Kanban) é implementado de forma diferente de um teste em um projeto de ciclo de vida sequencial, como o Waterfall (Cascata).

 

7. Ausência de erros é uma ilusão

Algumas organizações esperam que os testadores possam executar todos os testes possíveis e encontrar todos os defeitos possíveis, mas os princípios 2 e 1, respectivamente, nos dizem que isso é impossível. Além disso, é uma ilusão achar que apenas encontrar e corrigir muitos defeitos assegure o sucesso de um sistema.

Encontrar e corrigir muitos defeitos não é garantia de que  , Como exemplo, testar exaustivamente todos os requisitos especificados e corrigir todos os defeitos encontrados não impede a produção de um software difícil de usar e/ou que não atenda às necessidades e expectativas dos stakeholders e/ou que seja inferior em comparação com outros sistemas concorrentes.

 

A aplicação de todos os princípios citados acima pode garantir maior eficácia e eficiência dos esforços de testes. Eles fornecem uma estrutura robusta para a implementação e execução de testes, auxiliam na identificação de defeitos precocemente, melhoram a cobertura de teste e possibilitam a adaptação ao contexto de qualquer projeto. Quando os desenvolvedores e testadores seguem tais princípios, as empresas tendem a aprimorar a qualidade dos seus produtos, reduzir os custos e riscos e também aumentar a satisfação dos clientes.

 

Fonte: https://bcr.bstqb.org.br/docs/syllabus_ctfl_3.1.1br.pdf