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 :