Automatizando com o Gauge... Que Gauge!? - Parte 1

 Ler em Português      Read in English
Hoje vou falar de uma ferramenta de automação que quase ninguém conhece, o Gauge.

Gauge? Que Gauge?
"Gauge é uma ferramenta de automação de testes multiplataforma. As especificações são escritas em Markdow de formato livre para que casos de teste possam ser escritos na linguagem de negócios, ao invés do formato mais comum, porém restritivo, "dado-quando-então". Suporte a linguagens e a IDEs são implementados como plugins, permitindo que analistas de teste usem as mesmas IDEs que o restante do time, com capacidades poderosas como autocompletar e refatoração. Essa ferramenta, desenvolvida com código aberto pela ThoughtWorks, também traz nativamente a execução paralela para todas as plataformas suportadas." (Fonte: ThoughtWorks - Technology Radar)
 
Resumindo, algumas qualidades do Gauge:
- Não te deixa preso no "given-when-then"; 
Obrigado
- Fácil de instalar;
- Permite que você escreva seus scripts em várias linguagens (Java, Ruby, C#, etc.);
- Open Source =D;
- Suporte a algumas IDEs (IntelliJ, Visual Studio e Eclipse);
- A sintaxe é bem simples de entender.

Vou fazer um mini-tutorial para mostrar como são executados os testes no Gauge e quais as principais features dele, mas como vou ter muito o que falar, vou dividir este post em algumas partes.
Hoje vou falar da instalação, execução e de como funciona a estrutura básica de um projeto no Gauge.

1 - Instale o Gauge
Verifique como instalar o Gauge em seu sistema operacional aqui.

Exemplo, se você usar o linux, você precisa:

  • Baixar o Gauge 32 bit ou 64 bit; 
  • Abrir o arquivo zipado pelo terminal, no meu caso, salvei o arquivo na home, então foi só executar esse comando:
$ unzip gauge-0.5.0-linux.x86_64.zip 
  • Agora, execute este comando para instalar:
$ ./install.sh

2. Instale o plugin da linguagem que você vai usar
Exemplo:

  • Se você usa Java: $ gauge --install java
  • Se você usa C#: $ gauge --install csharp
  • Se você usa Ruby: $ gauge --install ruby

3. Instale o plugin para gerar um relatório em HTML
O gauge tem um relatório em HTML. Na minha opinião, não é muito prático, mas pode ser útil quando você executa muitos testes de uma vez e não consegue acompanhar todos os resultados da execução no terminal.
 
Para instalar o plugin: $ gauge --install html-report

4. Verifique sua instalação
Execute $ gauge -v

Se tudo der certo, a resposta será parecida com essa:
Gauge version: 0.5.0

Plugins
-------
html-report (2.1.0)
ruby (0.2.0)


5. Inicie um projeto
Execute o comando de acordo com sua linguagem escolhida, no meu caso: 
$ gauge --init ruby

Quando você executa esse comando, o Gauge vai criar um projeto modelo para você utilizar como exemplo. Veja a estrutura do projeto criado:

6. Execute 
$ gauge specs pra ver se o projeto exemplo está rodando normalmente:
 
Specifications: 1 executed 1 passed 0 failed 0 skipped
Scenarios:     2 executed 2 passed 0 failed 0 skipped

Total time taken: 80ms
 
Sucesso total!
 

7. Entendendo a estrutura do Gauge

Você vai trabalhar basicamente com dois arquivos a maior parte do tempo, as especificações e os steps. 
 
Especificação
Exemplo de especificação
Nome da especificação - O nome que você vai dar para o grupo de cenários contidos nesse arquivo. Para especificar o nome é necessário "sublinhar" o título com "======" ou colocar uma # antes do nome. 
Exemplo: # Specification Heading.
Nome do cenário - A especificação deve conter no mínimo um cenário. Para especificar o nome do cenário é necessário sublinhar o título com "-------" ou colocar duas ## antes do nome. 
Exemplo: ## Vowel counts in single words.
Steps - Passos executáveis que podem ou não estar dentro do cenário. Para especificar o nome dos steps é necessário colocar um * antes do nome. Exemplo: * Almost all words have vowels.




Steps


Aqui ficarão os scripts dos testes. A implementação depende de cada linguagem, no caso do Ruby (exemplo acima), será sempre:
step 'Say <greeting> to <product name>' do |greeting, name|
 # Code for the step
end
Essa foi a primeira parte do post sobre Gauge. Na próxima, quero mostrar alguns recursos legais que utilizo no meu dia-a-dia.

Ficou com dúvidas? Mande sua pergunta aqui nos comentários!

The Developers Conference 2016 - Como foi a Trilha de Testes

 Ler em Português      Read in English

Olá! 
No dia 08/07/2016 aconteceu em São Paulo a Trilha de Testes do TDC 2016! Como os eventos da área de testes são muito raros, resolvi conferir as palestras e ver o que tinha de novo.




Achei interessante que havia muitos palestrantes que estão há pouco tempo na área de QA (até dois anos) e alguns desenvolvedores. Eu dou meus parabéns a todos, principalmente porque eu tenho horror a falar em público, e fazer uma palestra pra quase 200 pessoas (acho que era mais ou menos isso) não é fácil.

Alguns assuntos e angústias já eram esperados em eventos de testes como esse. Alguns foram abordados de maneira mais engraçada, mas a maioria ficou um pouco repetitiva. Eu não sei se é porque estou há muito tempo na área e já cansei de ouvir esse mimimi, ou porque certos assuntos realmente não morrem, como por exemplo:

A falta de ambiente de testes...
Eu vi você testar seu código em produção
Eu também gosto de viver perigosamente

 Falta de documentação...
Documentação??
Ninguém tem tempo pra isso

relacionamento Dev x QA difícil...
patolino.gif
- Erro crítico
- Não pode ser reproduzido

e Agile. (A bala de prata do momento. Às vezes essa palavra me cansa...)
Diga Agile
mais uma vez

Mas eu senti muita falta de novas ferramentas, e não acho que foi porque os palestrantes não falaram. É porque realmente não vejo nada de novo há muito tempo!

As únicas ferramentas que me chamaram a atenção foram o BrowserSync, que permite que você navegue em todos os browsers ao mesmo tempo, inclusive dispositivos móveis. Mas acredito que não seja nenhuma novidade, principalmente pra quem trabalha com front-end.


... e o Exploratory Testing da Microsoft, que funciona como uma extensão do Chrome e te ajuda a capturar os bugs enquanto navega no sistema, e a filmar o passo-a-passo dos testes exploratórios, assim nunca mais teríamos problema pra reproduzir um bug de teste exploratório de novo. Tudo muito lindo, muito bonito, mas como tudo que é bom nessa vida da Microsoft, não é de graça... Não sei se posso considerar como uma boa opção.

Em resumo, eu achei um evento muito bom pra conhecer pessoas, ver como as outras empresas estão trabalhando e entender que, após 6 anos na área, as angústias continuam as mesmas. 
Aí você irá me dizer que o QA é maltratado, que ninguém dá importância pra área e que nosso trabalho é menosprezado.
Mas, pense: será que as empresas não dão valor para a área de QA ou não estamos sabendo vender nosso peixe? Pense nisso, pequeno gafanhoto!

Que tester sou eu?

 Ler em Português      Read in English

Se você trabalha com testes há algum tempo, já percebeu que nós somos chamados de todo tipo de coisa. E não, não estou falando dos xingamentos dos desenvolvedores ou gerentes de projeto, mas sim de todos os nomes de cargo que inventaram pra essa área. Apenas alguns exemplos:
- Analista de Testes
- Engenheiro de QA (Quality Assurance)
- Automatizador
- Analista de QA
- Tester

Como eu vejo esses caras: 
Analista de Testes e Analista de QA
Uma pessoa que está mais focada em elaborar cenários. Precisa entender muito bem o negócio pra saber quando e onde pode dar problema. Utiliza muito a documentação do sistema e, quando ela não existe, o trabalho vira uma caça ao tesouro. Vai achar mais erros nos requisitos do que no sistema. Possivelmente um(a) analista de requisitos/negócios/sistemas frustrado.
REESCREVA todos os requisitos!
Engenheiro de QA e Automatizador
Uma pessoa mais técnica, não perde muito tempo com teste manual, o negócio dela é programar e rodar scripts. A vida dela é um teste de regressão. Os desenvolvedores não a consideram uma desenvolvedora e os analista de testes acham que ela traiu o movimento. Possivelmente um(a) programador(a) frustrado(a).
Eu sei TDD
Tester
Há um tempo atrás (não muito), chamávamos de tester (ou executor de testes) a pessoa que apenas executa os testes, ou seja, a pessoa era paga pra ler roteiro de testes e apertar botão. Ainda bem que hoje em dia raramente vejo uma vaga com essa função, mas vejo 2 possibilidades pra esse nome ainda ser tão comum:
1. É uma pessoa que faz de tudo, mas provavelmente ganha o salário de 1/2.
2. O RH não faz a mínima idéia de como chamar a pessoa que faz testes, falaram que era tester e a vaga foi colocada assim, o mais genérica possível.
Eu não tenho idéia do que estou fazendo
O que eu concluo com isso tudo:
Que se danem as nomenclaturas! Sério, não se preocupe com isso. A única coisa que você "tester" deve saber é:
- Elaborar planos, roteiros, estratégia, casos de teste, relatório de execução, aceite e outros 15 documentos que ninguém se importa e vão fazer você perder um tempão elaborando;
- Ter CTFL, CTAL, CBTS, QAI, CTEL e outras siglas que vão deixar sua assinatura enorme e seu currículo lindo, mas se alguém te perguntar na entrevista o que elas significam, você está ferrado!
- Ter 15 anos de experiência, curso superior, pós-graduação, mestrado, doutorado, inglês e espanhol fluentes mas não ter mais de 30 anos;
- Programar em Ruby, PHP, Java, Phyton, Javascript, C#, C++, Objective-C, Visual Basic, Perl, Go, Pascal, Brainfuck, e se souber Assembly será um diferencial;
- Ter experiência com TestNG, Cucumber, Selenium, RSpec, Gauge, Capybara, Appium, Loadrunner, etc. Mesmo que a empresa use só uma ferramenta, aprenda todas e use tudo ao mesmo tempo!
- Saber usar MySQL, Oracle, SQL Server, MongoDB, DB2, e o PostgreSQL. Todos! E, por favor, decore como fazer pelo menos um SELECT (nada de simples, com WHERE, ORDER BY e INNER JOIN, por favor!), INSERT, DELETE e um UPDATE em cada um deles. É muito importante que você não utilize o google pra lembrar como executar nenhum deles;
- Já ter usado Jira, Mantis, Bugzilla, Testlink, ALM e todas aquelas ferramentas que você não aguenta mais olhar pra tela;
- E, principalmente, estar preparado pra ser o culpado por todo o projeto atrasado. Se isso acontecer... 

PARABÉNS, você está fazendo seu trabalho! =)
Bugs
Bugs em todo o lugar