Para desempenhar essa tarefa dentro do contexto apropriado, é importante ter uma compreensão adequada do software que está sendo desenvolvido, de sua arquitetura e dos principais mecanismos e recursos que ele suportará. Examine a documentação disponível referente à arquitetura do software para obter uma noção inicial e a suplemente com entrevistas e debates com o arquiteto de software, se necessário. Considere o impacto que cada ambiente de destino de implementação pode ter nessas informações e observe novos fatores que possam ser relevantes para o esforço de teste.

Utilizando o conhecimento da arquitetura de software e seus ambientes de destino, examine as informações fornecidas na abordagem e teste. Considere os principais aspectos técnicos da abordagem e crie uma lista de sugestões de mecanismos que serão necessários para suportá-la. Aqui está uma lista parcial dos mecanismos comuns a serem considerados como sugestões: persistência, simultaneidade, distribuição, comunicação, segurança, gerenciamento de transações, recuperação, manipulação e relatório de detecção de erros e controle e sincronização do processo.

Observe que esses mecanismos normalmente se aplicam aos esforços de teste manual e automatizado, embora um mecanismo específico possa ter mais ou menos relevância para o teste manual ou automatizado. Observe também que embora o mesmo mecanismo seja necessário para ambos os esforços de teste, as características da solução implementada geralmente serão diferentes.

Examine as ferramentas de teste disponíveis e as implementações de teste existentes e crie um inventário dos mecanismos que têm uma ou mais soluções. Embora esse passo seja mais obviamente relevante em termos do esforço de teste automatizado, há algumas considerações equivalentes para o esforço de teste manual.

Subtópicos:

• Mecanismos de Automação de Teste
• Mecanismos de Teste Manuais

Mecanismos de Automação de Teste

Comece compilando uma lista das ferramentas disponíveis ou que você planeja adquirir. Lembre-se de que as ferramentas de automatização assumem várias formas e sua lista normalmente incluirá mais do que as ferramentas de implementação e execução de testes automatizados. Para cada ferramenta, examine os mecanismos fornecidos por ela. Por exemplo, a ferramenta de criação de script que você planeja utilizar fornece seu próprio mecanismo de persistência de dados e, neste caso, é apropriado às suas necessidades ou será necessário complementá-la? Outras perguntas podem incluir: a ferramenta de execução permite a execução simultânea de scripts de teste em várias máquinas cliente do host? A ferramenta de execução permite a distribuição de scripts de uma máquina mestre central para várias máquinas cliente do host?

Quando implementações de automatização de teste estiverem disponíveis, haverá outros mecanismos para inventário. Alguns aspectos dessas implementações estenderão ou suplementarão os mecanismos básicos fornecidos pelas ferramentas para torná-los mais úteis. Outros aspectos oferecerão implementações para mecanismos adicionais não fornecidos na ferramenta básica.

Mecanismos de Teste Manuais

Em um nível básico, isso envolverá a revisão da guia de teste existente para a implementação e a execução do teste. Você deve procurar soluções de processo existentes para questões como simultaneidade, como os testadores podem compartilhar conjuntos de dados, principalmente estruturas de dados existentes, sem afetar um ao outro de forma adversa; distribuição, se a equipe de teste está distribuída, quais soluções estão disponíveis para a coordenação dos esforços de teste separados.

Agora que você decidiu sobre os mecanismos de teste necessários, precisa comunicar sua escolha à equipe de teste e a outros investidores no esforço de teste. Recomenda-se documentar as decisões sobre os mecanismos de teste necessários para a automatização como parte da documentação Arquitetura de Automatização de Teste, e aquelas relacionadas ao teste manual como parte do Guia de Teste.

Como alternativa à documentação formal, você pode simplesmente registrar essas informações como um conjunto de observações de arquitetura e processo, acompanhadas de alguns diagramas explanatórios, possivelmente mantidos em um quadro branco. Durante a implementação e execução do teste, testadores individuais utilizarão essas informações para tomar decisões táticas.

Quando você identificar o possível requisito de interfaces de teste especiais que precisarão ser criadas no software que está sendo desenvolvido, considere registrar esse requisito criando um ou mais resumos de Especificações de Interface de Teste; esse resumo deve fornecer um nome, uma breve descrição e enumerar os principais requisitos ou características de interface de teste. Evite perder muito tempo com esses esboços; a lista de requisitos e recursos será detalhada subseqüentemente em Tarefa: Definir Elementos de Testabilidade.

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 as listas de verificação fornecidas no RUP para verificar se a qualidade e a integridade estão suficientemente boas.

Faça com que as pessoas que desempenham tarefas posteriores, que dependem do seu trabalho como entrada, participem da revisão do seu trabalho provisó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 seu trabalho em relação aos principais produtos de trabalho de entrada para certificar-se de que foram representados de maneira precisa e suficiente. Pode ser útil fazer com que o autor do produto de trabalho de entrada revise seu trabalho nessa base.

Não se esqueça de que o RUP é um processo de entrega interativo e que, em muitos casos, os produtos de trabalho evoluem com o tempo. Dessa formal, nem sempre é necessário (e às vezes é contraproducente) formar completamente um produto de trabalho que será utilizado apenas parcialmente ou que nem será utilizado no trabalho imediato subseqüente. Isso acontece porque há uma grande probabilidade de que a situação em torno do produto de trabalho sofra alterações e de que os pressupostos feitos quando o produto de trabalho foi criado se provem incorretos, antes que o produto de trabalho seja utilizado, resultando em esforço perdido e 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.