Estude a arquitetura de automatização de testes e as especificações da interface de teste para obter um bom entendimento das necessidades de implementação e avaliação do teste. Em particular, compreenda as restrições que serão impostas por essas necessidades ao processo de liberação do software ou à arquitetura e ao design do software.

Estude as necessidades de testabilidade e execute a análise básica em termos do impacto no esforço de teste provocado pela necessidade não ter sido atendida. Considere também algumas análises básicas do esforço possível exigido pela equipe de desenvolvimento para investigar e fornecer uma solução para a necessidade. Identifique, para cada necessidade, soluções alternativas possíveis que teriam um impacto menor nas equipes de desenvolvimento.

Usando essas informações, formule uma lista priorizada que coloque em primeiro lugar as necessidades que causarão maior impacto no esforço de teste caso não sejam atendidas e que não possuem solução alternativa. Faça isso não desperdiçar valiosos recursos de desenvolvimento em necessidades de testabilidade menos essenciais, reservando essa oportunidade para as necessidades realmente importantes.

Ao solicitar que a equipe de desenvolvimento desenvolva um software com provisão específica para o esforço de teste, você estará acrescentando requisitos e restrições adicionais ao esforço de desenvolvimento; isso resume-se basicamente em mais trabalho, além de risco e complexidade adicionais para a equipe de desenvolvimento. Algumas equipes de desenvolvimento considerarão o design de testabilidade como fora do escopo de sua responsabilidade. Em outros casos, as necessidades de testabilidade deverão competir pelos recursos de desenvolvimento com as necessidade e os requisitos do cliente que normalmente recebem mais prioridade. Dessa forma, você precisa "vender" os benefícios das necessidades de possibilidade de teste para o coordenador de projeto, o arquiteto de software e outros investidores da equipe de desenvolvimento.

Formule uma análise dos benefícios de cada necessidade de testabilidade para a qual você deseja obter um compromisso. Procure artigos de pesquisa e estudos que suportem a importância de sua necessidade de testabilidade e utilize estatísticas sobre o retorno de investimento quando ela estiverem disponíveis. Pense nos benefícios em termos de importância para a equipe de desenvolvimento; que informações úteis de avaliação você poderá fornecer a eles que não poderiam ser fornecidas se essa necessidade não fosse atendida? Como isso facilitaria ou tornaria mais eficaz que você fornecesse um feedback à equipe de desenvolvimento oportuno, preciso, detalhado ou útil durante cada ciclo de build? Essa necessidade fornecerá uma característica útil à equipe de desenvolvimento que poderá ser usada em seu próprio esforço de teste ou em diagnósticos futuros de falhas do software? No caso de disputa com as necessidades do cliente, pense em maneiras de demonstrar que uma solução antecipada para a necessidade de testabilidade trará oportunidades adicionais para que os requisitos do cliente sejam suportados em ciclos de build subseqüentes.

Considerando que você estará impondo um possível trabalho ou risco adicional à equipe de desenvolvimento, identifique e conheça os investidores influentes com capacidade para aprovar ou ordenar o suporte da testabilidade. Faça isso o mais rápido possível, antes de promover ativamente as necessidades de testabilidade que deseja que sejam suportadas.

Os três investidores mais importantes são o arquiteto de software, o gerente de projeto e o representante do cliente. Passe algum tempo com o arquiteto de software e mostre a importância de se criar uma arquitetura de software que suporte a testabilidade. Passe algum tempo com o gerente de projeto e mostre os benefícios da testabilidade em termos de produtividade da equipe de teste e um rápido tempo de resposta às informações de avaliação. Mostre ao cliente a importância de liberar um produto de qualidade.

É importante promover as necessidades da testabilidade na direção certa. Cada combinação de gerente de projeto, equipe de desenvolvimento e investidores do lado do cliente possui uma dinâmica social e cultura diferentes; é importante que você esteja ciente disso quando promover as necessidades de testabilidade. Como heurística geral, não monte uma "campanha" de possibilidade de teste formal se a equipe for relativamente relaxada e informal, nem utilize uma abordagem informal em um projeto de alta formalidade.

Em alguns casos, uma sessão colaborativa de troca de idéias é um formato de apresentação útil, em que a necessidade é apresentada como um desafio para a equipe de desenvolvimento, que é aconselhada a identificar soluções criativas para atender à(s) necessidade(s) de possibilidade de teste. Isso estimula sua propriedade da solução e gera uma sensação de parceria no esforço.

O tempo também é importante neste passo. Como regra geral, tente identificar e promover as questões de testabilidade mais importantes o quanto antes, em geral, durante a Elaboração, e, quando for possível, na Fase de Iniciação. Quando questões de testabilidade são levantadas nos estágios iniciais do projeto, a equipe normalmente é menor e mais receptiva a mudanças. Também é mais fácil incluir essas necessidades no design em desenvolvimento já que geralmente um retrabalho mínimo é necessário.

Uma boa chance de identificar as necessidades de possibilidade de teste e apresentá-las de uma forma positiva e menos "oficial" é quando a equipe de teste oferece seus serviços de avaliação das atividades de prova de conceito e de avaliação da seleção de componentes de terceiros para uso no esforço de desenvolvimento. Especificamente, o envolvimento das equipes de testes durante a seleção de componentes de banco de dados, seleção de componentes ou controle de UI, seleção de componentes de middleware etc. significa que as questões de testabilidade podem ser usadas como um aspecto dos critérios de seleção de componentes. Por exemplo, em muitos casos, as equipes de desenvolvimento terão uma preocupação mínima sobre qual biblioteca de widgets de UI utilizar; se uma biblioteca for mais testável que outra, a equipe de desenvolvimento ficará feliz em selecionar a biblioteca de widgets mais testável.

Se já tiver tido problemas para identificar ou conhecer os campeões de testabilidade, você talvez precisará considerar uma abordagem que apresente as mudanças de uma forma mais incremental, tornando-as possivelmente menos arriscadas e distribuindo-as em blocos menores de esforço, ou talvez precisará escalar as necessidades de testabilidade mais importantes como questões críticas do projeto que impedem que o esforço de teste seja bem-sucedido até que elas sejam resolvidas. No segundo caso, recomenda-se que você considere cuidadosamente todas as suas opções antes de decidir adotar essa medida.

É importante assegurar que as necessidades de testabilidade sejam consideradas da mesma maneira que qualquer outro requisito ou restrição imposta ao esforço de desenvolvimento. Você precisa receber uma confirmação de que as características de testabilidade disponibilizadas hoje não serão abandonadas amanhã.

Em alguns casos, tentar obter esse compromisso poderá resultar na recusa da equipe de desenvolvimento em desenvolver ou suportar as necessidades de testabilidade. Embora isso possa ser desestimulante, é melhor estar ciente dessa situação e lidar com a realidade o quanto antes do que perder um tempo enorme e desperdiçar esforço desenvolvendo uma implementação de teste que não será mais suportada pela equipe de desenvolvimento.

Embora a equipe de desenvolvimento possa concordar em fornecer o suporte necessário para as necessidades de testabilidade do esforço de teste, é importante que você tenha um interesse ativo no design, na implementação e na conclusão desse trabalho. Não abandone simplesmente o trabalho só porque a equipe de desenvolvimento concordou em lidar com as necessidades de testabilidade ou começou a trabalhar em uma solução; você precisa garantir que uma solução apropriada será desenvolvida no momento oportuno.

Coloque a si mesmo e os outros membros da equipe de teste à disposição para responder às perguntas das equipes de desenvolvimento e se ofereça para avaliar os protótipos assim que eles forem construídos. Ofereça um feedback construtivo e demonstre entusiasmo pelo esforço da equipe de desenvolvimento em ajudá-lo a atender às suas necessidades. Ofereça os principais membros de sua equipe para promoverem ou participarem de workshops de design para as necessidades de testabilidade mais complexas, mas tome cuidado para que sua equipe não acabe se tornando autoritária e controlando o espaço de solução do processo de design para os desenvolvedores.

Quando surgirem problemas e você sentir que eles não estão recebendo a devida atenção ou sendo resolvidos com a rapidez necessária, compartilhe suas preocupações com o arquiteto de software e o gerente de projeto. Peça que o gerente de projeto registre um problema na lista problemas do projeto se for apropriado.

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.