Começando com uma revisão do Plano de Teste para determinar as necessidades de avaliação, considere como a avaliação da extensão do teste e da qualidade do software pode ser determinada usando a Abordagem de Teste declarada. Considere qualquer necessidade especial que precise ser tratada relacionada a Itens de Objetivo do Teste específicos.

Reveja os mecanismos úteis para permitir o teste neste ambiente e identifique os elementos de teste específicos que implementam esses mecanismos. Isso inclui a revisão de recursos, como qualquer biblioteca de funções que tenha sido desenvolvida pela equipe de teste e os stubs ou harnesses implementados pela equipe de desenvolvimento.

A possibilidade de teste é atingida através de uma combinação de desenvolvimento de um software testável e definição de uma abordagem que suporte os testes de forma apropriada. Portanto, a possibilidade de teste é um aspecto importante do desenvolvimento de componentes para as equipes de teste, assim como é uma parte importante do esforço de desenvolvimento de software. A obtenção da Possibilidade de Teste (a capacidade de testar efetivamente o produto de software) tipicamente envolverá a combinação do seguinte:

• ativadores de possibilidade de teste fornecidos pelas ferramentas de automatização de testes
• técnicas específicas para criar os Scripts de Teste dos componentes
• bibliotecas de funções que separam e encapsulam a complexidade da definição básica de procedimento de teste no Script de Teste, fornecendo um ponto central de controle e modificação.

Analisar os Requisitos de Distribuição

O Conjunto de Testes atual possui o requisito a ser distribuído? Nesse caso, utilize os elementos de possibilidade de teste que suportam distribuição. Esses elementos serão tipicamente características de ferramentas de suporte de automatização específicas que distribuirão o Conjunto de Testes, executarão o conjunto remotamente e retornarão o Log de Teste e outras saídas para a determinação de resultados centralizados.

Analisar os Requisitos de Simultaneidade

O Conjunto de Testes atual possui o requisito para ser executado simultaneamente com outros Conjuntos de Testes? Nesse caso, utilize os elementos de possibilidade de teste que suportam a simultaneidade. Esses elementos serão tipicamente uma combinação de ferramentas de suporte específicas e funções de utilitário que permitirão que vários Conjuntos de Testes sejam executados simultaneamente em diferentes máquinas físicas. A simultaneidade exige design e gerenciamento de Dados de Teste cuidadosos para assegurar que nenhum efeito colateral inesperado ou não planejado ocorra, como dois testes simultâneos atualizando o mesmo registro de dados.

Enumerar um ou mais Conjuntos de Testes que (quando executados) fornecerão um resultado completo e significativo de valor para a equipe de teste, permitindo relatórios subseqüentes para os investidores. Tente equilibrar o nível de detalhes, de modo que sejam suficientes para fornecer informações específicas para a equipe de projeto, mas não tão detalhados a ponto de não poderem ser gerenciados.

Onde já existem Scripts de Teste, você provavelmente poderá montar sozinho o Conjunto de Testes e suas partes constituintes e, em seguida, passar o trabalho de estabilização do Conjunto de Testes para ser concluído por um Implementador de Conjunto de Testes.

Para Conjuntos de Testes que requerem a criação de novos Scripts de Teste, forneça também alguma indicação dos Scripts de Teste ou outros Conjuntos de Teste, que você acredita que serão referenciados por esse Conjunto de Testes. Se for fácil enumerá-los, faça isso. Caso contrário, você poderá fornecer apenas uma breve descrição que descreva a cobertura de conteúdo esperada do principal Conjunto de Testes e deixar a cargo do implementador do Conjunto de Testes a tomada de decisões táticas sobre exatamente quais Scripts de Teste serão incluídos.

Talvez seja necessário subdividir ainda mais ou reestruturar os Conjuntos de Testes identificados para acomodar a Estrutura de Divisão do Trabalho (WBS) na qual a equipe está trabalhando. Isso ajudará a reduzir o risco de ocorrência de possíveis conflitos de acesso durante o desenvolvimento do Conjunto de Testes. Algumas vezes, as ferramentas de automatização de testes podem impor restrições sobre o modo de trabalho dos indivíduos com componentes de automatização, portanto, reestruture os Conjuntos de Testes para acomodar isso conforme necessário

Na maioria dos casos, os Conjuntos de Testes podem simplesmente chamar os Scripts de Teste em uma ordem específica. Isso será suficiente em muitos casos para assegurar que o estado correto do sistema seja passado através de um Script de Teste para o próximo.

No entanto, em certas classes de sistema, os dados dinâmicos de tempo de execução são gerados pelo sistema ou derivados como resultado das transações que ocorrem dentro dele. Por exemplo, em um sistema de entrada e despacho de pedidos, em cada entrada de um pedido, um número de pedido exclusivo é gerado pelo sistema. Para permitir que um Script de Teste automatizado despache um pedido, um Script de Teste de entrada de ordem precedente precisa capturar o número exclusivo gerado pelo sistema e passá-lo para o Script de Teste de despacho do pedido.

Em casos como esse, você precisará considerar o mecanismo de comunicação de Script entre Testes que será apropriado para usar. Alternativas típicas incluem a passagem de parâmetros, leitura e gravação de valores em um arquivo de disco e utilização de variáveis globais de tempo de execução. Cada estratégia apresenta aspectos positivos e negativos que a torna mais ou menos apropriada em cada situação específica.

Isso está principalmente associado ao seqüenciamento dos Scripts de Teste e possivelmente aos Conjuntos de Testes para processamento em tempo de execução. Testes executados sem o estabelecimento das dependências corretas correm o risco de falharem ou de relatarem dados anômalos.

Se tiver acesso a uma ferramenta de desenho ou de modelagem UML, pode ser que você deseje criar um diagrama do Modelo de Implementação de Teste que descreva os elementos-chave do software de teste automatizado. Você também poderá diagramar alguns aspectos-chave da Arquitetura para Automatização de Testes de forma semelhante.

Outra abordagem possível é desenhar esses diagramas em um quadro branco facilmente visível para a equipe de teste.

À medida que o projeto progride, é provável que os Conjuntos de Testes sejam alterados: novos Scripts de Teste são incluídos e os Scripts de Teste antigos são atualizados, reordenados ou excluídos. Essas mudanças são uma parte natural da manutenção do Conjunto de Testes e você precisa aceitá-las em vez de evitá-las.

Se os Conjuntos de Testes não forem mantidos ativamente, eles serão interrompidos rapidamente e cairão em desuso. Abandonado por algumas construções, um Conjunto de Testes poderá exigir um esforço extenso para ressuscitar, sendo mais fácil, talvez, abandoná-lo e criar um novo a partir do zero. Consulte a seção Informações Adicionais:, na tabela de cabeçalhos desta página para obter diretrizes adicionais sobre como manter Conjuntos de Testes automatizados.

Usando os requisitos de Rastreabilidade descritos no Plano de Teste, atualize os relacionamentos de rastreabilidade conforme necessário.

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.