Lições Aprendidas com Teste Automatizado

Meu nome é Ieda Alves e a quase 3 anos eu trabalho aplicando testes automatizados nos produtos desenvolvidos pela empresa onde eu trabalho.

O que é importante saber sobre o teste automatizado?

Primeiro de tudo, para se realizar esse tipo de teste é preciso fazer uso de uma ferramenta que automatize as funcionalidades do sistema. Existem várias no mercado, porém neste artigo vou me ater a apenas uma para garantir o foco.

Segundo, quem garante a eficiência e cobertura do teste não é a ferramenta e sim o tester, ou seja, você ou a pessoa que utilizará a ferramenta. Como a própria denominação “Ferramenta” já diz, o software de automatização é um utensílio de trabalho, não faz milagre sozinho. Cabe ao testador e gerente de teste programar e planejar a execução da automatização de teste.

Terceiro e não menos importante, o planejamento e priorização do teste farão a diferença na dinâmica de gravação dos testes. Conhecer o sistema que será testado faz parte do planejamento, não saber o comportamento e estrutura do que se pretende gravar provavelmente proporcionará tempo e dinheiro jogado fora.

Ferramenta de automação de testes.

Apesar de existirem N ferramentas existentes por ai no mercado como Arbiter, Selenium, TestComplete entre outras, este artigo tratará apenas da ferramenta proprietária Rational Functional Tester – IBM.

A RFT (Rational Functional Tester) é uma solução de teste funcional e de regressão automatizada para equipes de QA preocupadas com a qualidade de seus aplicativos Java™ baseados na Web, Microsoft® Visual Studio, NET®, baseados em terminal, SAP, Siebel e Web 2.0.

Atualmente a RFT está na versão 8.2.1 e as atualizações são garantidas pelo sistema web da IBM. Claro que como um software proprietário é preciso ter a licença para poder fazer as ditas atualizações. Diga-se de passagem, não é um software barato.

O software utiliza a plataforma Eclipse como suporte às funcionalidades e interface e os testes são executados na ideologia gravar/reproduzir. A gravação é iniciada e basicamente todas as ações do testador no sistema são gravadas na forma de scripts em linguagem Java ou Visual Basic. Os scripts são totalmente editáveis e passíveis de manipulação.

Após a gravação é só mandar reproduzir o script gravado, todas as ações serão repetidas conforme executado pelo testador. A ferramenta fornece um relatório na forma de log dos eventos manipulados pelo escript, inclusive se durante a execução aconteceu algo inesperado.

Também é possível manter revisões dos scripts em um repositório SVN, assim é mantido a rastreabilidade de tudo que foi gravado.

Em conjunto com a RFT utilizo outro software chamado Test Mananger, também da IBM. Este software faz o gerenciamento e a aglutinação dos scripts criados na RFT. É neste momento que a estrutura seqüencial e funcional do teste é criada. São criadas as suítes de execução que por sua vez incorporam os Test Cases (Casos de testes – os scripts). É esta execução em cadeia que garante a qualidade do teste automatizado.

Nesta ferramenta também é possível configurar e recolher evidências dos testes, como por exemplo, logs de execução, gráficos e relatórios populados, o que agrega grande valor a execução do teste automatizado, uma vez que comprova as funcionalidades do sistema testado, na forma de documentação também automática.

Experiência do testador.

Tudo isso parece uma maravilha, porém não é esse “mar de rosas não”, as ferramentas são "temperamentais" e é ai que entra as habilidades dos testadores. O que está descrito no site de especificações das ferramentas não ajudam muito, o que vale mesmo são as lições apreendidas durante o projeto piloto.

Existem muitos detalhes que não são nada intuitivos e alguns comportamentos que as ferramentas não tratam, incompatibilidade com o browser é uma delas, e isso precisa ser contornado.  Sem falar na oneração do processamento e acumulo de cache.

O testador precisa mais do que nunca do seu perfil investigativo, pois é difícil trocar experiências a respeito da RFT. O Site da IBM muitas vezes se transforma em um labirinto, principalmente no início, quando se está começando. Até se encontrar algo útil levam-se horas. Ir a fundo nas configurações algumas vezes pode estragar com tudo, por isso deve sempre anotar ou guardar as configurações originais ou seja, aquele backup sempre será uma boa idéia. Precaução e bom senso são as palavras.

Planejamento dos Testes

Para se automatizar um sistema é preciso que o mesmo esteja estável, pois o  objetivo principal do teste automatizado é homologar um produto garantindo que os recursos já validados em uma versão anterior continuam funcionando após a inclusão de novas melhorias/requisitos.

O teste automatizado começa antes da gravação propriamente dita, o mais importante na hora de automatizar um sistema é conhecê-lo. Saber o seu fluxo de funcionamento, suas dependências entres registros, entrada e saídas. Assim é possível criar um roteiro de gravação.

O roteiro de gravação é um documento que serve como guia e recolhimento de informações acerca do sistema. Nele devem estar relatadas as dependências entre registros, ou seja, os pré-requisitos para cada registro a ser gravado, além disso, deve estar descrito o fluxo que se deve seguir dentro do sistema, por onde começar e todas as etapas críticas que precisam ser gravadas.

Uma técnica também muito utilizada é chamada de "stubs", que consiste em popular os registros / telas mais simples e com poucos campos através de scripts e/ou congelando a base de dados já com esses dados inseridos. A automatização de um sistema deve ter como foco garantir o fluxo principal e os requisitos crítico do sistema em automatização.

Com base no roteiro de teste fica muito mais fácil criar os Casos de Testes. Cada script pode ser um caso de teste, isso vai depender da métodologia adotada pela área de teste, porém criar scripts muito logos nãp são uma boa idéia, principalmente na hora de manutení-lo.

Por enquanto esse artigo fica por aqui, espero futuramente contribuir mais sobre as peculiaridades do teste automatizado e da ferramenta RFT com as minhas experiências e rotinas de trabalho.

Ieda Alves.