Desenvolver e implantar um software de qualidade, dentro de prazo e dos custos planejados por incrível que possa parecer, ainda não é uma atividade trivial. Parte importante desse processo de desenvolvimento é a fase de testes funcionais do software, que deve ser planejada e ter uma estratégia definida. Estratégia que segundo a Wikipédia é a definição de como recursos serão alocados para se atingir determinado objetivo. Quais são os recursos necessários e os objetivos  para a realização de um teste funcional? É sobre isso que trataremos nesse artigo.
1º Passo – Definição da quantidade de builds que serão liberadas para os testes funcionais

Se o software a ser testado é de tamanho pequeno ou médio, provavelmente será liberado em uma build única. Para softwares maiores muitas vezes é comum liberar duas ou mais builds para testes funcionais. Por exemplo, um sistema de gestão acadêmica pode ser liberado para testes em duas builds, sendo que a 1ª build poderia conter os módulos de cadastros de professores, turmas e disciplinas. A 2ª build acrescentaria os módulos de lançamento de notas e faltas aos módulos da 1ª build (supondo um desenvolvimento iterativo e incremental)

Porque a definição da quantidade de builds é importante para a estratégia de testes funcionais?

Sabendo-se a quantidade de builds que serão liberadas para testes, nos permite elaborar o planejamento da etapa de elaboração dos roteiros de testes funcionais, de forma que se possa priorizar os roteiros dos módulos que serão liberados na 1ª build do software a ser testado.

Com essa informação é possível também definir sobre a quantidade de ciclos de testes que serão necessários. No nosso exemplo, como temos duas builds, uma estratégia possível para os ciclos seria: execução de um ciclo para a 1ª build (cadastro de professores, turmas e disciplinas), e dois ciclos para a 2ª build (cadastro de professores, turmas, disciplinas, lançamento de notas e faltas). sendo o 3º  ciclo destinado a validar a correção dos eventuais defeitos encontrados no 2º ciclo.

2º Passo – Definição da massa de dados necessária para os testes funcionais

A correta definição das necessidades quanto à massa de dados certamente é um fator crítico de sucesso para uma boa estratégia de testes. Para sistemas on-line, dependendo da sua natureza, consegue-se gerar as massas de dados necessárias durante a própria execução dos casos de testes. Por exemplo: num sistema de gestão acadêmica pode-se efetuar o cadastro de professores, turmas e disciplinas através da execução dos casos de testes destas funcionalidades.

Já para sistemas batch o mais comum é haver a necessidade de geração de massa de dados como pré-condição para a execução dos testes, e daí se faz necessário se planejar a estratégia que será utilizada para essa geração de massa de dados, levando-se em consideração os seguintes pontos:

- Os dados necessários serão gerados a partir do zero, ou copiados e descaracterizados do ambiente de produção?

- Se os dados forem copiados de produção, será necessário se fazer uma redução da massa de dado?

- Depois de uma execução dos testes, e havendo consumo da massa de dados, qual será o processo para se gerar novamente a massa de dados?

3º Passo – Controle de versão e congelamento da build sob teste

Definir os mecanismos ou ferramentas que serão utilizados para o controle de versão e o congelamento das builds que serão testadas é outro passo fundamental para o sucesso da estratégia dos testes. Muitas vezes os testes funcionais são feitos sem que a build seja congelada, resultando em alterações de código pelo desenvolvedor enquanto a equipe de teste está executando os testes e relatando eventuais defeitos. O resultado é a perda de consistência nos resultados da execução dos testes. Sem build congelada e controle de versão não há resultados confiáveis da execução dos testes.

estrategia

4º Passo – Definição do ambiente de testes

O ambiente em que serão realizados os testes funcionais normalmente é conhecido como ambiente de teste integrado, se diferenciando tanto do ambiente de desenvolvimento (destinado logicamente ao desenvolvedor de software) quanto do ambiente de homologação (destinado ao cliente final do software). O ambiente de teste integrado deve conter uma configuração similar ao do ambiente de homologação, e recebe uma build oriunda o ambiente de desenvolvimento, que é congelada para os testes funcionais. Trabalhando-se com esses três ambientes de testes, o de desenvolvimento, o de testes integrados, e o de homologação cada um serve a um propósito específico, e garante-se uma melhor qualidade de software a ser implantado.

5º Passo – Estimativa de esforço e prazo para projeto e execução de testes

A definição de estratégia dos testes funcionais deve reservar um tópico para as estimativas de esforços e prazos para toda a etapa de testes, desde a elaboração dos roteiros de testes, preparação do ambiente e massa de dados até a execução dos testes. Estimativas é sempre um assunto polêmico: existem aqueles que adotam o ponto de função como métrica para estimativas para testes, há os que adotam apenas a hora x homem, há aqueles que constroem suas bases histórica, e há também aqueles que não estimam.

O que mais me parece prático é a construção de uma base histórica de projetos de testes da sua empresa, que capture a natureza e complexidade dos seus projetos e a produtividade da sua equipe de testes tanto para a elaboração dos roteiros de testes quanto para execução dos mesmos. A partir dessa base histórica pode-se estabelecer estimativas mais confiáveis para o projeto e execução dos testes.

6º Passo – Critérios de interrupção e de finalização dos testes

Neste passo define-se quais são os critérios que ocasionarão a interrupção dos testes, como por exemplo, indisponibilidade do ambiente de testes por mais de duas horas, alteração da build durante a execução dos testes, falta de massa de dados adequada para a execução dos casos de testes planejados.

Além disso define-se também quais serão os critérios de finalização dos testes: execução completa de 3 ciclos de testes, ausências de erros classificados como críticos, por exemplo.

Uma boa estratégia de testes deve ser elaborada no ínicio do desenvolvimento do software, de forma que possa servir como um documento que permita o planejamento dos recursos materiais e humanos necessários para se garantir uma boa qualidade do software que será implantado. E você, o que considera importante para a estratégia de testes de software?