Desenvolvimento ágil - Artigo Clube Delphi 125

Antes de tudo é preciso saber que não importa se o teste será feito com técnicas automatizadas ou não, o importante e testar. Existem outras maneiras de testar o software, como por exemplo, contratar pessoas especialmente para esta função. Esta provavelmente não é a melhor alternativa, mas é possível e deve trazer bons resultados. O importante é executar os testes não importa se eles serão automatizados ou não.

Por outro lado, além de tornar o software mais barato, quando você automatiza os testes você também codifica mais rápido e quando tiver que fazer modificações poderá fazê-las mais facilmente e com mais segurança: você não estará preocupado se sua última alteração estragou outras partes do sistema.

É comum que as pessoas se assustem quando começam a estudar sobre teste unitário, pois existem muitos termos técnicos sobre o assunto como “caixa branca”, “testes de regressão”, “fases de testes”, entre outras. Isso é o suficiente para assustar alguém que provavelmente não vai mais nem querer ouvir falar em técnicas de testes. Todos estes termos fazem os testes parecerem complicados, mas não são. Vou explicar o porquê.

Por que os testes são simples

Existe uma sequência natural para o processo de desenvolvimento de um projeto e os testes estão nesta seqüência. Quando você começa a criar um programa ou uma nova parte dele, naturalmente a primeira coisa que você precisa é saber o que esta nova função deve fazer, sendo assim os testes devem ser criados para validar se a nova opção faz o que deveria fazer.

Depois que os testes passarem o sistema estará fazendo o que precisa: a próxima etapa é garantir que ele faz do jeito certo. Para isto outros testes serão executados, seja por você mesmo ou por outras pessoas. Nesta etapa serão testados itens como desempenho em situações extremas, facilidade de uso, clareza das mensagens, padronização das telas, funcionalidade entre outras coisas: o objetivo é refinar a opção. Existe um tipo de teste que se adapta melhor para cada tipo de “refinamento”, por este motivo existem tantos termos técnicos. Não se concentre de mais com o nome de cada fase (refinamento): tenha em mente que cada opção deve passar por várias fases de testes para melhorar a qualidade.

Todo este processo é natural. Primeiro o sistema é codificado par afazer o que precisa fazer. Depois uma série de procedimentos são executados para refinar o programa e garantir que ele faz o que deve fazer do jeito certo. Você poderia fazer isso sem estudar nada sobre testes, mas seria mais difícil. As técnicas de testes existem para facilitar o trabalho de refinamento e aumentar a qualidade do software.

Teste de software: o que é?

Teste de software é qualquer procedimento com o objetivo de provar que o software não funciona corretamente. Estes procedimentos podem ser executados por uma pessoa ou podem ser automatizados em pilhas de testes que ficaram cada vez mais completas à medida que o projeto madurece.

A diferença mais evidente entre um projeto desenvolvido orientado a testes e outro não orientado a testes está no processo de desenvolvimento. Enquanto que um começa a partir do teste automatizado e só é criado o necessário para o teste passar, o outro é simplesmente construído e em algum momento no futuro os testes serão executados por um humano. Por serem executados por humanos não há garantia de que os testes serão fielmente repetidos sempre que algo mudar.

É comum pensar que criar classes de testes aumenta o tempo de desenvolvimento do software tornando-o mais caro e até mesmo inviável. Este é um pensamento equivocado, pois de modo geral programas desenvolvidos com base em testes são mais simples e fazem somente o que devem fazer uma vez que será escrito somente o necessário para o teste passar. Dificilmente o tempo é desperdiçado com algo que não seja realmente necessário.

Quem programa com bases nos testes que cria, ganha tempo quando precisa encontrar um erro, pois raramente será necessário debugar o programa para encontrar um erro: basta rodar o teste e ele aponta onde exatamente está o problema. Algumas metodologias de desenvolvimento de software nos levam a criar classes de testes antes mesmo de criar a opção em si: este a meu ver é o cenário ideal. No decorrer deste artigo você verá como fazer isso.

Escrever testes para todas as classes que você criar deve ser uma realidade no seu dia-a-dia. Além de ser um requisito do modelo ISO de qualidade de software, os testes levarão o seu projeto para outro nível de qualidade. É claro que a qualidade dos testes, e consequentemente do produto final, depende diretamente da pessoa envolvida, mas mesmo assim um programa desenvolvido orientado a testes normalmente consegue atingir o objetivo com mais clareza e em menos tempo.

Teste de software: o que NÃO é?

Testar um software não é debugar. Ao contrário da fase de codificação, cujo objetivo é construir o software, o teste é um processo que visa desmontá-lo para provar que ele não funciona ou que tem erros. Os testes devem ser escritos como se quem os escreve tivesse sido desafiado a provar que o programa tem falhas, como se já soubesse que as falhas existem e encontrá-las é apenas uma questão de tempo.

É difícil garantir que um software não tem erros, visto que normalmente existem muitas variáveis para avaliar, o que aumenta a complexidade. Um software pode falhar por vários motivos, como: problemas de hardware, erros de codificação, requisitos errados, mensagens pouco claras, entre outros motivos. A quantidade de pessoas envolvidas no projeto e qualificação de cada uma também influencia diretamente na qualidade do produto final. Além disso tudo, ainda tem o fato de que as alterações são constantes e normalmente muitas ao mesmo tempo: parece um ambiente caótico para quem não conhece.

Ainda hoje existem pessoas que pensam nos testes como uma tarefa secundária, porém há muito tempo escrever testes passou a ser uma fase do desenvolvimento assim como a análise e implantação. Os testes fornecem informações preciosas sobre o nível de qualidade de software em relação ao contexto que ele pertence.