Automação de testes com o Robot Framework

Embora muito importante para identificar falhas que muitas vezes passam despercebidas pelos desenvolvedores, a prática do teste de software é algumas vezes desconsiderada pelas empresas. Essa atividade não faz mais parte do processo de desenvolvimento, executada por programadores e analistas de sistemas, e agora deve fazer parte de um nível de processo mais qualificado.

Nas empresas desenvolvedoras de software, já existem equipes com profissionais altamente qualificados e experientes, responsáveis por fazerem toda a análise técnica de testes funcionais, não permitindo que erros e falhas passem despercebidos, promovendo, cada vez mais, a qualidade no produto desenvolvido. A verdadeira intenção ao se prover testes em um software é garantir a produtividade aliada à qualidade.

Felizmente, hoje em dia há uma gama de ferramentas para a automação de testes de software. Tais ferramentas têm como objetivo controlar a execução dos testes e comparar os resultados alcançados com os resultados esperados. A automação de teste é extremamente útil para realizar testes repetitivos – mas necessários – ou difíceis de se realizar manualmente.

Este artigo tem como objetivo apresentar a ferramenta de automação de testes Robot Framework, bem como sua integração com a IDE Eclipse através da utilização do plugin Apache Maven 3. Para melhor ilustrar as capacidades da ferramenta, este artigo também propõe uma explicação básica sobre testes de aceitação.

Automação dos Testes de Aceitação

Geralmente realizados nos estágios finais de desenvolvimento com um pequeno grupo de usuários, os testes de aceitação de software realizam testes de caixa preta inserindo dados em um programa para verificar suas saídas. Uma das vantagens dos testes caixa preta é que não há necessidade de se conhecer o código fonte para testá-lo – ou seja, para se realizar esse tipo de teste, não é preciso entender como uma determinada operação é realizada, mas sim o que ela deve fazer.

A diferença entre o teste de caixa preta, utilizada no teste de aceitação, e o teste de caixa branca, é que nesse último é possível examinar o código fonte em busca de pistas que podem ser úteis para o teste. Contudo, essa mesma liberdade proporcionada pelo teste caixa branca pode se tornar um problema quando o examinador tenta manipular os testes para que eles façam sentido dentro das operações do código – mesmo que estejam erradas.

O maior problema desses testes é realizá-los manualmente, pois demandam muito tempo e esforço, ainda mais levando-se em consideração o quão repetitivo são os cenários de teste. Uma solução encontrada é a de dividir os casos de teste mais importantes e, assim, reduzir a quantidade de testes que serão feitos. Contudo, isso acaba trazendo riscos, visto que haverá, como consequência, uma menor cobertura.

Outra saída encontrada foi o desenvolvimento guiado por testes (TDD, Test-Driven Development), que organiza o processo de desenvolvimento, análise e teste do código de forma unificada e síncrona. Essa prática ajuda o desenvolvedor a manter, além da qualidade do software ao longo do processo, um controle maior sobre a organização do código fonte. No entanto, mesmo com um intervalo de tempo maior entre os testes, acaba havendo um aumento nos casos de teste – o que é um ponto positivo, pois aumenta a cobertura –, e a realização dos mesmos continua maçante."