Usando a missão de avaliação como contexto, examine o Plano de Teste de iteração e estude os motivadores de teste identificados para o próximo esforço de teste. Talvez seja necessário uma maior investigação na fonte de Motivadores - geralmente, o plano de iteração permite localizar informações adicionais.

Considere a abordagem de teste e as técnicas associadas que podem ser necessárias para abordar cada Motivador. Examine também o Plano de Teste de iteração e estude os itens de teste. Cada item de objetivo do teste deverá ser considerado em relação a cada Motivador, e a abordagem e as técnicas deverão ser estendidas de acordo. Se você não conseguir localizar muitos detalhes ou se não estiver familiarizado com os itens de teste, talvez seja conveniente discutir os itens de destino com a equipe de desenvolvimento, normalmente começando pelo arquiteto de software ou pelos chefes da equipe de desenvolvimento.

Concentre-se em identificar o conjunto mínimo de técnicas necessárias para abordar satisfatoriamente a missão de avaliação e os motivadores. Procure por oportunidades em que uma técnica possa ser usada para abordar mais de um aspecto do teste necessário. Observe outras técnicas possíveis que pareçam interessantes para serem exploradas, mas esteja preparado para identificá-las como adicionais, e não essenciais.

Estude a Arquitetura de Software para compreender seus elementos-chave, os mecanismos, as visualizações principais, etc. Em geral, o Documento de Arquitetura de Software fornece informações apropriadas, com o nível certo de detalhes, para serem utilizadas no caso de uma abordagem de teste. Para esclarecer essas informações ou, na falta de um documento, convém discutir a arquitetura com a equipe de desenvolvimento, normalmente conversando diretamente com o arquiteto de software ou com um dos chefes da equipe de desenvolvimento.

Concentre-se na identificação e na discussão dos principais mecanismos e tente adquirir uma boa compreensão desses aspectos do sistema. Cada mecanismo e principal característica da arquitetura provavelmente apresentará desafios ou restrições ao esforço de teste. Por exemplo, uma arquitetura distribuída pode necessitar que a equipe de teste seja organizada em subequipes, com cada equipe concentrada em uma camada de arquitetura.

Embora uma estratégia criativa de implementação e execução de teste possa ser utilizada com freqüência para superar esses desafios, pode ser necessário que a equipe de desenvolvimento modifique o software para ativar o teste, conforme descrito em Tarefa: Definir Elementos de Possibilidade de Teste.

Baseado em sua experiência, reveja os requisitos para a abordagem do teste nos níveis geral e detalhado apropriados para este estágio do ciclo de vida do projeto. Considere os requisitos adicionais que ajudarão a apresentar uma abordagem mais completa.

Com base em sua própria experiência ou em outra experiência à qual você tenha acesso, identifique as técnicas existentes que atenderão aos requisitos da abordagem de teste ou que poderão ser adaptadas para atendê-los.

Não é muito vantajoso pensar em termos de uma abordagem de teste "completo"; há sempre técnicas adicionais que você poderia tentar apenas se tivesse tempo e recurso ilimitados.

Entretanto, é importante que a abordagem de teste seja bem definida e abrangente o bastante para permitir uma avaliação útil da qualidade percebida que deverá ser feita. Isso requer uma abordagem que avalie aspectos suficientes do risco ou das dimensões de qualidade para que a equipe de projeto avalie a qualidade percebida com um grau de confiança justificado.

Descrever as funções de cada técnica. Abordar o tipo de teste suportado, o objetivo e o escopo, o método de implementação, as previsões de teste, o método de avaliação e as necessidades de automatização da técnica.

Em vários casos, você reutilizará a técnica de um projeto para o outro. Nessa situação, você poderá simplesmente fazer referência a uma definição comum da técnica ou copiar a definição existente e revisá-la, conforme apropriado.

Para cada técnica existente ou requerida:

• Definir objetivos e escopo
• Descrever o método de implementação
• Identificar o método de avaliação adequado
• Identificar o uso aplicável da automação,
• Identificar ferramentas aplicáveis

Definir Objetivos e Escopo

Várias técnicas suportarão mais de um tipo de teste, portanto, pense um pouco e tente identificar quais testes a técnica precisará suportar. Isso ajudará a identificar o escopo do esforço necessário caso a técnica esteja sendo definida pela primeira vez.

Pense no objetivo fundamental e no valor representado por essa técnica.

Descrever o Método de Implementação

Defina como a técnica será implementada. Não basta simplesmente afirmar "Estamos testando o desempenho do sistema", você deve pensar seriamente como isso pode ser alcançado.

Algumas técnicas que você gostaria de usar têm um custo elevado para serem adquiridas. Descrevendo rapidamente como abordará a implementação dessa técnica, você conseguirá obter um sentido geral da logística e dos aspectos práticos que envolvem a aquisição da técnica futuramente.

Identificar o Método de Avaliação Adequado

Determine como você observará e avaliará os resultados de cada teste implementado utilizando essa técnica. Pense nas diferentes Previsões de Teste que estão disponíveis para uso. Existe uma única previsão ou há diferentes maneiras de determinar o resultado de cada teste?

Identificar o Uso Aplicável da Automação

A automatização pode desempenhar uma função importante em várias técnicas de teste. Em alguns casos, ela será menos sofisticada, simplesmente oferecendo suporte para a condução de testes manuais.

Pense em como o trabalho que envolve a técnica poderia ser implementado, mantido e gerenciado de modo mais eficaz. Pense em todos os aspectos, considerando o maior número de opções possíveis.

Identificar as Ferramentas Aplicáveis

Identifique as ferramentas apropriadas a serem usadas com essa técnica de teste. Use o trabalho do passo anterior que identificou as utilizações da automatização.

Lembre-se de considerar uma ampla variedade de categorias de ferramentas; sua lista de sugestões de ferramentas deve incluir mais do que apenas as ferramentas de automatização para execução de testes. Além das ferramentas que automatizam a execução de testes, considere ferramentas que melhorarão a produtividade da equipe de teste, reduzindo tarefas repetitivas e trabalhosas, como gerenciamento de Dados de Teste, análise de Resultados de Teste, ferramentas de relatórios de incidentes e de Controle de Mudanças, etc.

Baseado na experiência adquirida de sistemas semelhantes ou em domínios de problema semelhantes, comece a definir uma arquitetura sugerida para o sistema de automatização de testes.

Recomendamos que você revise as informações relacionadas ao desenvolvimento de arquitetura de software para ajudá-lo com essa tarefa.

Assim como vários outros produtos de trabalho produzidos durante um projeto de desenvolvimento de software, os recursos de teste são sugestões para o gerenciamento de configuração e o controle de versão.

Os requisitos específicos podem variar em termos de complexidade, desde a decisão de utilização de serviços básicos de backup e recuperação permitidos até o suporte total para o desenvolvimento paralelo de Scripts de Teste automatizados em vários locais com diferentes versões de um aplicativo.

Pense nos seus requisitos para o gerenciamento de configuração e comece a esquematizar as prováveis necessidades de logística para a realização desses requisitos.

Algumas vezes é melhor construir recursos a partir do zero e outras vezes não. Tente encontrar um bom equilíbrio entre uma filosofia completa do tipo "faça você mesmo" e o estabelecimento de uma política rígida e burocrática para a criação de um novo produto de trabalho.

Algumas vezes, uma abordagem será melhor do que outra, portanto, você deve ser flexível o suficiente para aproveitar os benefícios oferecidos pelas duas abordagens.

De acordo com diversos fatores, incluindo tamanho da equipe e cultura da organização, haverá maneiras melhores e piores de registrar as decisões feitas sobre a abordagem de teste.

Normalmente você considerará dois públicos: a equipe de gerenciamento desejará revisar essas informações para fornecer aprovação e estar ciente das implicações logísticas da abordagem e a equipe de teste desejará utilizar a abordagem de teste como orientação para o trabalho a ser realizado. Tente localizar um meio apropriado para tratar adequadamente de ambas as necessidades: talvez utilizando um Web site de Intranet do projeto.

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.