Estratégias para implantar o processo de automação de testes

Antes de definir quais ferramentas utilizar, perfis de pessoas à contratar/capacitar, linguagens de programação à utilizar e várias outras coisas, é preciso primeiro definir algumas estratégias para que o processo de automação de testes seja implantado com sucesso, alinhar expectativas e que o investimento traga resultados positivos.

Neste post vou apresentar algumas dessas principais estratégias que devem ser levadas em consideração antes de mais nada, e já começo com a seguinte pergunta:

Em quais testes concentrar meus esforços?

Isso pode variar com a cultura que cada empresa conduz os seus projetos, mas considerando o melhor dos cenários com processos muito bem definidos, vou apresentar um conceito criado por Mike Cohn descrito em Succeeding with Agile, que é a pirâmide do teste. São elas:

  • Testes Unitários
  • Testes de Aceitação / Integração / Testes de Componente
  • Testes de Interface.


Na pirâmide invertida, os esforços estão concentrados em Testes de Interface. Neste caso, o foco dessa abordagem é encontrar bugs, pois é nessa camada, que na maioria das vezes, é que conseguimos identificá-los.

Já na segunda pirâmide, os esforços estão concentrados na base da pirâmide já que o foco é prevenir erros. Com uma base sólida, as chances de encontrar bugs nas camadas superiores são menores.

A escolha de qual pirâmide adotar depende muito do foco que a empresa quer adotar como objetivo. É natural observar que a segunda pirâmide parece ser a melhor opção por conta do baixo esforço e maior ROI, mas nem sempre é possível adotá-la já que o contexto e cultura de cada empresa influencia bastante nesta escolha.

Com foco definido, o próximo passo agora é definir em qual forma os scripts de testes serão construídos. Sendo assim:

Scripting ou Record and Playback?

Essas são as duas maneiras mais comuns de construir scripts de automação mas como funciona cada uma?

Para o Scripting, a grande maioria das ferramentas de automação permitem que os analistas codifiquem scripts de testes através das linguagens de programação (Java, C#, Python, JavaScript,...). Isso permite mais flexibilidade durante a construção, reuso do código fonte e variação de dados. Mas para isso, é necessário que o analista tenha conhecimento prévio de programação, sem contar que o tempo de construção é bem maior se comparado com o Record and Playback que nada mais é do que a reprodução de um teste previamente gravado.

É como se você colocasse a ferramenta de automação para gravar suas ações na tela e em seguida ela gerasse um script automaticamente para você executá-lo.

No Record and Playback a construção do script é bem mais engessada, permite pouco reuso do código fonte e variação de dados. Só que em compensação a construção é muito rápida se comparada com o Scripting.

Assim como decidir qual pirâmide escolher, a adoção de cada uma dessas maneiras varia muito do contexto da empresa.

Quais e quantos testes automatizar?

Depois de definir onde concentrar os esforços e a maneira de construir os scripts, agora é hora de definir o quê e quanto de testes se deve automatizar.

Primeira regra: Priorize risco de negócio e cálculos.

Por exemplo: para um sistema bancário, priorize testes de liberação/recebimento de dinheiro. Nesse caso, testes automatizados nessas funcionalidades irão apresentar resultados de falha ou sucesso de forma bem mais rápida e confiável.

Já para os cálculos, é menos provável que um "robô" erre o cálculo, desde que programado corretamente, do que um ser humano.

Para ajudar a definir esses testes, tente responder às seguintes perguntas:

  • Quão importante ou quão crítico esse teste é para manter o negócio funcionando?
  • Qual é o impacto financeiro para a empresa em caso de erro?
  • Qual é a probabilidade de falha? Alto, média ou baixa?
  • Qual é o impacto na Service Level Agreement (SLA)?

Segunda regra: Não automatize tudo.

Existem testes que vão demorar tanto para serem construídos ou que serão executados raramente, que o script de teste será tão caro a ponto de tornar inviável a construção.  Nesse caso valeria mais a pena executá-lo manualmente do que prepará-lo para executar automaticamente. Sendo assim, tente começar entre 10% e 15% dos testes de regressão com base na primeira regra. Já é um excelente começo! Ao longo do tempo aumente esse percentual, mas lembre, não vale a pena chegar ao 100% de casos de testes automatizados. Com quase tudo definido, aparecem outras perguntas tão importante quanto as anteriores.

Quando, onde e por quem será executado?

"O quanto antes e o mais frequente possível". Embora possa parecer uma abordagem interessante, nem sempre ela trará grandes resultados. Se sua bateria de testes for pequena, não há problema algum em executá-la com bastante frequência, mas tenha em mente que isso é inversamente proporcional ao tempo à medida que ela começa a ficar grande demais.

Uma forma de manter a frequência e tempo de execução baixo seria fazer execuções com paralelismo. Só que pra isso, o investimento teria que ser maior para esse caso. Deve-se colocar na ponta do lápis esses custos e avaliar o orçamento.

Dessa forma, "quebre" a bateria em baterias menores com base no risco no negócio e impacto de análise (baseado nas mudanças da nova versão de teste).

Uma boa estratégia inicial seria:

  • Executar testes de fumaça após cada build ou commit.
  • Executar teste em funcionalidades críticas diariamente.
  • Executar todos testes de regressão semanalmente.

A medida que o projeto for evoluindo, essa estratégia deve ser evoluída também. Mas lembre, é importante ter todos os seus testes seja executado com frequência pois quanto mais testes forem executados, maiores serão os retornos de investimento (ROI).

Uma outra importante pergunta a ser respondida é onde e por quem serão executados a bateria de testes.

Podemos detalhar ainda mais a estratégia inicial da seguinte forma:

  • Ambiente mais instável (DEV) - por desenvolvedores
    • Executar testes de fumaça após cada build ou commit.
  • Ambiente instável (DEV) e estável (QA) - por desenvolvedores e testadores
    • Executar teste em funcionalidades críticas diariamente.
  • Ambiente estável (QA)
    • Executar todos testes de regressão semanalmente.

Dessa forma é possível manter uma boa frequência de execuções e em diferentes ambientes possíveis.

Conclusão

Não existem regras absolutas para implantar o processo de automação de testes. Existem contextos, perfis e culturas diferentes para cada situação e para isso a escolha de cada estratégia deve ser muito bem avaliada para atender cada particularidade.

Espero que esse post tenha esclarecido algumas dúvidas e que facilite sua tomada de decisão.
Até mais….

 

 

About Leonardo Amaral

Graduado em Análise e Desenvolvimento de Sistemas (UNATEC) e certificado em fundamentos de testes (CTFL / ISTQB). Mais de 7 anos de experiência com processos e qualidades de testes. Leonardo atua com gerenciamento de testes em fábricas de softwares , consultoria em automação de testes e ferramentas de qualidade de software.