Examine o plano de iteração e identifique o escopo e os objetivos do plano.

É útil complementar esse exame iniciando discussões informais com a equipe principal do projeto, como o gerente de projeto, o arquiteto de software e o representante do cliente. Essas reuniões geralmente enfatizam as preocupações de forma mais explícita do que o documentado no plano. As reuniões de início de iteração também fornecem informações úteis.

A missão é o carro-chefe que conduz o esforço de teste durante um período específico. Os recursos de teste são geralmente limitados e, portanto, o desafio será balancear determinadas restrições de recurso de teste com as necessidades de validação de qualidade do esforço de desenvolvimento de software.

Busque uma compreensão inicial, em um nível estratégico, das expectativas da equipe de desenvolvimento de software. Você deve estar principalmente preocupado com as expectativas do gerente de projeto, do arquiteto de software e dos analistas de sistema líderes.

Não é uma prática extremamente útil considerar os objetivos e o escopo separados do restante da equipe de projeto. O RUP defende a propriedade de qualidade de produto da equipe e, sendo assim, você deve incluir investidores relevantes da equipe de projeto ao decidir qual teste é importante. Você deve considerar os membros da equipe que desempenham as funções a seguir como investidores importantes: Coordenador de Projeto, Arquiteto, Analista de Sistemas, Integrador.

Em alguns casos, o formato da apresentação adequado será o formal, com os investidores reunindo-se como uma junta consultiva e fazendo uma boa preparação antes. Em outros casos, almoços de negócios, ou entrevistas individuais com cada investidor, podem ser apropriados. Há pontos positivos e negativos para cada abordagem: escolha o formato que melhor se ajuste às suas necessidades do ambiente de projeto atual.

As declarações de missão são úteis ao enfocar uma equipe, especialmente em situações em que a equipe se depara com várias opções possíveis. As equipes de teste sem uma Missão de Avaliação geralmente consideram que apenas "realizam testes": isso permite pouca orientação quando é necessário fazer escolhas difíceis quanto ao melhor foco de teste dentro das restrições de tempo e recursos. Uma declaração de missão extrai a essência do objetivo de trabalho atual e fornece um "mantra" para manter a equipe concentrada nas tarefas certas.

Formule uma declaração de missão que possa ser usada pela equipe de teste. Não torne isso muito complexo nem incorpore muitas idéias conflitantes: As melhores instruções de missão são simples, breves e fáceis e, na maioria das situações em que uma decisão precisar ser tomada entre as opções possíveis, a missão deixará bem clara a escolha a ser feita pela equipe.

Aqui estão algumas idéias de declarações de missão que você poderia adotar em uma determinada iteração:

• localizar o máximo de erros possível
• localizar problemas importantes com rapidez
• avaliar os riscos de qualidade percebidos
• advertir sobre os riscos de projeto percebidos
• advertir sobre a qualidade percebida
• certificar um padrão
• verificar uma especificação (requisitos, design ou reclamações de produto)
• satisfazer investidores
• cumprir as determinações do processo

Observando essa lista, você deve ter imaginado que várias missões são mutuamente exclusivas. Por exemplo, se a minha missão for "localizar problemas importantes rapidamente", provavelmente não seria possível "verificar uma especificação": Para realizar com êxito uma missão, muitas vezes é necessário negar outras missões possíveis e exige uma abordagem de teste de suporte diferente.

As equipes de teste que tentam atender a várias missões de avaliação geralmente têm dificuldades ao se depararem com conflitos contínuos em seu trabalho. Observe também que recomendamos escolher ou reconsiderar a Missão de Avaliação em cada iteração: é natural que a missão seja alterada ao longo do tempo com base no contexto do esforço de trabalho atual.

Certos produtos de trabalho são distribuíveis importantes para um ou mais investidores: outros produtos de trabalho são partes necessárias do esforço de teste e, embora sejam importantes para a equipe de teste, são de pouco interesse para esses mesmos investidores.

Reflita um pouco sobre o conjunto mínimo de produtos liberados úteis no esforço de teste. Não liste todos os produtos de trabalho, mas somente aqueles que oferecem benefícios diretos e tangíveis a um investidor e aqueles através dos quais o sucesso do esforço de teste será avaliado. Talvez seja necessário adaptar essa lista inicial para acomodar as necessidades dos investidores, mas você precisará desempenhar uma função pró-ativa, estimulando os produtos liberados a se manterem úteis e gerenciáveis.

Mais uma vez, reflita sobre o formato apropriado para apresentar a missão e conseguir as aprovações necessárias. Escolha o formato que melhor se adeqüe às suas necessidades no contexto do ambiente de projeto atual.

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.