Agile

9 ago, 2018

Como faço (ou tento fazer) automação de testes na Sprint

Publicidade

Frequentando Meetups e conversando com profissionais de QA de outras empresas, sempre surge o assunto sobre a dificuldade de implementar automação de testes dentro da Sprint. Por isso, tive a ideia de contar como foi (e está sendo) minha experiência com automação na Concrete. Já adianto que essa é a receita do meu bolo e deu certo por dois projetos pelos quais passei, mas avalie se cabe no seu caso, ok?

Para que o método funcione, porém, são necessários alguns pré-requisitos que baseei em conversas e leituras sobre o assunto e na minha experiência na Concrete. São eles:

Empresa

Nos casos com mais sucesso citados nas conversas, a empresa (ou pelo menos alguns cargos de chefia) compra a briga para rodar agilidade, independente do framework (Scrum, Kanban ou outro). Nestes casos, se o time erra é estimulado a tentar de novo, e não punido pelos erros.

Essa briga também vai para a empresa-cliente que quer “cascatear” o processo. Se sua empresa acata as decisões da empresa-cliente de como o time deve trabalhar só para não perder a venda, a probabilidade de fracasso é alta.

Time

Aqui, vamos considerar o time como um grupo de pessoas trabalhando com o objetivo de agregar valor ao produto. Todas juntas com o mesmo objetivo.

O time deve compartilhar informações, ideias, dores, sucessos e fracassos, trabalhando como uma entidade única.
Um time é diferente de um grupo de trabalho de acordo com a maneira como as pessoas se comportam. Em um grupo de trabalho, cada um faz o seu, sem pensar no que pode afetar o outro. A Sprint falhou? “Eu entreguei meu trabalho no prazo, não tenho nada com isso”. Ou pior: “Quem não fez e prejudicou o time foi essa pessoa aí”, apontando o dedo.

Vou ainda colocar mais uma classificação; o “timinho”. O timinho sabe trabalhar em união, mas só faz o que é mandado. Pode até pensar em melhorias, mas se o objetivo está sendo atendido, por que mexer?

Se você está em um grupo de trabalho, dificilmente vai conseguir automatizar durante a Sprint. Nos outros casos, a probabilidade é grande. E se está num timinho, por que não tentar torná-lo um time? Exponha suas ideias de integração nas retros ou chame o time para conversar depois de uma daily, já que estarão juntos.

Imaginação

Para automatizar uma funcionalidade que não existe, também é preciso um pouco de imaginação. Se você já tiver o desenho das telas, fica mais fácil; mas se não tiver, imagine o fluxo. Seu código, à princípio, vai automatizar funcionalidades como o preenchimento de um campo ou o clique de um botão, independente da sua posição na tela, cor ou forma.

“Mas eu não sei os IDs!”, você diz. Duas soluções que eu uso:

Deixe o campo em branco ou com alguma indicação para completar depois, ou crie uma variável que permita a construção chave-valor (hash, hashmap ou dict, por exemplo). Preencha o campo com o nome_da_variavel[none_da_chave]. Depois é só completar o segundo membro da igualdade com os valores que você for descobrindo.

Usando esse método, já consegui terminar meu código da funcionalidade junto com o Dev! Aí foi só mapear os IDs e fazer pequenos ajustes que a funcionalidade já estava automatizada.

Meu fluxo

Tudo começa na reunião de planejamento (planning), na qual decidimos o backlog da sprint. Vamos supor que o objetivo da sprint é a realização do login (sempre o login como exemplo).

Escreva todos os cenários possíveis para a realização de um login. Antes de sair automatizando tudo, defina quais serão unitários/instrumentados, quais serão de serviços/APIs, e quais serão do front.

Divida as responsabilidades e automatize primeiro todos os “caminhos felizes”, aqueles em que tudo vai ser feito e preenchido com perfeição. De nada adianta uma funcionalidade que não realiza sua função se o usuário fizer tudo certo.

Voltando, escreva todos os cenários possíveis de login com sucesso, por exemplo:

Funcionalidade: Login com sucesso

Contexto:
  Dado que estou na tela de login

Cenário: login com sucesso utilizando username
  Quando realizo o login utilizando "username"
  Então devo ser direcionado à página principal

Cenário: login com sucesso utilizando email
  Quando realizo o login utilizando "email"
  Então devo ser direcionado à página principal

Cenário: login com sucesso utilizando CPF
  Quando realizo o login utilizando "CPF"
  Então devo ser direcionado à página principal

Escreva todos os que seu sistema vai suportar.

Implementado os cenários

Aqui vem a imaginação. Os cenários vão ser implementados somente com desenho da tela de login. Meu arquivo de steps, sem a implementação, fica assim:

Meu arquivo de steps, sem a implementação, fica assim:

Dado("que estou na tela de login") do
  pending # Write code here that turns the phrase above into concrete actions
end

Quando("realizo o login utilizando {string}") do |string|
  pending # Write code here that turns the phrase above into concrete actions
end

Então("devo ser direcionado à página principal") do
  pending # Write code here that turns the phrase above into concrete actions
end

Perceba que mesmo que meu arquivo de features tenha ficado grande, só tenho três steps para implementar. Na hora de escrever qualquer coisa em seu código, é muito importante pensar na reutilização. Depois de implementar “com minha imaginação”, os steps ficarão assim:

Dado("que estou na tela de login") do
  @pagina_login = LoginPage.new
  @pagina_login.load
end

Quando("realizo o login utilizando {string}") do |usuario|
  @pagina_login.campo_usuario.set USUARIO[usuario]
  @pagina_login.campo_senha.set SENHA[usuario]
  @pagina_login.btn_login.click
end

Então("devo ser direcionado à página principal") do
  pagina_atual_e?(NOMES['pagina_principal'])
end

E os arquivos de page objects, variáveis e métodos, utilizando o SitePrism e Capybara:

login.po.rb
class LoginPage < SitePrism::Page
  set_url ""  
  element :campo_usuario, ""
  element :campo_senha, ""
  element :btn_login, ""
end
metodos.rb
def pagina_atual_e?(pagina)
  page.has_title? pagina
end
variavies.rb
NOMES = {
  'pagina_principal' => ''  
}

USUARIOS = {
  'username' => '',
  'email' => '',
  'CPF' => ''
}

SENHAS = {
  'username' => '',
  'email' => '',
  'CPF' => ''
}

Agora só esperar a tela de login ficar pronta e completar o código que a funcionalidade já está automatizada! Só que não.

Mesmo que você substitua tudo direitinho, a probabilidade de que dê algum erro na primeira (segunda, terceira…) rodada é enorme. O exemplo acima é só para servir como base. É legal consertar os erros conforme o log de execução for apontando.

Mesmo com os erros iniciais, com certeza é mais fácil e rápido fazer ajustes do que esperar a funcionalidade ficar totalmente pronta para escrever o código. Os erros vão diminuir ao passar do tempo.

Além disso, não é só porque você terminou uma feature que vai ficar sentado esperando. Em um time ágil, sempre há algo para fazer. Sente com a pessoa responsável pelo DevOps e veja como anda a pipeline do CI/CD, procure saber como anda o desenvolvimento da aplicação com quem desenvolve, converse sobre o backlog e a usabilidade.

Interaja com o time, dê sugestões para melhorias, aponte problemas (se possível já com soluções). Você é responsável pela qualidade do produto, e não só por automatizar testes.

Não esqueça do teste manual exploratório

Sempre separe um tempo para usar o seu produto, só assim você vai ter o completo conhecimento de como ele está funcionando. Não se prenda a automatizar somente os requisitos descritos nas histórias, pois muitas questões e até novas automações vão surgir com o uso da aplicação. Testes automatizados e manuais são complementares, não excludentes.

Até me arriscaria a dizer que, atualmente, com a grande exigência de automação, profissionais de QAs também devem “retroceder” um pouco e fazer testes manuais. Espero que possa pegar a ideia geral deste texto e aplicar no contexto da sua empresa, e não se esqueça de comentar aqui como está sendo a experiência! Tem alguma pergunta ou gostaria de compartilhar sua experiência? Deixe um comentário abaixo!

E se você quiser saber mais, aqui tem algumas dicas:

  • Podcasts da Samanta Cicília e do Frederico Moreira (recomendo muito!)
  • Livro Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo
  • Livro Agile Testing: A Practical Guide for Testers and Agile Teams
  • Livro More Agile Testing: Learning Journeys for the Whole Team

Até a próxima!

***

Este artigo foi publicado originalmente em: https://www.concrete.com.br/2018/08/03/como-eu-faco-ou-tento-fazer-automacao-de-testes-na-sprint/