Capítulo 8: Quando Automatizar?

De Dftestes

Autor: Fabrício Ferrari de Campos
Revisor: Marcelo Andrade

Tabela de conteúdo

1 Introdução
- 1.1 Automação no Teste de Software
2 Quando automatizar?
3 Quais são as razões para automação dos testes?
4 Quais tipos de Testes devem ser automatizados?
5 Alinhamento das expectativas
6 Automação no contexto ágil
7 Conclusão
8 Referências Bibliográficas

Introdução

A automação vem desempenhando um importante papel no progresso da sociedade, e isso tem ocorrido tanto para o bem quanto para o mal. Por exemplo: graças à automação foi possível a produção em série de carros, mas a mesma fez com que houvesse demissões em massa de funcionários em épocas de sazonalidade baixa no mercado automobilístico, já que o volume de produção é maior do que o de venda.

No entanto, neste capítulo não iremos abordar a automação no contexto automobilístico e sim no contexto de Teste de Software, uma das principais áreas da Engenharia de Software e onde a automação costuma ser um grande desafio, uma vez que pode contribuir para o progresso do projeto, como também, se usada de forma inadequada, ter o efeito reverso e causar vários problemas.

Automação no Teste de Software

A automação vem aos longos dos anos ganhando um papel importante na área de Teste de Software.

E isso se deve a uma série de fatores, dentre os quais podemos destacar:

Diminuição do uso de mão de obra;

Diminuição dos custos;

Aumento na velocidade do processo de Teste de Software;

Maior sustentabilidade da garantia da qualidade, perante o “triângulo da gerência de projeto” (escopo, tempo e dinheiro).

Podemos utilizar a automação em qualquer fase do Teste de Software, como especificação de casos de teste, geração de métricas de testes, execução de testes, montagem do ambiente, etc.

Porém, é importante salientar que a automação costuma ser um passo a ser dado, apenas após já termos um processo de Teste de Software bem estruturado e uma equipe preparada, pois ela muitas vezes exige um alto conhecimento técnico, principalmente para alguns tipos de testes específicos (que serão abordados mais a frente) e é um esforço que precisa ser apoiado por um processo maduro.

Em frente aos fatores citados anteriormente, tentaremos nas próximas páginas esclarecer melhor a automação no Teste de Software, pois tais fatores costumam ser mal interpretados, causando muitos problemas e o surgimento de falsas expectativas e impressões.

Quando automatizar?

Atualmente existem boas ferramentas (tanto livres quanto proprietárias) que podem nos auxiliar em diversas atividades do processo de Teste de Software, desde a revisão de documentos, até a execução de testes de desempenho.

Muitas vezes, sente-se a necessidade de ferramentas para automação de testes, quando acabamos despendendo muito tempo, por exemplo: criando ou formatando casos de teste, gerando métricas de testes, etc.

Ao pensar na automação dos testes, não podemos esquecer da automação dos testes unitários e integrados, que geralmente, são feitos pelos desenvolvedores e que já costumam ser executados de forma automatizada.

O problema é que a prática de criação de testes unitários e integrados não é muito comum, no âmbito do desenvolvimento de software, mesmo tendo resultados bem expressivos quando implantada.

Neste caso, a automação deve iniciar logo que a primeira linha de código for escrita, ou até mesmo (de preferência), antes mesmo da elaboração da primeira linha de código, como propõe a técnica TDD (Test-driven development).

Ao pensar em automatizar os testes de sistema, precisamos estudar a viabilidade da automação, quer dizer, se com a automação conseguiremos obter:

Ganho de tempo;
Redução de custos;
Manter a qualidade.

A maior dificuldade está em conseguir medir a viabilidade da automação, pois é necessário analisar vários fatores, dentre eles:

A maturidade do time e do processo de Teste de Software;

O grau de reutilização dos testes automatizados;

O nível de capacitação das pessoas para operar o software, ou manter o software, nos cenários em que a ferramenta ou script foi desenvolvido pelo próprio time;

O conhecimento acerca do comportamento que se espera do sistema a ser testado;

O tempo disponível para automatização dos testes. Lembre-se que a automação é um investimento a médio e longo prazo;

O grau de frequência de mudanças das funcionalidades a serem verificadas, pois em alguns casos, pode não ser viável automatizar um teste de uma funcionalidade que irá mudar amanhã (embora isso não seja uma verdade absoluta, pois há exceções);

A testabilidade do sistema. Em alguns cenários é necessário realizar alterações no código para que seja possível a automação dos testes. Isto ocorre de forma mais frequente, em sistemas legados, nos quais não houve uma preocupação com a testabilidade do sistema e o desenvolvimento não utilizava técnicas que favorecem uma boa testabilidade, como por exemplo, o TDD;

A garantia de que com a automação do teste, poderemos alcançar a mesma qualidade da execução manual do teste;

Aumentar a cobertura dos testes, uma vez que com os testes automatizados, a equipe pode ganhar tempo para elaborar testes mais complexos e assim, tornar o processo de Teste de Software mais eficiente, em relação ao tempo e qualidade, já que será possível prover um feedback mais rápido aos desenvolvedores e garantir uma maior qualidade do sistema sob teste.

Quais são as razões para automação dos testes?

No livro Agile Testing, da Lisa Crispin e da Janet Gregory, são citadas as seguintes razões:

Teste manual é demorado;

Reduzir a probabilidade de erros das tarefas de teste;

Liberar tempo para fazer o trabalho da melhor forma;

Prover uma rede de segurança ( se eu fizer uma mudança no código eu terei os testes, que irão me avisar se eu quebrei algo);

Prover feedback cedo e frequente;

Os testes que direcionarão a codificação (utilizando técnicas como o TDD e BDD) podem fazer mais do que isso (ex.: se tornam testes de regressão);

Os testes provem documentação, aliás, são uma excelente documentação;

ROI, com o passar do tempo o esforço gasto na automação dos testes se paga.

Um dos grandes benefícios da automação é prover feedback cedo e frequente, e isso é possível, principalmente com a automatização dos testes unitários e integrados (que iremos ver com mais detalhes no próximo tópico), geralmente realizados pelos desenvolvedores. Ou seja, quando falamos de automação de testes, não estamos falando apenas da área de Teste de Software, mas sim em práticas que devem ser comum no desenvolvimento de software como um todo.

Essa é uma prática que pode ser utilizada em qualquer metodologia e não demanda de um grande investimento financeiro, pois boa parte das ferramentas que auxiliam esses níveis de testes, são softwares livres, como por exemplo: o JUnit para criação de testes unitários em Java.

Podemos perceber pelas razões citadas que a automação dos testes pode ser uma boa escolha, frente ao teste manual, porém como vimos anteriormente, precisamos analisar vários fatores, antes de partir para a automação.

Quais tipos de Testes devem ser automatizados?

Quando tomamos a decisão de iniciar a automação na execução dos testes, é bom avaliar quais testes serão automatizados primeiro. De acordo com o Elias Nogueira, já há certos tipos de testes que sofrem uma tendência a automação, sendo eles:

Testes de regressão;
Smoke Tests;
Tarefas repetitivas;
Funcionalidades críticas do software;
Testes com cálculos matemáticos.

Há outros testes que devido à grande dificuldade de sua execução de forma manual, a automação torna-se praticamente essencial:

Teste de performance;
Testes unitários e integração.

Patrick Wilson-Welsh fez uma boa metáfora usando a pirâmide de Mike Cohn, que nos ajuda a explicar, quais tipos de testes devem ser automatizados, tendo em vista o custo de se manter os testes. No topo, temos os testes de palha são aqueles que testam o sistema de forma caixa-preta, por meio da interface. No meio temos os testes de madeira que não são por meio da interface, mas tipicamente testam muito mais do sistema, do que os nossos testes de unidade. E na última camada temos os testes dos programadores: testes unitários que verificam partes do nosso sistema, de forma isolada.

Figura 8.01 - Pirâmide da Automação (patrickwilsonwelsh.com, 11 de abr. 2010)

O interessante dessa pirâmide, é que ela costuma ser invertida em equipes tradicionais (não ágeis), pois geralmente a automação surgi como uma necessidade da equipe de Teste de Software, por conta dos testes de regressão.

Mas como podemos perceber com a metáfora do Patrick, precisamos apoiar a automação dos testes em uma base sólida, e essa base sólida, só pode ser construída com criação de testes unitários. E isso explica porque é importante pensar em testes sempre, testar não é uma atividade que deve ser realizada só no final, ou por apenas uma área.

Alinhamento das expectativas

Bret Pettichord diz em seu artigo “Seven Steps to Test Automation Success“, que devemos tratar a automação dos testes da mesma forma que tratamos qualquer outro projeto. De acordo com o Bret, se iremos desenvolver um software para auxiliar a automação será necessário:

Já se iremos adquirir um software para auxiliar a automação serão necessárias outras ações, como por exemplo:

Mark Fewster e Dorothy Graham, lembram em seu livro "Software Test Automation - Effective use of test execution tools", que há uma expectativa de que os testes automatizados irão encontrar diversos novos defeitos. Porém, é mais provável que um teste encontre um defeito, na primeira vez que ele é executado, e geralmente, a primeira execução é manual. E se o teste já foi executado e passou, é muito menos provável que uma nova execução do mesmo teste encontre um defeito, ao menos que o teste execute um código que foi mudado ou poderia ser afetado por uma mudança realizada em uma parte diferente do software, ou ainda executando o teste em um ambiente diferente.

Portanto é importante saber que várias ferramentas de execução de testes são ferramentas de "repetição", ou seja, ferramentas de teste de regressão. Elas são usadas para executar testes que já foram executados. E isto é muito útil, mas o objetivo principal destes testes não é encontrar novos defeitos, e sim nos dá confiança de que o software está funcionando da mesma forma de antes.

Uma expectativa errônea, que às vezes ocorre quando iniciamos a automatização dos testes, é a de que teremos que ter 100% dos testes automatizados e isso faz que as pessoas busquem uma meta que muitas vezes não é coerente.

Dificilmente iremos utilizar apenas uma ferramenta para automatizar os testes. Por exemplo: se iremos testar uma aplicação Web podemos automatizar os testes funcionais com o Selenium, já os testes de performance podemos automatizar com o JMeter.

É importante ter em mente, que o projeto de automação não dará resultados do dia para a noite. Aliás, bem pelo contrário, pois como já dito, a automação é um investimento a médio e longo prazo.

Como vimos anteriormente, a automação é essencial para alguns tipos de testes, porém para outros tipos de teste, como por exemplo, testes de usabilidade, ela não é viável.

Além disso, a automação não deve ser medida pela quantidade de casos de teste que foram automatizados, mas sim por quais testes foram automatizados e quanto tempo foi ganho com a automação. Em determinadas circunstâncias, pode até ser possível obter bons ganhos mesmo com apenas 10% dos testes automatizados. Por isso é importante saber o que será necessário automatizar e o que é mais prioritário. Automatizar apenas por automatizar costuma ser uma péssima ideia.

Automação no contexto ágil

A automação dos testes está entre as principais práticas ágeis, uma vez que as metodologias ágeis focam em entregas pequenas e curtas e que devem ter valor para o cliente.

E como garantir a qualidade de uma entrega que é feita em duas semanas, por exemplo?Por isso que a automação dos testes é uma prática imprescindível no desenvolvimento ágil, pois ela que irá ajudar o mesmo a se tornar sustentável, já que não é possível realizar ciclos curtos de entrega se tivermos que orçar um ciclo de teste manual.

É necessário poder executar os testes à vontade e de forma rápida (segundo o livro Agile Testing, 10 minutos), para obter feedback a respeito da qualidade do código. Você precisa escrever e executar os testes junto com o sistema sendo desenvolvido, para encurtar o ciclo de comunicação com o cliente e não perder tempo e esforço com mal-entendidos.

Os quadrantes de Brian Marick (figura 2) ilustra a ênfase da automação em agile. Mesmo para os testes do quadrante superior direito (crítica do produto / voltados ao negócio) é possível ser auxiliado por ferramentas de automação. Em outros quadrantes, não se descarta o teste manual. Na prática, apenas os testes de unidade (quadrante inferior esquerdo) são inviáveis sem automação e os testes do quarto quadrante são executados com o auxílio de ferramentas, muitos deles realizados de forma automatizada, como por exemplos os testes de desempenho.

É bom lembrar que no modelo de Teste Ágil, testes são pensados não apenas como mecanismo de detecção de defeitos, mas que também é analisado seu papel de especificação do comportamento do sistema e suporte à equipe de desenvolvimento. Requisitos, testes e exemplos são aspectos diferentes das mesmas especificações.

Indo mais a fundo no papel da automação dos testes no contexto ágil, por meio do quadrante do Marick, podemos notar os seguintes pontos a respeito de cada quadrante:

Kent Beck, criador do XP e do TDD, tem uma postura bem radical, em relação aos testes automatizados:

"Qualquer funcionalidade que não possui testes automatizados simplesmente não existe."

A visão de Kent Beck pode até parecer radical demais, mas os testes tem um papel fundamental em um ambiente ágil, e os ciclos curtos exigem que eles sejam automatizados, sempre que possível.

Duas práticas fortemente difundidas com o surgimento de metodologias ágeis é o TDD e o ATDD. O primeiro que é sigla para Test-Driven-Development (Desenvolvimento Orientado a Testes), e como o próprio nome já sugere, a ideia é fazer que desenvolvedor desenvolva o sistema sendo guiado pelos testes, ou seja, os testes não são propriamente o objetivo dessa prática e sim o desenvolvimento do sistema de uma forma sustentável, que favorecer a manutenbilidade e testabilidade do mesmo.

Já o ATDD do inglês Acceptance Test Driven Development (Desenvolvimento Orientado a Testes de Aceitação) faz com que o desenvolvedor desenvolva o sistema focado no negócio, utilizando testes de aceitação que validem o comportamento esperado do sistema. Esses testes de aceitação são criados, geralmente, com a participação do cliente e do analista de teste. A geração de tais testes faz com que seja gerada uma "documentação viva" do sistema, uma vez que a sua execução costuma ser feita de forma automatizada, por meio de ferramentas como o Fitnesse, por exemplo.

Ambas as práticas são utilizadas antes do desenvolvimento do código, afinal o objetivo é que elas possam orientar e ajudar o desenvolvedor no processo de codificação. O grande ganho de tais práticas, é que utilizando elas o desenvolvedor tem um melhor entendimento sobre o sistema, sem ter escrito sequer uma linha de código e os testes que foram criados com o propósito de auxiliar a modelagem do sistema poderão ser utilizados como testes de regressão, garantindo assim a corretude do sistema e facilitando futuras mudanças, uma vez que não haverá o medo de quebrar algo, já que temos uma rede de segurança, os testes automatizados.

Conclusão

A automação está longe de ser a bala de prata para o Teste de Software, mas pode trazer benefícios significativos para o projeto, quando utilizada adequadamente dentro do mesmo. Precisamos executá-la de forma incremental, sempre analisando quais testes que se automatizados trarão maior benefício à equipe.

Automatizar os testes não é algo simples, e diversas premissas são necessárias para que possamos trazer todos os benefícios da automação, pois caso contrário, ela irá trazer mais problemas. É importante ter em mente que quando partimos para a automação, não podemos esquecer das pessoas e do processo, afinal como diz um velho ditado: “Tolos com ferramentas , continuam tolos”.

Quando trabalhamos com ciclos curtos de entrega, a automação de testes torna-se essencial para conseguirmos garantir a qualidade do software que está sendo desenvolvido. Essa necessidade fez surgir várias ferramentas voltadas para a automação dos testes, boa parte delas distribuídas de forma gratuita.

Por fim, a resposta para a pergunta “Quando automatizar?”, só pode ser obtida por cada um, pois os fatores que podem influenciar a decisão pela automação podem variar muito de empresa para empresa. A intenção desse capítulo foi colocar em foco os desafios, características e fatores ligados a automação de teste, que aponta para ser uma das principais tendências na área de Teste de Software nessa nova década.

Referências Bibliográficas

[5] CRISPIN, Lisa; GREGORY, Janet. Agile Testing: A Practical Guide for Testers and Agile Teams. 1 ed. Addison-Wesley Professional. 2009.

[6] FEWSTER, Mark; GRAHAM, Dorothy. Software Test Automation - Effective use of test execution tools. Addison-Wesley Professional. 1999.