Existem várias maneiras de abordar esse passo. Grande parte da abordagem dependerá da cultura do projeto. Quando disponível, colete e agrupe os relatórios de andamento preparados pelos membros da equipe ou pelas subequipes. As agendas do projeto são outra fonte possível a ser considerada. Quando sistemas de agendamento de projetos como o Microsoft Project são ativamente utilizados e atualizados com o andamento real, isso fornece uma outra fonte útil de informações. Quando disponíveis e ativamente utilizadas, você poderia também derivar as métricas objetivas de status e andamento a partir dos sistemas de gerenciamento de mudança e configuração.

Neste passo e nos passos subseqüentes referentes à coleta de informações e à avaliação do esforço de teste, tente obter uma visão balanceada incorporando medidas objetivas e subjetivas. Lembre-se de que os números de objetivos oferecem apenas parte do panorama e precisam ser suportados e explicados pelo "clima" do projeto atual. Por outro lado, não confie simplesmente em boatos e especulações subjetivas sobre o esforço do teste: procure evidência objetiva de suporte. Recomendamos que você complemente os dados objetivos através de discussões com os líderes de equipe ou, quando possível, com cada membro da equipe, a fim de reunir avaliações subjetivas e estimar até que ponto pode confiar nos dados objetivos.

Investigue o grau de esforço despendido na identificação, definição, design, implementação e execução dos testes. Fique atento a indícios de que esteja dedicando esforço excessivo para um único aspecto do esforço de teste em detrimento de outros. Observe também as áreas em que o esforço pode ser improdutivo ou não mostre benefícios suficientes, tendo em vista o nível de esforço que está sendo despendido.

Verifique a eficácia do teste. Procure dados que respaldem suas observações iniciais sobre a eficácia. Considere aspectos como taxa de descoberta de defeitos, contagens de gravidade de defeitos, estatísticas de defeitos duplicados e defeitos detectados como escapes de teste.

Identifique tendências importantes que aparecem nos dados da Solicitação de Mudança. Em geral, é menos importante para essa tarefa perder tempo analisando volumes de dados e é mais importante identificar o que as tendências de dados relativas estão indicando. Procure pontos positivos, como uma taxa contínua estável de descoberta de defeitos, ou um leve aumento ou diminuição contínua na taxa de descoberta, no decorrer do tempo. Fique atento a picos e baixas na taxa de descoberta que indiquem que a equipe de teste pode estar prestes a se deparar com problemas processuais, ambientais, políticos etc. que reduzirão a produtividade.

Observe as tendências em fechamentos de defeito. Procure aumentos significativos de fechamentos pela equipe de desenvolvimento como "não reproduzíveis", identifique os casos em que esse é um resultado da análise insuficiente do defeito que está sendo desempenhada pela equipe de teste e quantifique a extensão desse problema. Examine as tendências em defeitos que estão sendo fechados pela equipe de desenvolvimento como "funcionando conforme projetado", identifique casos em que esse é um resultado da análise insuficiente da especificação que está sendo desempenhada pela equipe de teste e quantifique a extensão desse problema. Tenha cuidado para confirmar que essas indicações não são falsas e acontecem graças aos desenvolvedores sobrecarregados, quando decidem examinar minuciosamente sua carga de trabalho. Uma análise de tendências de verificação de defeito também deve ser feita à medida que correções para os defeitos são liberadas para a equipe de teste em construções subseqüentes: procure tendências que indiquem que os defeitos que estão aguardando verificação pela equipe de teste estão vencendo ou chegando a um número não gerenciável.

Procure outras tendências que indicam problemas. Observe o modo no qual os defeitos e outros controles de mudanças foram registrados ou gerenciados pela equipe de teste: informações ambíguas e insuficientes em um controle de mudanças são difíceis e frustrantes para um desenvolvedor executar uma ação. A equipe deve ter cuidado para monitorar se a qualidade das informações registradas sobre os defeitos permanece, na média, relativamente alta. Aproveite a oportunidade para melhorar a clareza das Solicitações de Mudança associadas, eliminando a ambigüidade e a linguagem e argumentação emotivas. Trabalhe junto com as pessoas que criaram esses produtos de trabalho para garantir que a essência do problema esteja claramente especificada e para incentivar essas pessoas encontrar maneiras concretas e precisas de abordar a discussão dos Problemas.

Além disso, procure desequilíbrios na distribuição de defeitos em várias dimensões diferentes. Procure áreas funcionais do aplicativo ou da especificação que apresentem contagens baixas de defeitos: isso pode indicar um situação em que teste insuficiente foi realizado nessa área funcional. Observe também a distribuição por membro da equipe de teste: pode haver indicações de que membros individuais da equipe estejam sobrecarregados e que isso está afetando a produtividade.

Analise o estado dos relacionamentos de rastreabilidade entre os recursos de teste, Idéias de Teste, Casos de Teste, Scripts de Teste, Conjuntos de Testes e Controles de Mudanças, e os recursos de envio de dados e de recebimento de dados aos quais estão relacionados. Procure indícios que indiquem que o esforço de teste enfoca as áreas corretas e um conjunto útil de motivações. Observe também indicações negativas que sugiram que determinados aspectos de teste estão ausentes ou não são mais importantes: Se os requisitos ou as equipes de desenvolvimento estiverem trabalhando em áreas não representadas pelo esforço de teste atual, haverá essa preocupação.

Agrupe todas informações que você coletou e avalie-as como um todo. Lembre-se de que cada parte dos dados coletados abrange somente um aspecto da avaliação total e que você deve formular a avaliação do esforço de teste com base em uma visão balanceada e ponderada de todos os dados.

Registre a avaliação inicial em um formato adequado para que os investidores façam comentários e dêem seu feedback.

Esta tarefa produz informações de status resumidas que são importantes para o coordenador de projeto e outras funções na equipe de gerenciamento. Esses papéis usarão as descobertas resumidas para tomar decisões sobre o projeto com base nessas informações.

Recomendamos que você registre alguns aspectos da avaliação do esforço de teste em um formato que permita a comparação das avaliações subseqüentes com as anteriores. Isso permitirá que você analise a tendência relativa nas melhorias do esforço de teste no decorrer do tempo.

Apresente sua avaliação aos investidores para que eles façam comentários e dêem feedback. O formato ou método para fazer isso difere de um projeto para outro: em alguns casos, será uma série de conversas informais, em um outro, será simplesmente uma divulgação em um Web site da intranet do projeto e, em outros, uma apresentação formal; escolha um formato que se ajuste à sua cultura.

Mesmo com os melhores documentos de especificação e planejamento possível, haverá geralmente diferenças entre a expectativa original e a intenção desses documentos e o produto final resultante. Isso se aplica tanto ao software de teste e de avaliação como ao próprio desenvolvimento de software. O valor deste passo é aproveitar a oportunidade para solicitar o feedback dos investidores e identificar em que ponto o planejamento e a documentação falharam ao realizar o que se esperava inicialmente.

Com base na sua análise e no feedback que você recebeu dos vários investidores, identifique as oportunidades de melhoria. Busque maneiras de tornar o teste mais eficaz e produtivo. Isso poderia envolver: redesignar equipe, incluir duas equipes iguais para que o trabalho seja mais eficiente ou empregar contratantes especializados; utilizar ferramentas de produtividade para aprimorar a eficácia; localizar abordagens e técnicas alternativas que sejam mais produtivas em termos de localização de defeitos.

Na maioria dos casos, é melhor fazer aprimoramentos pequenos e incrementais no esforço de teste e evitar o risco de desviar o projeto com grandes mudanças desordenadas: Em alguns casos, uma alteração maior é permitida e útil. Use o bom senso para formular uma abordagem apropriada para as melhorias e discuta suas idéias com outra equipe de gerenciamento para obter colaboração, antes de envolver a equipe em mudanças grandes.

Para que as melhorias sejam eficazes, você precisará gerenciar seu sucesso. Identifique maneiras em que será possível monitorar as iniciativas de aprimoramento, de preferência antes de adotá-las, para avaliar sua eficácia. Monitore ativamente o andamento da adoção das mudanças; faça isso você mesmo ou indique alguém da equipe.

A maioria das mudanças encontra resistência ou problemas que devem ser superados para que elas sejam bem-sucedidas. Reserve um tempo para resolver quaisquer problemas que surjam e impeçam o sucesso da iniciativa, e esteja preparado para fazer isso rapidamente. Esteja atento a pessoas naturalmente relutantes a mudanças e encontre formas de lidar com suas preocupações adequadamente.

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.