Comece examinando os sumários de avaliação de testes que a equipe de teste preparou. Compare as informações de avaliação com o Plano de Teste da iteração, a fim de compreender o sumário no contexto do trabalho planejado. Discuta quaisquer ambigüidades e preocupações com os membros da equipe de teste que preparam o sumário e resolva-as.

Neste passo e nos passos subseqüentes referentes à coleta de informações e à avaliação da qualidade do software, tente obter uma visão balanceada incorporando medidas objetivas e subjetivas. Lembre-se de que os números 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 a qualidade do software: 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.

Com base nos sumários de avaliação de testes, examine os resultados de teste selecionados em busca de contexto adicional. Pesquise os resultados até ter a certeza de que compreende as questões importantes que foram identificadas nos sumários de avaliação de testes.

Além disso, revise os dados e procure as tendências importantes evidentes nos dados dos resultados de teste que possam estar ausentes. Em geral, é mais importante identificar o que as tendências relativas dos dados estão indicando do que observar números absolutos. Fique atento a indicações como falhas em áreas que estejam relacionadas a falhas de outras áreas.

Recomendamos que você limite este exercício às questões mais urgentes e às solicitações de mudança associadas. Você será capaz de dedicar mais atenção a um menor número de questões e, em geral, há uma probabilidade maior de elas exercerem o maior impacto sobre a qualidade do produto. Se você tiver uma lista maior de problemas-chave, recomendamos dedicar esforço apropriado a eles com base na prioridade relativa: não desperdice seus recursos com um problema menos significativo. No entanto, observe que um número significativo de Solicitações de Mudança pendentes de baixa prioridade pode tornar uma declaração sobre a qualidade dos produtos tão importante quanto as poucas mudanças de prioridade alta. Tente agrupar as Solicitações de Mudança de baixa prioridade em aspectos lógicos de qualidade, com base nos riscos de qualidade que elas representam. Isso o ajudará a articular e defender o efeito combinado sobre a qualidade de modo mais claro.

Identifique as tendências importantes que aparecem nos dados gerais de Controle de Mudanças. Em geral, é mais importante identificar o que as tendências relativas dos dados estão indicando do que observar números absolutos. Procure pontos positivos, como uma taxa contínua estável de resolução de defeitos ou um aumento contínuo gradativo e uma diminuição subseqüente da taxa de resolução, no decorrer do tempo. Fique atento a picos e baixas na taxa de resolução que indiquem que a equipe de desenvolvimento pode estar prestes a se deparar com problemas processuais, ambientais, políticos etc. que reduzirão a produtividade.

Nota: você também poderá aproveitar a oportunidade para aprimorar a clareza dos Controles de Mudanças associados, eliminando a ambigüidade e a linguagem e argumentação emotivas. Se você mesmo fizer essas alterações, discuta as melhorias obtidas com as pessoas que criaram esses produtos de trabalho, para que elas possam compreender por que as melhorias são importantes.

Identifique cada brecha de qualidade e avalie o impacto e o risco associados de cada problema que está gerando essa brecha. Considere as estratégias de diminuição e contingência, formule suas idéias iniciais sobre essas estratégias e discuta-as com outros membros da equipe.

Considere que a qualidade "perfeita" é comprovadamente um conceito um tanto imaginário. Tenha cuidado ao utilizar uma "barra de qualidade" realista e alcançável ao avaliar a qualidade e identificar as falhas de qualidade. Consulte Técnica: Qualidade do Produto

Para cada brecha de qualidade importante, considere as possíveis estratégias de diminuição e contingência. Formule suas idéias iniciais sobre essa estratégia e discuta-as informalmente com outros membros da equipe para ter uma visão maior e validar seus pensamentos. No caso de soluções, é bom ter opções: elas ajudam a ponderar as compensações e adotar a melhor solução para um determinado contexto.

Trabalhe com um conjunto de possíveis soluções e sugestões úteis que auxiliará a equipe do projeto a lidar adequadamente com cada brecha de qualidade. É importante fazer isso para que o esforço de teste seja reconhecido como uma contribuição útil para a resolução de problemas: não simplesmente um relato de problemas. Esse é um aspecto importante, que defende o valor da equipe de teste e conquista o respeito e a cooperação dos outros membros da equipe.

Não é nada engraçado apoiar uma causa perdida. Geralmente, a abordagem mais eficaz é identificar soluções para problemas em que há mais probabilidade de a equipe do projeto apoiar, aceitar e se comprometer. Mantenha um relacionamento estreito com os principais tomadores de decisão e comece tornando esses problemas-chave informalmente visíveis através de uma discussão bidirecional. Muitas vezes, essa será uma excelente maneira de conquistar apoio e chegar a soluções possíveis.

Haverá ocasiões em que você não terá escolha, a não ser adotar uma solução que não é muito bem aceita pela equipe de desenvolvimento. Quando possível, será até mesmo mais importante saber quem pode lhe dar apoio e encontrar formas de vender a solução que apresente seu valor da maneira mais clara possível ou expor claramente a terrível conseqüência da não resolução do problema.

Esse é o ponto crucial de proteção da qualidade: ser capaz de negociar uma solução adequada que satisfaça a equipe de desenvolvimento e não reduza significativamente a qualidade do produto. Lembre-se de que, na maioria dos casos, a equipe de teste é basicamente um conselheiro de qualidade. Portanto, você deve ter cuidado para não exigir que uma determinada resolução seja executada.

Entretanto, é importante que a equipe de teste faça um bom trabalho como advogada da qualidade, o que implica, algumas vezes, ser portadora de notícias que a equipe do projeto não gosta de ouvir. É aqui que equipes de teste eficientes fornecem o esforço de desenvolvimento com o máximo de discernimento do problema, de suas possíveis soluções e com o máximo de compreensão das alternativas para cada opção, conforme possível. Você deve atuar, de certa forma, como um agente dos eventuais clientes do produto e ajudar a negociar as soluções que serão de maior interesse para eles.

Às vezes, os defeitos e outras solicitações de mudança se perdem no processo de desenvolvimento contínuo básico do produto e no processo de expansão das características. Isso acontece, em parte, porque é mais atrativo para os desenvolvedores trabalhar com "material novo" do que corrigir um código antigo e cheio de erros e, em parte, porque o valor do negócio pode ser mais obviamente manifestado na inclusão de algo novo do que na correção de algo interrompido. Como advogados da qualidade, a equipe de teste precisa ajudar o projeto a ver consertos de defeito importantes.

As equipes de software de sucesso encontram um bom equilíbrio entre a melhoria incremental da qualidade através da resolução de defeitos e a expansão incremental das características. A equipe de teste pode auxiliar a equipe de projeto encontrando maneiras de motivar e suportar o aprimoramento de qualidade incremental, em vez de adotar uma função menos útil e mais controversa da "política de qualidade".

Seja qual for a solução adotada pela equipe de desenvolvimento para resolver um problema de qualidade, a resolução deve melhorar finalmente a qualidade. Certifique-se de que avaliou a melhoria na qualidade após uma determinada resolução e que essa resolução não exerce nenhum impacto prejudicial na qualidade de outras maneiras.

No caso de soluções que oferecem algum nível de risco, talvez seja útil executar alguns testes em um possível release inicial antes de despender muito tempo e esforço para concluir a resolução.

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.