A "arte de desenvolver testes"

Falar de automação de testes talvez seria uma das últimas coisas que eu faria, e ca estou eu e o intuito é passar a visão de alguém que lutou e lutou e que no fim resolveu “dar uma chance” para a tão sonhada e para alguns a bala de prata, chamada automação. E a primeira dica que talvez eu possa dar é que para que haja o primeiro passo, o cidadão tem que simplesmente “querer” e na época eu quis e tive a ajuda e talvez um “norte” do meu grande amigo Eduardo Freitas, que naquele momento estava realizando um trabalho de automação no SAP e foi me passando um pouco sobre automação no selenium IDE. Já havia trabalhado com IDE algumas vezes.

Bom o intuito aqui é mostrar que pode ser interessante e muito divertido “desenvolver testes”, vou chamar assim para que não haja fantasmas quando se fala em “automação”. Eu acredito que palavras geram bloqueios e que títulos novos geram motivação e curiosidades. Vou enumerar para que fique bem fácil, assim como foi pra mim =).

1. O início

Acredito ser a principal parte, que nada mais é que a curiosidade em dar uma chance. Se der uma chance por si só, sem que haja pressão externa, ou opiniões opressoras ou opiniões que possam criar novos bloqueios e aquelas opiniões escrotas que dizem que quem não automatiza está fora do mercado o resultado chega a ser surpreendente. Então, acordar e pensar assim: “Hoje vou dar uma chance em desenvolver meus testes” já servirá de motivação para continuar o trabalho. Se ocorrer de não gostar, tente dar mais umas três chances e se depois disso nada rolar, não tem problema, seu lugar no mercado ainda é bem visto e cada um tem seu valor ;).

2. Por onde começar

No meu caso, pedi ajuda para aprender selenium IDE e começar pelo IDE de certa forma abre mentes, pois a interface é amigável, vc não terá muitas linhas de comando e se colocar na cabeça que é um simples “passo a passo” de um cenário, o trabalho flui melhor. Usar e abusar do record and play também é muito válido, pois dessa forma as pessoas vão se familiarizando com cada comando gerado. Naturalmente depois você desapega dessa prática e passa a usar comando a comando.

Uma coisa que é importante colocarmos na nossa cabeça é que toda tela possui elementos e que elementos passam a ser o coração da automação, pois são esses mesmos elementos que eu vou clicar, escrever, selecionar, etc. Então vamos a pequenas dicas:

a. Comandos como Click, ClickandWait, Type, WaitforElementPresent, WaitforTextPresent, AssertText, Selectandwait são alguns comandos que acabam fazendo boa parte do que precisamos e todos eles precisam informar os elementos no campo Target do selenium.

b. Utilizar o firebug é essencial para identificar os elementos.

c. Não se assuste com o HTML, sempre tem o “inspecionar elemento” que vai direto para o elemento em questão.

d. Todo elemento pode ser identificado por um “id” ou buscamos por “css” ou “xpath”. O id ta escancarado no html rs, mas se não tiver id, clique com o botão direito na seleção no firebug e lá terá as opções de copiar o css ou xpath. É simples, copie e no campo target, coloque “id=xxxx”, “css=xxxx” ou “xpath=xxxx”. Nesse momento não se preocupem com o tamanho das strings geradas para css e xpath, depois vamos melhorar nossa busca de elementos utilizando outras técnicas, mas para o início basta. Para certificar que o elemento é aquele mesmo, basta clicar no botão find do selenium e o elemento ficará em amarelo e vai piscar.

e. No início, não se preocupem em utilizar e abusar dos comandos wait (até porque da um certo folego no passo a passo e não vai passando por cima de um passo ou outro) e lembre-se, você está no início, boas práticas agora não competem a você, vc precisa do negócio funcionando e vai funcionar.

f. A cada sucesso, execute e veja rodando e aumente a auto-estima, salve e parta para uma nova conquista.

Viram como até agora não precisamos de programar nada, é buscar elemento e passar pro próximo passo e depois rodar e ver a mágica acontecer.

3. O desapego

Agora vem a parte do desapego, pois uma hora que tu já começa a ver muitas coisas funcionando, vc acaba percebendo que o IDE já não é tão atrativo. É nessa que vamos desejar almejar voos mais altos e atuar no webdriver.

4. A escolha certa para o seu contexto.

Escolher uma linguagem de programação para atuar com os testes não é uma tarefa simples, no meu caso, optei por ruby + test::unit (biblioteca nativa do ruby para testes), ela é amigável, simples de usar e muitos devs conhecem, e no meu caso, todos da equipe de dev utilizam no dia a dia e com isso tirar dúvidas é muito mais simples.

5. E agora???

Após escolher a linguagem a se trabalhar, não pensem que iremos começar do zero tudo de novo, pois podemos exportar o que fizemos na linguagem que escolhemos e a partir daí ter uma nova curva de aprendizado, pois veremos os comandos que colocamos no IDE de forma “traduzida” para a linguagem. As dicas para ruby são bem simples:

**a. Estruturas básicas:
** a.1.
Ter na cabeça que temos classes e métodos. Quando exportamos, o IDE traz essa estrutura pra você.

b. No início, faça um “linguição” dentro de um método só, Lembre-se que cada linha do método significa um passo a mais no seu teste. Cada método inicia com “def” e finaliza com “end”. Para o método ser executado, lembre-se que deve iniciar “test_”, pois o test::unit vai interpretar e vai iniciar o passo a passo. Então, dentro do export, procure por esse método e coloque-o antes do último end (classe). O restante dos métodos, deixem do jeito em que estão (por hora é isso). Foque apenas no método que contenha o teste.

c. A essência do test::unit, assim como no IDE está na busca de elementos na tela e depois posso clicar, selecionar, escrever, etc. Outro detalhe bem legal no test::unit, assim como em outras linguagens, é que o trabalho começa a ficar bem repetitivo, ou seja, é tranquilo andar com as próprias pernas. Como a busca de elementos é o X da questão, os comandos se repetem, nesse caso, "@driver.find_element(:id,css ou xpath, “id, caminho do css ou xpath” ".
Vou colocar abaixo um exemplo de um método em ruby de um teste básico de login:

Início dos testes
Método de aprendizado. Testando Login

def test_login
@driver.get “http://enderecoweb.com.br
@driver.find_element(:id, “id do elemento Logar”).click
@driver.find_element(:css, “html.js body.welcome-controller div#top-bar.slogan div.container div.action-links div.dropdown a#user-name-link.bold” do elemento informe o login).send_keys "teste@teste.com.br"
@driver.find_element(:xpath, “/html/body/div[2]/div/div/div/a” do elemento senha).send_keys “password0001”
@driver.find_element(:id, “id do elemento entrar”).click
# O comando assert vai certificar que no campo X o nome teste deve aparecer. Qualquer coisa diferente disso, ele vai falhar o teste. Fazendo um paralelo, funciona como o waitforTextPresent. #
assert(@driver.find_element(:id, “id do elemento”).text == “teste”)
end

Fim do método de Login
Fim dos testes

6. Executando o script.

Para deixar claro, como escolhemos test::unit para criação e selenium como driver, temos que ter as seguintes gemas instaladas no ruby:

selenium-webdriver
test-unit

Bom, dado que o ruby esteja instalado em sua máquina, executar com o comando “ruby + nome_do_arquivo”, então ele irá abrir o navegador, rodará os testes e finalizará. O Log vai aparecer da seguinte forma:

1 tests, 1 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed

Bom galera, os mitos a cada dia vão caindo, “desenvolver testes” pode ser mais divertido do que qualquer outra coisa. É prazeroso ver um fluxo que se fazia manual ficar automático e rápido, e cada sucesso, salve, e crie outro método e outro e outro.
Como falei, no início, esqueça as boas práticas e foque no aprendizado, escute os desenvolvedores que irão te ajudar, não queira deixar o negócio todo bonito porque ta no livro do Martin Fowler logo de cara, quando o nível de maturidade for chegando a um patamar melhor, iremos ver que a cada dia que passa iremos melhorando nossos testes, melhorando a forma de escrita, aprendendo mais. Pergunte sempre ao google sobre um problema, que ele vai te responder e vc vai conseguir aplicar.

Hoje estou entrando em um contexto para desenvolver em BDD com cucumber + capybara. É um pouco diferente, mas é bem legal, porém o início eu acredito que pelo test::unit seja o melhor dos mundos, a visão vai se abrindo e depois que o bloqueio foi tirado, não importa por onde você vai “desenvolver”, você irá conseguir e na minha opinião, é bemmmm mais fácil. Em paralelo, estudando uma ferramenta muito boa para automação em ambiente mobile (utilizando o próprio device) e estou entrando em um seleto grupo que automatiza para mobile =).

Estou aberto para tirar dúvidas, mandar exemplos, etc.
Se hoje sou um QA mais completo, não sei, mas minha opinião de que há lugar para todo mundo não muda. Funcional ou técnico, extraia o melhor de ti e não dê ouvidos teorias da conspiração, seja o melhor e é isso ai.

Até o próximo.

E ae Thiago,
Muito bom post!

Uma dose de incentivo para os que estão começando, assim como eu.
Porém, tem uma parte que não consegui enxergar “O desapego”. Você se refere as limitações de determinada ferramenta em relação á testes mais complexos ?

Abraço!

@Leandro-Santos O Selenium IDE é muito bom mas tem suas limitações, embora você possa progredir bastante com os plugins:
http://docs.seleniumhq.org/projects/ide/plugins.jsp

Parabéns Biro, pela força de vontade de persistência!
Eu tenho muito orgulho de você!

Você é um exemplo de que é possível aprender qualquer coisa quando estamos dispostos.
Não significa que é fácil, significa que é possível!

As dificuldades nós mesmos quem as criamos quando não estamos interessados em aprender algo novo.
São inúmeras as iniciativas em ensinar automação (do básico ao avançado), mas por mais que elas existam nunca vamos conseguir progredir se não existir VONTADE.

Abraços,
Eduardo Souza

@Leandro-Santos

Leandro, o desapego eu acredito ser algo natural, eu tive uma evolução muito boa no IDE, mas tem uma hora que temos que ficar virando do avesso para conseguir algo que no webdriver eu faria de forma mais tranquila. Outro detalhe é que os devs não usam IDE e sabem de lógica =). A documentação é bem ampla e de fácil aprendizado. Qualquer coisa me manda email pra poder tirar alguma dúvida para eu esclarecer melhor.

@eduardo-Souza Valeu Du =) . Como você disse, basta vontade. Você mais que ninguém sabe o quanto eu lutei contra, e, baixar o orgulho e o ego e pedir ajuda e pedir para alguém ensinar é algo que não está em todo ser humano. Tamo junto! E valeu!

@thiagompereira said:

baixar o orgulho e o ego e pedir ajuda e pedir para alguém ensinar é algo que não está em todo ser humano

HEhehe eu que o diga…

Bom post… tem que sempre começar por algum lugar.

Eu comecei direto com selenium 1 + java pq o selenium IDE na época o suporte dele era horrível, mas hoje parece que a coisa melhorou um pouco. A tendência agora é para uma linguagem mais orgânica e o BDD toma conta disso…

[]s!

Falaaaa @thiagompereira, bacana o texto cara, ta ajudando a deixar claro os passos que todos nós que começamos com automação passamos.
As minhas dúvidas e os aprendizados com o desenvolvimento de testes ainda não chegaram nem perto de acabar, mas pra facilitar nesse passo de transição, eu e o Robson aqui na Lw, criamos um projeto exemplo, usando selenium_webdriver/rSpec, no Ruby. Da pra baixar e rodas os exemplos, “https://github.com/robsonagapito/rspec_selenium_webdriver”, depois é só exportar as funções do IDE pra dentro do padrão.
Valeu cara, a cada fase que avançamos precisamos sempre da ajuda de pessoas que compartilhem suas experiências.

@Diego-Alves Boa meu velho!!! Acredito que apenas a vontade pelo novo pode abrir portas, porém, quando a vontade vem com um ar de pressão nada dá certo! Ai o bolo desanda!!!

Parabéns Thiagompereira pela mentalidade, por ter tido iniciativa e sair da zona de conforto para explorar uma nova perspectiva.

Gostei de saber que você já está tendo contato com o Capaybara pois ele faz um uso muito superior do selenium-webdriver pois ele já possui waits implícitos que tornam o desenvolvimento muito mais focado no comportamento e menos carregado de codigo repetitivo.

Como próximos passos sugiro o estudo de:

  • Conceito de page objects
  • O que é BDD - (BDD não é teste nem automação) The RSpec book é o melhor pra ensinar isso
  • Melhorar os conhecimentos relativos a programação (refatoração etc)

Passei por um caminho muito semelhante. E após estudar técnicas que antes eu pensava serem de testes TDD < BDD < Specification by Example eu mudei totalmente minha visão e hoje me considero um Developer com foco em qualidade e acho desnecessário a separação de roles como Q.A. e Dev. Siga aprendendo, parabéns!

@Juraci-Vieira valeu pelo feedback. Eu acredito que tudo tem uma evolução, talvez essa evolução acaba cegando algumas pessoas e essas pessoas criam fantasmas para afugentar outras pessoas entende. No meu caso, nunca estive em zona de conforto, por exemplo, sou perito em banco de dados e conheço um pouco de SAP, analiso logs, defino estratégias e resolvi dar uma chance para a tão sonhada automação =). Para mim, é só mais um skill pro meu cv. Obrigado pelas dicas sobre capybara, ta sendo muito gostoso trabalhar e estudar sobre, aproveitar que tem você para tirar algumas dúvidas ;). Um abraço.

Vou ficar feliz em ajudar, inclusive eu desenvolvo e mantenho essa gem chamada swamp https://github.com/Juraci/swamp que escaneia uma página alvo e gera os page objects em Capybara de forma automática acelerando muito a criação dos mesmos.

@Juraci-Vieira Vou colocar o link da sua GEM no artigo de “canivete suiço de teste” : )

Muito bom maninho!!! muito feliz com o seu progresso!!! parabens pelo post, ficou show!!

@Éden-Pereira valeu meu irmão =) … Espero que tenha agregado.

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.