Sem tempo para automatizar testes? Quatro dicas para virar o jogo
Nem sempre dá tempo de automatizar testes, e a cobertura de testes automatizados pode ser bem menor do que a gente gostaria. Muitas vezes os testes automatizados acabam sendo postergados para uma sprint futura, mas como surgem outras urgências no meio do caminho, vão ficando para depois, e depois, e depois…
A grande questão é: como tornar a automação de testes um hábito dentro do time? Como viabilizar que a evolução da suíte de testes automatizados ocorra junto com o desenvolvimento do nosso produto sem deixar os testes para depois?
Neste artigo eu trago um mix de conceitos bastante conhecidos, insights de cursos que fiz (dentre eles o TSPI 💜) e uma pitada de opinião e experiência pessoal, listando quatro dicas que considero essenciais para virar o jogo.
São elas:
- Lembrar sempre da pirâmide de testes
- Conhecer e aplicar na prática os princípios FIRST
- Começar a testar (de verdade) o quanto antes
- A importância do apoio do time
Elas vão te ajudar a planejar melhor o que e como será automatizado, reduzir o tempo gasto na construção e manutenção dos testes, otimizar o uso do seu tempo durante a sprint e engajar o seu time para que todos participem da automação. Dessa forma, ficará mais fácil encaixar a automação de testes no dia a dia.
Nas seções a seguir, é feito o detalhamento de cada uma dessas dicas.
Dica 1: Lembrar sempre da pirâmide de testes
O conceito de pirâmide de testes surgiu no livro Succeeding with agile: software development using Scrum, de Mike Cohn. Ele nos ajuda a distribuir os testes em diversas camadas, de forma a evitar que a construção e execução deles se torne excessivamente demorada.
A pirâmide de testes tem em sua base os testes unitários, o que significa que este nível de teste deve possuir a maior quantidade de testes, visto que são testes muito rápidos de montar e rodar.
Já no meio da pirâmide ficam os testes de serviços, que possuem complexidade intermediária entre os testes unitários e os testes de interface.
E no topo, temos os testes de interface, ou seja, neste nível devemos ter a menor quantidade de testes. Quem já automatizou testes nessa camada sabe que é desafiador: encontrar os elementos na tela e lidar com problemas de sincronismo (ah os timeouts…) faz com que a construção desses testes tenda a demorar bem mais do que no caso de testes de unidade e serviços.
Além disso, a execução de testes nesta camada demora mais também pelo fato de ter que abrir o navegador, aguardar o carregamento da página e assim por diante (pensando em testes web).
Aqui o conselho que dou é: reflita sobre qual é a camada mais apropriada para você automatizar o seu teste, tendo em mente o objetivo dele. Você pode ganhar muito tempo fazendo isso!
Por exemplo: se o objetivo do seu teste é verificar se todas as opções de produto do seu site são retornadas, vai demorar muito para você montar esse teste na camada de interface (imagina ter que mapear na interface cada um dos elementos da lista, vai dar muito trabalho, além de ter que ficar esperando o navegador abrir cada vez que for rodar o teste).
Em vez disso, você poderia validar se a API do seu site que envia as informações para a interface está retornando tudo direitinho. Validar elementos do JSON retornado é muito mais rápido do que fazer essas validações na interface web, vai por mim :)
Outro ponto importante é lembrar que é impossível automatizar todos os testes. Dessa forma a seleção do que será automatizado deve ter como foco mitigar os riscos de nível mais alto. Para saber mais sobre testes baseados em riscos, super recomendo a leitura deste artigo do Gabriel Santos.
Dica 2: Conhecer e aplicar na prática os princípios FIRST
Os testes baseados em riscos nos ajudam a decidir o que será automatizado e a pirâmide de testes nos ajuda a decidir como será automatizado (em qual nível). Isso já nos faz ganhar tempo, dado que estaremos utilizando nosso esforço de automação de forma mais eficiente.
Mas como reduzir o tempo gasto na construção e principalmente na manutenção dos testes? É nesse ponto que os princípios FIRST podem nos ajudar!
Os princípios FIRST para escrita de testes automatizados têm origem no livro Clean Code, de Robert C. Martin, um dos profissionais por trás do Manifesto Ágil. Segundo esses princípios, os testes devem ser:
Fast: execução dos testes deve ser rápida. Isso nos possibilita ter um feedback o mais cedo possível sobre possíveis impactos das modificações feitas no software. Além disso, facilita para podermos rodar os testes várias vezes se necessário e torna mais ágil o debug dos testes, reduzindo o tempo necessário para criar e manter os scripts. Para atingir este objetivo, evite construir testes complexos demais ou que processem uma quantidade de dados desnecessariamente grande.
Independent: os testes devem ser independentes entre si. Isso evita que a falha em um teste cause falha em outros testes, o que dificulta e torna bem mais demorada a investigação de problemas. O “você do futuro” vai agradecer muito ao “você do presente” por isso :)
Repeatable: ao rodar um teste com os mesmos dados de entrada diversas vezes, o resultado retornado deve ser sempre o mesmo. Se cada vez que um teste for executado ele der um resultado diferente (às vezes passa, às vezes falha), perde-se a confiança no teste. Além disso, perde-se tempo investigando um teste que falhou sem um motivo justo para isso. Para satisfazer o critério Repeatable, é necessário ter um ambiente controlado e boa gestão de dados de teste. Se este não for seu caso, você perceberá que seus testes começarão a ficar cada vez mais complexos e menos confiáveis, até chegar ao ponto de ferir o Fast e o Independent.
Self-Validating: os testes devem reportar claramente se passaram ou falharam, para que esta avaliação não se torne subjetiva, de forma a agilizar a análise dos relatórios dos testes para saber se algo que funcionava quebrou.
Timely: os testes devem ser escritos o mais cedo possível (de preferência antes mesmo de o código ter sido escrito, como no caso do TDD). Começar a escrever os testes automatizados assim que as funcionalidades são desenvolvidas evita que ocorra um acúmulo de testes automatizados pendentes, o que pode acabar até inviabilizando a sua implementação.
Dica 3: Começar a testar (de verdade) o quanto antes
Em muitos times, o dia a dia do QA durante a sprint é um misto de tédio e desespero.
Tédio no início da sprint, porque não tem nada para testar, já que os devs ainda não finalizaram nenhuma implementação. Nesse meio tempo, muitos QAs ficam escrevendo casos de teste que só eles mesmos vão ler, e que na sprint seguinte não terão nenhuma serventia.
Já no final da sprint, o clima é de puro desespero! Depois de alguns dias sem nada pra testar, de repente vem uma avalanche de features para validar, lá pelo 7º, 8º dia da sprint. E o que acontece? Na correria de entregar as features testadas, lá se vai a chance de automatizar os testes, e se acaba fazendo os testes apenas manualmente.
Como mudar isso?
Buscando o combate! Não espere até o “desenvolvimento te entregar uma versão”. Não precisa estar tudo tudo pronto para você começar a testar. Tenha o ambiente de desenvolvimento na sua máquina e mantenha-o atualizado com os commits dos devs. E já vai olhando o que está sendo feito e vai testando o que der, nem que seja um único endpoint da API que já está pronto.
Use mocks para simular o que ainda não estiver pronto e, enquanto isso, já vai escrevendo testes automatizados que verifiquem que está funcionando, lembrando sempre da pirâmide de testes e dos princípios FIRST.
Assim quando tudo tudo estiver pronto, você vai poder rodar esses testes para te ajudar a validar mais rapidamente se continua tudo ok e já vai ter seus testes automatizados prontos ao final da sprint! Além disso, vai te possibilitar encontrar problemas bem mais cedo.
Outro ponto importante é evitar documentar excessivamente os testes que você planejou. Ao invés de escrever páginas e páginas de casos de teste, avalie substituir isso tudo por mapas mentais. Assim você ganha um precioso tempo para poder criar mais testes automatizados, que são uma ótima forma de documentação :)
Dica 4: A importância do apoio do time
Ter um projeto de automação de testes bem sucedido é uma batalha que não temos como vencer sozinhos. Se apenas uma pessoa cuidar da criação e manutenção dos testes automatizados, rapidamente ela ficará sobrecarregada e não dará conta da demanda. Além disso, se sentirá frustrada e o projeto de automação tende a ir por água abaixo, podendo ser abandonado.
Aplicar as três dicas dadas até aqui é de suma importância, mas não trará o resultado desejado se o seu time não se unir a você nesta luta.
Dessa forma, é essencial engajar o seu time!
1. Conscientize-os de que a automação de testes (bem como a qualidade do produto) é responsabilidade de todo o time, não só do QA. Todos não só podem, como devem ajudar.
2. Faça com que eles se sintam parte do processo desde o início. Envolva-os no debate sobre qual será a estratégia para automação de testes, bem como que ferramentas serão usadas.
3. Selecione, junto com o seu time, uma linguagem de programação para fazer a automação. Não existe linguagem melhor ou pior, qualquer uma pode ser usada. O essencial é que todo o time tenha ao menos um conhecimento mínimo dessa linguagem, para que todos possam ajudar na automação.
Se você chegou até aqui, parabéns :)
Tenha a certeza de que não será da noite para o dia que você conseguirá colocar isso tudo em prática. Eu mesma estou colocando essas ideias em prática aos poucos, e estou muito animada com os resultados!
Isso tudo que compartilhei com vocês são ideias que estão me guiando para evoluir cada vez mais, em parceria com o meu time.
Espero que esse text(ão) ajude a você também :)
Até a próxima!
Obs.: agradecimento super especial ao Júlio de Lima e seu treinamento TSPI, por causarem uma verdadeira revolução na minha forma de pensar e praticar a qualidade de software 💜
