Testes de Software - 2

BSI03

O artigo trata da importância de Testes de Software no processo de desenvolvimento, e o quanto ele pode garantir que sistemas tenham seu nível de qualidade na entrega acrescido. Através dos testes é possível filtrar grande parte de erros muitas vezes simples e de fácil resolução que não foram descobertos pelos desenvolvedores e que se fossem para cliente poderiam causar um constrangimento ou mesmo quebra de contrato.

Muitas vezes ele é descartado por empresas pelo fato de custar muito caro ( em torno de 40% do tempo, segundo pesquisas em empresas que adotam a metodologia) e por ter seus objetivos mal compreendidos. Assim, pensar que os testes devem ser executados de maneiras apenas manuais e cansativas ou que os testes apenas irão demonstrar as funcionalidades implementadas no sistema são equívocos comuns que desencorajam a utilização desta fase tão importante do ciclo de desenvolvimento.

Existem muitos tipos de testes que podem ser aplicados em momentos diferentes do desenvolvimento e de formas diferentes. Alguns são realizados de maneiras automatizadas (geralmente em testes que devem ser executados com maior freqüência ou que exijam imparcialidade) evitando que, por exemplo, um usuário que já esteja acostumado com o sistema passe pelos erros sem notá-los, devido ao vício causado pela constante utilização, ou mesmo para evitar que isto se torne uma atividade enfadonha para quem tem que testar. A automatização é muito útil em testes de unidade ou de integração.

Testes de Softwares são comumente relacionados a cores, onde os testes de caixa-branca representam a parte de testes responsáveis por garantir que todas as partes do código fonte estão funcionais e sem erros. Testes de caixa-preta preocupam-se apenas com os requisitos do software, verificando se estes estão sendo atendidos. E por fim também existem os testes de caixa-cinza que é a mesclagem entre os testes de caixa branca e preta.

Para que a execução dos testes seja feita de forma padronizada, existe uma área que deve ficar responsável apenas por isto. Nesta área encontram-se profissionais como testador, que executa o testes, analistas responsáveis pela montagem de ambiente e pela definição das condições dos testes, além do engenheiro que provê as soluções e o gerente que é o responsável por todo o processo.

Com isto percebe-se que testar software é algo bastante abrangente, mas que não deve ser utilizado sem a análise do projeto como um todo. Devido ao alto custo na execução de testes e a grande variedade de tipos é fundamental que se perceba quais testes realmente são necessários para o sistema e executá-los. Quando mal interpretados, testes podem elevar o custo/tempo de um projeto e não trazer o objetivo esperado, já que de nada adianta eu ter um teste de integração se meu sistema não é em módulos, por exemplo.

Testar deve ser premissa em desenvolvimento de software e isto é uma questão de cultura que deve ser adotada pela equipe como um todo. Eleger profissionais responsáveis por ferramentas ou testes mais pesados é excelente, mas se o programador não faz a parte dele fazendo um teste unitário ou outro teste mais simples que seja (mesmo manual) e pensando que encontrar os bugs é responsabilidade do testador só fará com que exista uma transferência de responsabilidade sobre o software parecendo que se o sistema tem bug é “problema” do testador.

Quando existir cooperação entre todos da equipe e a visão de que o produto é da empresa, testar passará a ser sinônimo de garantir um bom trabalho e com certeza um aumento de qualidade no que será percebido no que for entregue ao cliente final. Testar deixará de ser atividade trivial e desgastante para ser rotineira e gerar bons resultados.