TESTE DE SOFTWARE

Por que fazer testes? Segundo a lei de Murphy, se algo pode dar errado, vai dar. Se tudo parece estar indo bem é por que você não está prestando atenção… e a natureza sempre fica do lado do erro escondido. Ou seja, ninguém é infalível e um erro é sempre muito mais evidente do que centenas de acertos.

Alguns programadores acham um martírio testar softwares, ou se sentem humilhados, porque se fossem bons o bastante não precisariam realizar testes.

Alguém já ouviu as frases?

“Aqui está funcionando…”

“Estranho, isso não era para acontecer…”

“Nossa, como você conseguiu fazer isso?”

São frases bem comuns e geralmente são respostas de desenvolvedores para usuários.

O que os desenvolvedores precisam ter em mente é que o usuário não sabe o que eles sabem e consequentemente usarão o aplicativo de maneira diferente do que eles usariam, encontrando assim falhas que passam desapercebidas aos desenvolvedores. Quanto mais testes forem feitos, será melhor!

Primeiramente deve ser definida uma saída especifica esperada, e esta saída deve ser exaustivamente analisada. Os testes precisam verificar condições válidas e inválidas.

Quem testa destrói o software em busca de erros e falhas, quem desenvolve, como está em um processo de construção, fica cego para esses erros, por isso equipes diferentes precisam ser utilizadas para desenvolvimento e teste.

O ideal é usar testes de regressão, que verificam a evolução da qualidade do software conforme o desenvolvimento for fazendo alterações. Testes descartáveis podem empobrecer o resultado final.

O teste pode ser divido em 4 fases iniciais.

Teste de unidade:

São feitos testes isolados em pedaços do aplicativo, uma vez que a unidade é a menor parte testável de um software. Geralmente as unidades são independentes, facilitando assim o teste individual. Nesse momento são testadas entradas válidas e inválidas.

Entradas válidas são as previstas pelo sistema e as inválidas são aquelas onde, por exemplo, o código aceita 1 ou 2, ao colocar 3 deverá haver um tratamento para o retorno do erro.

Teste de integração:

Essa fase é onde os módulos passam a conversar entre si… neste ponto do teste são identificados erros de interface e de módulos soltos, sem integração.

Teste de sistema:

Nessa fase os módulos estão integrados, e será testado o conjunto, a funcionalidade, as entradas e as saídas.

Teste de aceitação

O teste de aceitação é a fase final do teste… geralmente esse teste é feito por usuários finais em locais semelhantes ao que eles usariam o software.

Outras fases

Fora essas fases ainda podem ser incluídas as fases onde são testadas versões ALFA, BETA e as versões RC.

Versão ALFA: 

É testada dentro do ambiente de desenvolvimento por usuários finais, onde o desenvolvedor pode verificar e anotar todos os erros que forem apresentados e assim corrigí-los… depois disso é disponibilizada para um grupo restrito e selecionado a versão beta.

Versão BETA:

A versão beta é testada em um ambiente não controlado, e o “testador” relata os problemas encontrados periodicamente ao desenvolvedor. Depois dessa fase, em alguns casos, como nas comunidades de software livre, são lançados os “RELEASE CANDIDATE”.

Versão RC: 

É uma versão beta com uma quantidade pequena de erros, geralmente aberta para toda comunidade realizar testes. Essa versão é a candidata a virar versão final.

TÉCNICAS DE TESTES

Existem algumas técnicas de teste, passando por técnicas usando usuário finais, profissionais da área… entre muitas, seguem então as mais famosas :

Teste de Caixa-branca ou teste de bolas brancasTesta o código fonte, códigos e algorítimos. 

Esse teste garante que TODAS as linhas de código sejam executadas ao menos uma vez. Garante também que todas as possibilidades lógicas: True e False sejam testadas e verifica a validade do código, identificando sujeira e código inútil.

Teste de Caixa-preta ou Teste de bolas pretas

Testa a interface e a saída. Dados de entrada são fornecidos e os dados de saída são comparados a saída esperada. Quanto mais entradas são fornecidas, mais completo é o teste. Em um teste perfeito TODAS as entradas seriam testadas, mas na maioria dos casos isso é impossível, por diversos motivos: dinheiro, tempo, mão de obra… O ideal é escolher um bloco de entradas que enriqueça o teste.

Basicamente o teste da caixa preta é um teste de uso, onde botões, links e execuções são testadas e validadas. O teste da caixa preta pode ser executado em todas as fases do teste.

Teste de Caixa-cinza

É um misto entre os testes da caixa branca e da caixa preta, analisando o código, as entradas e as saídas… em alguns casos é feito inclusive engenharia reversa.

Plano de testes

O plano de testes deve ser escrito ANTES do teste ser efetuado e deve ser seguido. O plano de testes identifica as necessidades a serem testadas, os métodos a serem usados e os passos a serem seguidos.

Considerações finais

O teste precisa ser objetivo, analisar os itens e encaminhar os erros aos desenvolvedores. O teste deve ser contínuo e paralelo ao desenvolvimento.

Os testes são feitos em fases diferentes, por pessoas diferentes, desde profissionais criativos e qualificados até chegar ao usuário final. 

Os testes precisam trazer uma revisão e uma correção antes da implementação. Os testes são preventivos e não corretivos!