O início 

Tenho atuado em testes de software desde 2006, em um projeto de inserção de testes em uma empresa de projetos para mobile. Como a maioria faz ao começar na área, iniciei como testador de testes funcionais (manuais), mas em pouco tempo, fui induzido a fazer testes automatizados para mobile. Na ocasião, o framework de automação utilizado era um framework próprio da empresa, que foi um importante avanço na automação de testes de software. Nessa ocasião, os testes automatizados eram de testes funcionais, testes de performance e carga.

Aprimorando os conhecimentos

Foi apenas nos meados de 2010, que tive contato mais real com o mundo da automação. Selenium + JUnit + Java, até então, o trio mais influente na época. Foi uma experiência muito prazerosa automatizar testes com Java, aprendendo como funciona o Selenium, copiando e colando ações do Selenium IDE.

Eclipse com Junit e Selenium

Para mim foi um momento muito importante em minha vida profissional, foi o ponto no qual pude ter uma nova visão da área de Testes de Software.

Separação momentânea

Em 2012 uma mudança de atividade promoveu uma separação, não esperada, necessária para o cargo assumido. Assumi a liderança de uma equipe de testes, logo mudando o foco nas atividades, deixando o operacional para o gerencial.

Os conhecimentos de automação anteriores foram cruciais para que, gerencialmente, eu pudesse tomar algumas decisões gerenciais, funcionais e operacionais, porém o esforço da automação ficava com a equipe de testes, para mim sobrou estudar as ferramentas/metodologias e avaliar a implementação delas no processo.

A retomada

Em 2016, após implementado e estabilizado todo um processo de testes na empresa, pus em prática um desejo antigo, incluir no processo um novo “braço”, a automação dos testes. Foi onde retomei o meu contato com o mundo da automação, reavaliando as ferramentas atuais, para definir e implementar a melhor solução de automação para a fábrica de testes da empresa.

Nesse momento voltei a utilizar o Selenium, o JMeter, entre outras ferramentas, e iniciei o contato com a então “febre”: Cucumber. Até então as ferramentas escolhidas foram para serem executadas juntos a projetos Java, aproveitando o conhecimento adquirido, e por ser uma linguagem utilizada na maioria das soluções da empresa.

“Mudando a chave”…

Em 2019 fui submetido a um novo desafio. No meu ingresso à DB1, fui incentivado à “mudar a chave” de meus conhecimentos e procurar expandi-los e ajudar o projeto atual e a equipe de testes.

Inicialmente houve uma conversa sobre pontos a serem levantados no PDI, um ponto abordado, considerado importante, foi o aumento e melhora de conhecimentos de ferramentas automáticas (visando justamente o período no qual foquei em atividades de liderança). Logo na primeira semana o desafio foi lançado, desenvolver um framework para automatizar testes de mobile, porém em RUBY.

Isso mesmo, o meu desafio será mudar a automação de JAVA, no qual tenho certa familiaridade, para o RUBY, que nunca obtive um contato direto. Salientando que ainda não tinha experiência direta para automação em Mobile, diferente do que já havia executado no início de nossa conversa, quando o framework era interno e já estava pronto.

“Mudar ou não mudar, eis a questão”.

Durante os estudos para a iniciação no Cucumber para Ruby + Capybara, comecei a ver o quão simples é estruturar um projeto Ruby em relação ao Java. Ruby é uma linguagem muito boa para fins de automação de testes, de fácil compreensão e muito produtiva, principalmente para quem está iniciando na linguagem. Para aprendizagem, o Ruby é relativamente melhor que o Java.

Estrutura de projeto no VSCode com Cucumber + Ruby

Confesso que o impacto inicial com o Ruby foi grande, justamente por ser uma linguagem mais simples que o Java, também por ainda está com a mente muito acostumada com o Java. Muitas das vezes eu ficava me perguntando “de onde vem essa variável? Que método é esse? De onde isso surgiu?”, uma vez que estava habituado com a “burocracia” do Java, tendo a obrigação de declarar todas as variáveis, tipificando-as e especificando cada método/variável.

Estrutura em Java e Selenium com Page Object:

Estrutura de projeto no Eclipse em Java com Selecion + Appium + PageObject

Contudo, visto de outra forma, essa “burocracia” do Java torna o código mais amarrado e organizado, que para muitos, é melhor para debugar ou até mesmo “entender” o código de terceiros.

Estrutura em Ruby, Capybara e Page Object:

De início, foi assustador ver que o Ruby tem uma sintaxe mais simples, fazendo com que a curva de aprendizado seja menor, (para iniciantes, isso é um diferencial). Mas por um outro lado, já confessei um certo “desespero” com tanta facilidade, principalmente em entender as “aparições” de variáveis, surgimentos de métodos do nada. Para quem estava acostumado com a “amarração” que o Java requer, necessitaria algum tempo para se adaptar com tanta simplicidade.

E as GEM’s (ou gloriosas gemas)?

Uma das coisas mais legal em aprender o Ruby foi descobrir que temos as Gems: bibliotecas do Ruby, com elas tem-se uma facilidade a mais para desenvolver, pois estão em um único local, tudo muito fácil, rápido e extremamente geniais. Basta acessar o site www.rubygems.org, uma mina de ouro.

É muito bom saber que com uma única linha de comando é possível ativar uma biblioteca inteira, que minutos antes não estava nem instalada no computador, oferecendo-nos novos recursos e possibilidade. Daí vem o surgimento de métodos “do nada”, que anteriormente mencionei.

Acesse o RubyGems.org e descubra ainda mais sobre o mundo incrível das GEMAS.

Ainda não sou um expert em desenvolvimento, tenho minhas dificuldades e estou anos atrás de muita gente, mas a minha análise dessa transformação foi a melhor possível, além de aprender novas ferramentas eu pude mudar alguns paradigmas de programação e perder o “medo” da busca dessa mudança. Foi preciso um desafio, tornar algo obrigatório, para que eu pudesse me posicionar de uma forma mais segura em aceitar conhecer novas linguagens.

Sobre o Ruby, por ser uma linguagem dinamicamente tipada, senti-me confortável em aceitar esses novos conhecimentos, pois com ele tem-se flexibilidades e praticidades. No geral, se escreve bem menos para alcançar o mesmo resultado, sem perder a “legilibilidade” no código.

Repito não sou um expert em programação, mas vai um conselho àquele que automatiza em Java, não fique bravo, fique calmo, não é minha intenção, nesse texto, falar mal do Java, estou descrevendo a minha experiência em tentar aprender automação de testes em outra linguagem, e sabe-se que não é uma tarefa fácil introduzir automação de testes para testadores que sempre fugiram da programação, e nesse ponto com Ruby é menos complicado que com o Java.

Portanto, deixo uma dica para o testador tradicional, resistente às mudanças, não deixe de procurar mudar por medo ou por já está acomodado com uma linguagem, enriqueça seus conhecimentos, pois, com certeza, vai se surpreender.

Referências

Para a criação do texto, utilizei os dois links abaixo. Eles também podem ajudar você:

9 Razões para aprender Ruby on Rails (RoR)

Ruby: vale a pena investir nessa linguagem?