Comece revendo as descrições existentes para os Conjuntos de Testes e determine quais Conjuntos de Testes são boas sugestões para a implementação no momento atual. Utilize o Plano de Teste de Iteração, a Lista de Idéias de Teste e qualquer produto de trabalho adicional de definição de teste como uma base para tomar sua decisão.

Para cada Conjunto de Testes selecionado para implementação, identifique quais Itens de Objetivo do Teste e Testes associados são sugestões para inclusão no escopo do Conjunto de Testes.

Comece considerando a Configuração do Ambiente de Teste e o estado inicial específico do sistema. Considere quais requisitos específicos de configuração serão definidos, como o conjunto de dados inicial para bancos de dados dependentes. Onde uma Configuração do Ambiente de Teste será utilizada para vários Conjuntos de Testes, identifique as definições de configuração que talvez precisem ser gerenciadas para cada Conjunto de Testes, como a resolução de tela de exibições de vídeo ou as configurações regionais do sistema operacional.

Agora determine quaisquer relacionamentos específicos entre os Testes. Procure por dependências em que a execução de um Teste incluído no Conjunto de Testes resultará em uma alteração de estado do sistema necessária como uma pré-condição de um outro Teste.

Depois de identificadas as dependências relevantes, determine a seqüência correta de execução para os Testes dependentes.

Um dos principais desafios para manter um Conjunto de Testes, principalmente um conjunto automatizado, é assegurar que mudanças contínuas sejam fáceis de serem efetuadas. Recomenda-se que, sempre que possível e conveniente, você mantenha um ponto central de modificação para os elementos usados em vários locais. Faça isso especialmente se esses mesmos elementos provavelmente forem alterados.

Embora os próprios Testes formem unidades naturais de modularidade, a montagem dos Testes em um Conjunto de Testes geralmente identifica elementos de procedimento duplicados em vários Testes que poderiam ser mantidos de forma mais eficaz se fossem consolidados. Aproveite a oportunidade para identificar qualquer mecânica geral dos Testes que possa ser potencialmente refatorada em uma rotina padrão para ajudar na manutenção contínua.

A maioria dos esforços de teste requer o uso de um ou mais "utilitários" que geram, reúnem, diagnosticam, convertem e comparam as informações utilizadas durante a execução dos testes. Esses utilitários normalmente simplificam tarefas complexas e trabalhosas que estariam propensas a erros se fossem executadas manualmente. Este passo é relativo à aplicação de funções de utilitário existentes dentro do Conjunto de Testes e à identificação de novos utilitários necessários.

Recomenda-se simplificar as interfaces com esses utilitários, encapsulando todas as complexidades possíveis dentro da implementação privada do utilitário. Também convém desenvolver o utilitário de modo que ele possa ser reutilizado onde for necessário para esforços de teste manuais e automatizados.

Recomendamos que você não oculte as informações que caracterizam um teste individual dentro desses utilitários: em vez disso, limite o utilitário à mecânica complexa de reunir informações ou comparar valores reais com os resultados esperados, etc. Mas onde possível, transmita as características específicas de cada teste individual como entrada a partir de- e retornar o teste individual atual resulta em uma saída para- um Teste controlador ou Conjunto de Testes.

Determine os pontos apropriados no Conjunto de Testes para recuperação em caso de falha do Conjunto de Testes durante uma execução. Esta etapa é considerada importante quando o Conjunto de Testes contém um grande número de Testes ou quando executará por um longo período de tempo, normalmente de modo não assistido. Embora geralmente sejam identificados como requisitos para os Conjuntos de Testes automatizados, os pontos de recuperação também devem ser considerados para os Conjuntos de Testes executados manualmente.

Além dos pontos de recuperação ou reinício, você talvez também deseje, no caso de Conjuntos e Testes automatizados, considerar a recuperação do Conjunto de Testes automatizado. As duas abordagens para a recuperação automática são: 1) recuperação básica quando o Conjunto de Testes existente puder se recuperar automaticamente de um erro secundário ocorrido em um de seus Testes, normalmente recuperando a execução no próximo Teste do Conjunto de Testes ou 2) recuperação sofisticada que será limpa após o Teste com falha, reconfigurando o estado apropriado do sistema, incluindo reinicialização do sistema operacional e restauração de dados, se necessário. Como na primeira abordagem, o Conjunto de Testes determina o Teste que falhou e seleciona o próximo Teste a ser executado.

Dependendo do nível de sofisticação exigido, será necessário um esforço para implementar e estabilizar o processamento de recuperação. Reserve um tempo para simular algumas falhas prováveis (e algumas improváveis) a fim de testar o funcionamento do processamento de recuperação.

No caso de uma recuperação automatizada, as duas abordagens descritas no passo anterior apresentam pontos positivos e negativos. Considere com cuidado o custo de uma recuperação automatizada sofisticada em termos de desenvolvimento inicial e em termos de esforço de manutenção contínua. Algumas vezes, a recuperação manual já é suficiente.

Reserve um tempo para estabilizar o Conjunto de Testes através de uma ou mais execuções de teste de avaliação, sempre que possível. A dificuldade em alcançar a estabilidade aumenta de forma proporcional na complexidade do Conjunto de Testes e quando há um acoplamento muito grande entre Testes não relacionados e pouca coesão entre Testes relacionados.

É possível que ocorram erros quando Testes são executados juntos em um determinado Conjunto de Testes, que não foram encontrados quando os Testes individuais foram executados de forma independente. Esses erros geralmente são os mais difíceis de serem controlados e diagnosticados, principalmente quando são encontrados no meio de um longo processo de execução de um teste automatizado. Sempre que for conveniente, recomenda-se reexecutar o Conjunto de Testes regularmente à medida que você inclui Testes adicionais. Isso ajudará a isolar um pequeno número de possíveis sugestões de Testes que serão diagnosticadas para a identificação do problema.

Usando os requisitos de Rastreabilidade descritos no Plano de Teste, atualize os relacionamentos de rastreabilidade conforme necessário. Os Conjuntos de Testes podem ser rastreados até os Casos de Teste ou até as Idéias de Teste definidas. Opcionalmente, eles podem ser rastreados até os Casos de Uso, os elementos de especificação de software, os elementos do Modelo de Implementação e até uma ou mais medidas da Cobertura de Teste.

Agora que o trabalho foi concluído, convém certificar-se de que o trabalho foi vantajoso e que não foi apenas um grande consumo de papel. Você deve avaliar se o trabalho é de qualidade adequada e se ele é completo o suficiente para ser útil aos membros da equipe que o utilizarão em seguida como entrada para o trabalho deles. Onde for possível, utilize listas de verificação fornecidas no RUP para verificar se a qualidade e a abrangência são "suficientemente boas".

Faça as pessoas que realizam as tarefas de recebimento de dados, que dependem do seu trabalho como entrada, participarem da revisão do trabalho temporário. Faça isso enquanto você tiver tempo disponível para tomar alguma ação para resolver os problemas delas. Você também deve avaliar o trabalho em relação aos principais produtos de trabalho de entrada para certificar-se de que eles foram representados de modo preciso e suficiente. Pode ser conveniente que o autor do produto de trabalho de entrada revise o seu trabalho nesse sentido.

Não se esqueça que o RUP é um processo de entrega iterativo e que, em muitos casos, os produtos de trabalho evoluem com o tempo. Nem sempre ele é necessário e, criar um produto de trabalho completo geralmente é contraproducente, pois ele será usado apenas parcialmente ou não mais será usado em outros trabalhos. Isso acontece porque há uma grande probabilidade de alteração na situação em torno do produto de trabalho e de que as suposições feitas durante a criação do produto de trabalho estejam incorretas, antes do produto de trabalho ser utilizado, resultando em esforço perdido e, portanto, em retrabalho dispendioso. Evite também a armadilha de gastar muitos ciclos na apresentação em detrimento do valor do conteúdo. Nos ambientes de projeto em que a apresentação tem importância e valor econômico como um produto liberado do projeto, convém utilizar um recurso administrativo para executar as tarefas de apresentação.