Por Weverton Parreira (*)

O que são testes? O que lhe vem à mente quando pensa em testes? Validar se o comportamento da aplicação é o esperado? Se tudo está correto?

Não é bem assim… Quando realizamos um teste partimos da premissa que existe um problema. Se não houvesse algum problema não seria preciso testar, certo? O objetivo do teste é encontrar o problema. O teste é uma busca por erros, no sentido de evitar defeitos no código e consequentemente falhas na execução da funcionalidade/software.

Numa única frase temos três conceitos diferentes, mas que muitos julgam ser o mesmo: o erro, o defeito e a falha. Um Erro basicamente é um engano. Seja na definição dos requisitos ou de outras interpretações do negócio. Quando o erro é introduzido no Código passa a chamar-se Defeito. E quando esse defeito é executado temos uma Falha.

Para exemplificar, imagine que eu sou analista num Banco. O Banco quer disponibilizar um novo tipo de empréstimo para os clientes. Então eu como analista que não entende de matemática financeira, faço uma fórmula para o cálculo dos juros a serem cobrados num empréstimo e acrescento à minha documentação dos Requisitos. A minha fórmula tem um Erro. O código é desenvolvido com base naquele erro e tem-se ali um Defeito. Mais adiante a funcionalidade vai para teste ou, na pior das hipóteses vai para produção, e quem vai validar aquele cálculo percebe que não está certo. Foi gerada uma Falha.

O cálculo errado pode ser tanto para um valor maior como menor. Se considerarmos que esse cálculo errado foi realizado já em produção temos como Falha um prejuízo para o banco ou para o cliente.

Quando pensamos em testes geralmente pensamos no ato de executar um teste de uma funcionalidade de um sistema. Daí a nossa tendência em achar que o teste é uma ação, mas na verdade o teste é um processo.

Esse processo é composto por sete passos:

  1. Planeamento: Deve planear-se as atividades e definir os objetivos dos testes;
  2. Controlo e Monitoramento: Aqui é o momento de comparar o progresso do que foi planeado e o progresso real;
  3. Análise: Basicamente é identificar as funcionalidades a serem testadas;
  4. Conceção: É o “como” testar cada condição. Gerar dados para testes, ambientes, etc;
  5. Implementação: Onde respondemos se já temos tudo o que é preciso para realizarmos os testes;
  6. Execução: Como o nome diz, é realmente executar os testes com base nos passos anteriores;
  7. Conclusão: Geração do diagnóstico. Identificação das falhas e geração do relatório para correções.

Temos também um fator interessante que é a Psicologia do Teste que costuma ser subestimada. A mentalidade do Developer é diferente da mentalidade do Tester. O Developer tem a mentalidade mais positiva, ele quer criar a solução para algo. Já o Tester tem uma mentalidade mais “negativa”, ele quer encontrar um defeito. Esse tipo de divergência pode gerar um certo conflito na equipa e por isso esse fator é tão importante de ser trabalhado.

Na psicologia temos um fator chamado “confirmação tendenciosa” que é a dificuldade que temos em aceitar uma informação contrária à nossa crença e consequentemente admitir que possamos ter cometido um erro. Então quando eu faço uma especificação, uma estória, eu assumo que aquilo está bom e correto. Se alguém se opõe, e considera que o que eu fiz não está correto, gera-se ali uma divergência porque eu terei sempre a tendência de acreditar que o que eu fiz está correto. Por isso é preciso essa interação entre as pessoas da equipa, para que se passe a ter uma visão mais ampla, aceitar a opinião do outro e gerir essas diferenças.

Assim como temos sete passos no processo de testes, temos também sete pilares:

  1. Os testes evidenciam a presença dos defeitos e não a sua ausência;
  2. Ausência de erros é uma falácia, porque todos os softwares que estão em produção têm falhas. Não existe um software sem falhas. O que acontece é que certas falhas precisam de dados tão incomuns, tão difíceis de serem encontrados, caminhos tão difíceis de serem percorridos, que aquela falha dificilmente se vai manifestar.
  3. Testes exaustivos são impossíveis.
  4. Os defeitos agrupam-se, percebendo-se onde está a maior parte dos defeitos consegue-se mais facilmente chegar à solução do problema;
  5. Testes são dependentes do seu contexto. Teste de softwares desenvolvidos em metodologias ágeis são diferentes dos testes para um desenvolvimento sequencial (waterfall)
  6. Paradoxo do pesticida: Refazer sempre os mesmos testes não trará resultados diferentes. É como nas plantações usar-se repetidas vezes um mesmo pesticida e este acaba por não ser mais eficaz porque os insetos já adquiriram resistência.
  7. Testar cedo poupa tempo e dinheiro. Os testes não precisam iniciar-se apenas ao final do desenvolvimento. Testes dinâmicos. Podemos iniciar os testes ainda na fase de definição dos requisitos com os chamados testes estáticos onde já se consegue prever possíveis falhas e tratá-las antes do desenvolvimento. Este tipo de teste é feito basicamente como uma revisão à documentação que será disponibilizada para o desenvolvimento.

Além disso podemos dividir os testes em duas categorias: Caixa Preta e Caixa Branca. Para ambas as categorias serão testados os componentes, as integrações e o sistema em si.

A diferença aqui é que os testes de Caixa Preta vão abranger os testes funcionais, não-funcionais e negociais. Já os testes de Caixa Branca vão servir para validar o código, a base de dados e a arquitetura. Por isso, esses testes devem ser feitos por pessoas Senior em cada uma das áreas. Uma alternativa quando não se pode ou não é viável ter uma equipa de testes de Caixa Branca, é ter um conjunto de boas práticas e alguém mais Senior na equipa para fazer uma validação. Existem ainda plataformas que conseguem validar essas boas práticas no caso de aplicações mais robustas.

Para finalizar o processo, passamos então aos testes de aceitação, que devem ser feitos por pessoas que não estiveram envolvidas nem nos testes de Caixa Branca, nem nos testes de Caixa Preta e preferencialmente alguém que tenha conhecimento do negócio.

Os testes ainda não têm sido um ponto de grande relevância para as empresas, mas a sua importância para o sucesso de um projeto é altíssima. Podemos ver essa diferença no índice de certificações. São apenas pouco mais de 721 mil certificações em testes no mundo em relação a milhões delas quando falamos em áreas de desenvolvimento de software.

Não subestime os testes porque este processo é o que define o sucesso do seu projeto.

(*) Consultor Funcional na Create IT