Diminuindo a Complexidade da Automatização de Testes

Os testes funcionais são os mais importantes e também os mais difíceis de se automatizar

Em tese basta adotar uma ferramenta de automatização, escrever os scripts e colocar para rodar periodicamente para se ter testes funcionais automatizados. Na prática é necessário que o teste seja escrito por um analista, executado pelo testador e automatizado pelo programador. Além de ocupar 3 funções, a programação é complexa.
As ferramentas de automatização são genéricas, atendendo a vários tipos de aplicações, a sintaxe dos scripts é vasta, genérica e mesmo com o uso de gravadores (registram as atividades enquanto um humano executa o teste) a programação é difícil e lenta. Outro agravante é a necessidade constante de alterações dos casos de testes existentes e da criação dos novos casos pois, é necessário que as manutenções, novas funcionalidades e situações de uso da aplicação sejam refletidos nos testes funcionais automatizados.
Ainda um outro aspecto relevante é a utilização de vários conjuntos de dados para o mesmo caso de teste. Em aplicações com muitas possibilidades de parametrização e perfis de usuários é importante que o mesmo teste seja aplicado usando vários conjuntos de dados e perfis de usuários com seus respectivos e específicos conjuntos de resultados.

Buscando a simplificação.

Desde uns 6 anos atrás temos, na Log.One, buscado formas de simplificar a automatização dos testes tirando um pouco o caráter puramente técnico do processo. Num primeiro momento o foco foi na simplificação dos conjuntos de dados associados a padrões de telas e não no script em si para que pelo menos os conjuntos de dados e testes de telas pudessem ser escritos por não programadores. O processo em si continuou dependendo de programação. Essa decisão foi acertada e tem sido usada na Log.One desde então: o caso de teste é definido pelo analista, programado por um programador e o conjuntos de dados/resultado é escrito diretamente pelo analista e/ou testador e sofre somente retoques antes de ser colocado para execução.

Exemplo de caso de teste programado em Java

Exemplo de planilha de testes automatizados

A decisão de se colocar os conjuntos de testes em planilhas foi meio natural e muito acertada. Chegamos a considerar o uso de um wiki, inspirados pelo Fitnesse, para a colocação dos dados em tabelas mas optei pelo uso de planilha em função da sua característica 'não técnica' de edição. Meio que por coincidência, em paralelo com a adoção das planilhas para os conjuntos de dados automatizados, trocamos o uso de uma ferramenta específica, o Testlink, pelo uso de planilhas também na escrita de casos de testes manuais... Acontece que já não fazíamos uso da parte do Testlink referente aos processos de aplicação dos testes (já estava nas tarefas do OpenProject) e o Testlink não é amigável na escrita dos casos de teste.

Exemplo de planilha de teste manual

Sendo o uso das planilhas bem sucedido na edição dos conjuntos de dados e na edição dos testes manuais, foi natural considerar a planilha também no processo de simplificação da escrita dos casos de testes.

Foco no contexto

Uma vez que as planilhas de dados para testes automatizados estavam atendendo perfeitamente, parti para a avaliação de como simplificar a escrita do caso em si, ou, em última instância: como não precisar do programador para automatizar o teste? como fazer o criador do caso de teste escrever o script do teste automatizado que refletisse o processo e não somente a tela?
Um programa de computador representa um contexto de trabalho. Eventualmente aplicações grandes são compostas por módulos onde cada módulo representa um sub-contexto da aplicação. Pensando dessa forma percebi que o conjunto de comandos necessários para se testar as funções poderia ser resolvido em um número menor, e bem definido, de ações automatizadas, ou seja: a solução natural foi criar uma linguagem específica para o domínio "Testes no Log.One". Em resumo: foi criado uma DSL, e seu interpretador, para testar o Log.One.

Exemplo de teste automatizado

É fácil observar a semelhança semântica entre o exemplo acima automatizado e o caso de teste manual (mais acima). De fato existe até mesmo semelhança de sintaxe com o objetivo de manter a familiaridade 'humana' das escritas.
Esse mecanismo está em fase experimental e com resultados promissores, sendo que a intenção final é que uma situação (teste de funcionalidade ou reprodução de bug) possa ser escrito nessa linguagem sem a necessidade anterior de execução na aplicação. Por exemplo: no processo de correções de bugs do Log.One, é necessário que o bug seja reproduzido e seu caso de teste seja escrito antes de delegar a tarefa ao programador. Quero que esses dois passos sejam um só, onde o analista escreve o caso de teste que reproduz o bug sem sequer precisar abrir a aplicação.

Trexho do fluxo de correção de bug

O próximo passo, considerando a adoção integral e bem sucedida dessa DSL, seria o uso de processamento de linguagem natural para diminuir a necessidade de sintaxe rígida na escrita dos casos e o aumento da amplitude dos comandos. Com a popularização das ferramentas de inteligência artificial e a evolução nos processos de aprendizagem, aliado ao fato de estarmos falando de contextos bem demarcados, essa não me parece uma meta muito longínqua, apesar de não ter certeza do real valor que seria agregado ;-)