Código finalizado, problema resolvido! Na verdade, não. Chegou a hora de identificar problemas que podem atrapalhar o trabalho do usuário.

Continuando a série A saga do herói… Ou melhor, do software!, hoje vamos falar sobre testes, a quinta atividade do desenvolvimento de software. Passamos por uma série de etapas que nos permitiram compreender as necessidades do usuário, refletir sobre o que o software deve fazer e como isso será feito, além da codificação de fato.

Teste de software pode ser definido como um conjunto de atividades que podem ser planejadas com antecedência e executadas sistematicamente para revelar erros nos artefatos desenvolvidos. Atenção para a parte “revelar erros nos artefatos”, uma vez que não é possível garantir que o software esteja 100% livre de erros, mas sim identificar e solucionar os erros existentes.

O objetivo aqui é não deixar essa tarefa de identificar os problemas para os usuários finais. Quem nunca xingou porque o jogo voltou para o início da fase ou teve que esperar horas numa fila porque o “sistema estava lento”?

Além disso, também é o momento em que é avaliado se o software construído é o software que o usuário realmente esperava receber. Imagens fortes a seguir, que representam bem essa situação…

Esses erros podem ter origem tanto por problemas na especificação do software quanto na implementação dele e vão demandar alterações no artefato gerado. Assim, os testes estão presentes em diferentes metodologias de desenvolvimento de software, podendo ser realizados após a implementação de determinada funcionalidade ou até mesmo no início do desenvolvimento, pensando primeiramente nos testes a serem executados e, após isso, escrevendo um código que passe neste teste.

Existem duas técnicas para testar um software: testes caixa-branca e testes caixa-preta. Ambas técnicas utilizam os casos de teste, que nada mais são do que um conjunto de instruções que descrevem uma condição particular a ser testada e é composto por valores de entrada, restrições para sua execução e um resultado ou comportamento esperado. Os testes caixa-branca, também conhecidos como estruturais, querem avaliar o comportamento interno do software. Assim, o código é analisado para elaborar um conjunto de casos de teste, garantindo que todas as instruções desse código foram executas pelo menos uma vez e que todos os possíveis caminhos foram exercitados. Já os testes caixa-preta, ou funcionais, querem avaliar o comportamento externo do software, sem considerar seu comportamento interno. Assim, utilizam a especificação para elaborar um conjunto de casos de teste.

Mais do que isso, para que um software seja completamente testado, seguimos uma estratégia de testes  que pode ser vista como uma espiral (outro texto interessante sobre o tema aqui):

Primeiramente, realizamos os testes de unidade que, como o nome já diz, testam as menores partes do software como subrotinas, classes ou pequenos trechos de código. O objetivo é encontrar problemas dentro dessa pequena parte independentemente do todo.

Após isso, passamos para os testes de integração. Normalmente os softwares não são organizados como um único bloco, mas como uma coleção de partes (componentes) que interagem para permitir o funcionamento do software. Assim, os testes de integração visam a encontrar problemas que surgem com a integração entre essas diferentes partes do software.

Também devem ser realizados testes de validação, em que os requisitos são validados em relação ao software que foi implementado. É nesse momento que são realizados os testes beta, conduzidos pelos usuários finais para identificar problemas nas versões quase finais do software.

Por fim, temos o teste de sistema, que visa executar o software sob ponto de vista e em condições similares do usuário final. Espera-se avaliar se o software é capaz de retomar o processamento em pouco/nenhum tempo após a ocorrência de algum problema, se os mecanismos de proteção incorporados ao software o protegem contra acesso indevido, como é o desempenho do software em tempo de execução etc.

Mas, como dito lá no início do texto, a identificação de um problema leva à necessidade de correção do software. Ou seja, vamos mexer novamente no código, mas não com o objetivo de construir o software, mas resolver os erros presentes nele. Durante essa correção, é necessário ter em mente algumas questões:

• “A causa do problema é reproduzida em outra parte do programa?”
• “Qual problema pode ser introduzido pelo ajuste realizado?”
• “O que poderia ter evitado esse problema desde o início?”

Somente assim o problema será realmente corrigido e teremos menos chances de gerar novas “dores de cabeça” ao tentar consertar os problemas identificados.