Concrete Logo
Hamburger button

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

  • Blog
  • 3 de Agosto de 2018

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 aqui 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 (se 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, sucesso e fracasso, 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, a 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:

  1. Deixe o campo em branco ou com alguma indicação para completar depois, ou
  2. 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.

Divididas 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

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:

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 vão ficar assim:

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

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 tem algo a 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!