Todos os dias, a aplicação de teste em software ganha maior importância dentro das empresas que buscam entregar um produto de forma ágil e sem possíveis defeitos. Essa tarefa pode se tornar cara conforme a complexidade do código. Portanto, empresas de software tem investido mais dinheiro e tempo em testes, contudo o foco não está no número de execuções da mesma funcionalidade, mas sim na qualidade e garantia de funcionamento.

A prática de aplicação de testes em software possui alguns termos usuais e muitas vezes fundidos, como por exemplo: validação, verificação, erro, falha, entre outros. Essa mistura de conceitos não é um problema grave dentro das empresas, mas difundir a cultura e diferenciar essas pequenas atribuições pode agregar muito ao sistema de trabalho.

Verificação e validação

A verificação e validação, utilizadas no exemplo acima, são palavras que causam certa confusão por serem tão semelhantes na rotina diária, mas que possuem uma diferença significativa de uso.

• Verificação: Tem por objetivo definir se o software atende a sua especificação. Faz parte desta etapa também verificar se o produto está sendo produzido dentro dos padrões;
• Validação: Definir se o software atende a necessidade do cliente.

A aplicação dos conceitos é a mesma tanto para linguagens orientadas a objetos quanto imperativas. O que difere são os artefatos utilizados, podendo ser drivers e adaptações ao código respectivamente.

Agora, conhecendo um pouco mais sobre essas denominações. É possível entender a verificação e validação sendo um processo e não necessariamente apenas etapas. Afinal, esse processo é utilizado durante todo ciclo de vida do software. Adentrando um pouco mais nos conceitos usuais, é bom deixar claro quais serão os objetivos de um teste eficaz e como é possível definir um limite de execuções a serem feitas.

Objetivos e Limites

Entre os objetivos, a segurança e confiabilidade do sistema sem dúvida são prioridades, entretanto é possível classificar estes como objetivos “macro” ou de maior escala. Em “micro” ou de menor escala o objetivo envolve executar uma implementação do software, informando dados de teste e examinando suas saídas e seu comportamento operacional.

Mesmo com essas informações a dúvida se mantém, qual o número de testes que irá comprovar a inexistência de defeito no software? Infelizmente a resposta disso pode ser: Quanto tempo você ou sua empresa pretende dedicar nisso?

Sim, isso mesmo! Tempo é a resposta para tudo que se relaciona a testes. Quando questionado sobre quantas vezes uma rotina precisa ser executada para provar que esta não possui defeitos, a resposta na grande maioria das vezes será: INFINITAS. No entanto, essa quantidades de execuções nunca será possível, uma rotina que tenha por objetivo testar todas as possibilidades é denominada teste massivo. Para exemplificar, podemos supor que uma função recebe dois inteiros como no trecho abaixo.

Visto que o domínio de entrada é formado por todos os pares de inteiros, o cálculo de variações é equivalente a:

Onde n é utilizado para o número de bits utilizados para representar um inteiro. Em uma arquitetura de 32 bits o número de execuções da mesma função seria de 18446744073709551616 vezes. Supondo que cada teste demore 1 milissegundo, o mesmo demoraria 5.849.424 séculos. Portanto, é necessário buscar alternativas como testes de robustez ou de pior caso (possivelmente irei escrever sobre estas alternativas em outro momento). Mas sempre tendo em mente que cada nível de proteção ou segurança, exigirá um maior tempo.

Mais conceitos

Caso não tenha notado, em nenhum momento foi descrita a busca de erros no sistema. Afinal, o que descreve as saídas que divergem do correto são denominadas defeitos. Isso porque, assim como destacado anteriormente, estas palavras são conceitos fundidos. Para a distinção desses termos, pode-se seguir a regra:

• Defeito: Saída do programa que difere da correta. Exemplo disso são relatórios com dados incorretos, ou mesmo outras informações que o sistema possa lidar de forma incorreta e apresentar ao usuário;
• Erro: Manifesto interno do defeito, não necessariamente ocorre devido ao código. Pode ocorrer de entradas no sistema não estarem corretas, então o sistema não saber lidar com esta informação;
• Falha: Problema no código, que ao executar pode levar ao erro e ao defeito.
• Exemplo: Ao executar gera um defeito, ao animar detecta o estado de erro que possivelmente leve a falha no código.

Claro que assim como toda informação absorvida, para se tornar usual deve ser colocada em prática. Por esse motivo, apenas o uso diário e adaptado a rotina de trabalho irá auxiliar no tratamento de testes.

Observações

1. A utilização desses termos não são obrigatórias para funcionamento da prática de testes. Apenas foram destacados para entender a distinção de etapas.
2. Esse foi o primeiro artigo que escrevi, podem haver falhas técnicas ou falhas gramaticais. Em qualquer situação, gostaria MUITO de receber seu feedback positivo e negativo.