Conceitos: O Ciclo de Vida do Teste

No ciclo de vida do desenvolvimento de software do RUP, o software é refinado através de iterações. Nesse ambiente de processo, o ciclo de vida do teste tira proveito de uma abordagem iterativa equivalente. Em cada iteração, a equipe de desenvolvimento de software produzirá um ou mais Builds, cada um deles representando uma possível sugestão a ser testada.

Como o foco e os objetivos da equipe de desenvolvimento variam de acordo com a iteração, os membros da equipe de teste devem estruturar o esforço de teste de forma apropriada. Sugerimos que você se detenha muito no planejamento e design detalhado prévio e, quando precisar fazer isso, não realize esse trabalho muito antes da hora em que ele será usado. É recomendável realizar o desenvolvimento do teste detalhado prévio com a antecedência máxima de uma iteração.

Adições, refinamentos e exclusões são efetuados nos testes implementados e executados para cada build. Alguns desses testes são retidos e acumulados em um conjunto de testes, que é usado para realizar o teste de regressão em builds subseqüentes usados em cada ciclo de teste posterior. Essa abordagem retrabalha e revisa os testes durante todo o processo, assim como o software em si é revisado. Não há nenhuma especificação de software congelada e nem testes congelados.

Fig. 1. Os testes evoluem ao longo do tempo

Essa abordagem iterativa — combinada ao uso de arquiteturas de componentes — precisa ser considerada no teste de regressões quanto à qualidade do produto em cada build subseqüente. Qualquer teste desenvolvido na iteração X é uma possível sugestão ao teste de regressão na iteração X+1, da mesma forma na iteração X+2 e assim por diante. Quando houver possibilidade de o mesmo teste ocorrer várias vezes, vale a pena considerar sua automatização. O teste de automatização fornece uma abordagem para o teste repetido de cenários de uso, que libera a equipe de teste para explorá-lo em novas áreas funcionais.

Observe o ciclo de vida do teste sem o restante do projeto na mesma figura. Esta é a divisão dos detalhes de trabalho para a disciplina Teste em uma determinada iteração:

Fig. 2. O ciclo de vida do teste.

Esse ciclo de vida está de acordo com o ciclo de iteração, seguido do restante da equipe de desenvolvimento. A Iteração começa com uma investigação pela equipe de teste e a negociação com o Gerente de Projetos e outros investidores, em relação ao trabalho de teste mais útil que pode ser realizado na próxima iteração. A maioria dos membros da equipe de teste tem participação nesse esforço de trabalho.

Em geral, cada iteração conterá pelo menos um ciclo de teste, como mostrado na Fig. 3. É uma prática muito comum produzir vários Builds por Iteração e um ciclo de teste corresponder a cada build. Contudo, em alguns casos, determinados Builds não serão testados.

Enquanto o principal esforço de teste estiver em curso, um subconjunto dos membros da equipe também pode investigar novas técnicas de teste. Esse esforço tenta provar que as técnicas existem para que a equipe possa contar com elas, principalmente em iterações subseqüentes.

Fig. 3. Uma iteração contém um ou mais ciclos de teste.

O ciclo de vida do teste faz parte do ciclo de vida do software; eles devem ser iniciados ao mesmo tempo. O processo de design e desenvolvimento de testes pode ser tão complexo quanto o processo de desenvolvimento do software em si. Se os testes não forem iniciados juntamente com os primeiros releases executáveis do software, o esforço de teste retardará a descoberta de muitos problemas no ciclo de desenvolvimento. Em geral, isso resulta em um longo período de correção de erros após a programação de desenvolvimento, acabando com as metas e as vantagens do desenvolvimento iterativo.

Como o início antecipado das atividades de planejamento e definição de testes pode expor falhas importantes no trabalho de especificação inicial, recomendamos que você escolha o trabalho de teste com cuidado e antecedência. Além da possibilidade de retrabalho já mencionada, a equipe de teste precisa ter cuidado para manter seu papel como consultora de qualidade imparcial e não se desviar das atividades de design e dos requisitos iniciais, atuando como "guardiã da qualidade". Por sua própria natureza, não adiantará nada a equipe de projeto tentar compreender antecipadamente os problemas e as soluções. A demanda excessiva sobre a qualidade desse trabalho inicial pode provocar a alienação da equipe de teste em relação ao restante do grupo de desenvolvimento.

Os problemas localizados durante uma iteração podem ser solucionados nessa iteração ou adiados para a próxima — uma decisão que fica, em última instância, a critério do papel Gerente de Projeto. Uma das principais tarefas da equipe de teste e dos gerentes de projeto consiste em medir a abrangência da iteração, verificando se os objetivos descritos no Plano de Iteração foram alcançados. A "detecção de requisitos" é realizada continuamente a cada iteração, e você precisa estar atento e preparado para gerenciá-la.

A maneira como os testes serão executados dependerá de vários fatores: seu domínio do aplicativo, seu orçamento, as políticas de sua empresa, sua tolerância a riscos e sua equipe. Quanto você deve investir em teste depende de como você avalia qualidade e tolera riscos em seu ambiente.

Rational Unified Process