Reveja o Plano de Iteração e identifique as necessidades de avaliação específicas para este próximo corpo de trabalho. Pergunte aos investidores o que eles esperam da avaliação e da rastreabilidade.

Considere também se o esforço de teste passará formalmente por auditoria durante o esforço de teste ou na conclusão do esforço. Requisitos formais de auditoria podem necessitar da retenção de documentação e registros adicionais como prova de que testes suficientes foram realizados.

Embora haja normalmente uma lista infinita de necessidades que possam ser consideradas como requisitos para estratégias de rastreabilidade e avaliação, é importante manter o foco nas necessidades mais importantes que a) Forneçam informações essenciais à equipe do projeto e que b) Possam ser realmente rastreadas e medidas. É improvável que haja recursos suficientes disponíveis para sua estratégia, permitindo oferecer mais do que o basicamente necessário.

Subtópicos:

• Nível de Qualidade Aceitável
• Ativação do Processo e das Ferramentas

Nível de Qualidade Aceitável

É importante identificar qual nível de qualidade será considerado "suficientemente bom" e desenvolver uma estratégia de avaliação apropriada. Observe que freqüentemente as dimensões de qualidade oscilam em termos de importância e os níveis de qualidade aumentam e diminuem, conforme o ponto de vista dos investidores, durante todo o ciclo de vida do projeto.

Revise o Plano de QA, revise o Plano de Desenvolvimento de Software e entreviste diretamente os principais investidores para determinar o que eles consideram um nível de qualidade aceitável.

Ativação do Processo e das Ferramentas

Embora você provavelmente possa considerar inútil as abordagens de rastreabilidade e avaliação em um nível baixo de granularidade, a realidade é que é difícil e normalmente caro implementar essas abordagens. Com um suporte de ferramenta sofisticado, ainda poderá ser difícil e demorado gerenciar abordagens de rastreabilidade de nível baixo; sem as ferramentas de suporte, isso será praticamente impossível. O próprio processo de engenharia de software pode colocar restrições sobre rastreabilidade: por exemplo, se for desejável a rastreabilidade de testes para requisitos de motivação, mas os próprios requisitos não estiverem sendo cuidadosamente gerenciados, pode ser impossível implementar essa rastreabilidade.

Considere as restrições e limitações das ferramentas e de seu processo de engenharia de software e escolha uma abordagem de rastreabilidade e avaliação apropriada que seja viável.

Agora que você já possui uma noção mais aprofundada dos requisitos de avaliação e rastreabilidade e das restrições impostas a esses requisitos pelo nível de qualidade desejado e pelo suporte disponível às ferramentas e ao processo, considere as possíveis estratégias de avaliação a serem empregadas. Para obter um tratamento mais detalhado das possíveis estratégias, sugerimos a leitura do documento "Measurement of the Extent of Testing", de Cem Kaner, publicado em outubro de 2000. (Obter o Adobe Reader)

Subtópicos:

• Análise da Cobertura de Teste
• Análise do Resultado de Teste
• Análise de Defeitos

Análise da Cobertura de Teste

Há várias abordagens diferentes para a cobertura de teste, porém, nenhuma medida de cobertura sozinha fornece todas as informações de cobertura necessárias para formar uma avaliação da extensão ou da abrangência do esforço de teste. Observe que diferentes estratégias de cobertura exigem mais ou menos esforço para serem implementadas e, com qualquer categoria de métrica específica, normalmente será possível obter uma análise de cobertura aprofundada que, depois desse ponto, encarecerá o registro de informações mais detalhadas.

Algumas categorias de medida de cobertura de teste incluem: Requisitos, Código Fonte, Reivindicações de Produtos e Padrões. Recomenda-se que você considere a incorporação de mais de uma categoria de cobertura em sua estratégia de avaliação de teste. Na maioria dos casos, a cobertura de teste refere-se ao planejamento e à implementação de testes específicos na primeira instância. Entretanto, as métricas de cobertura de teste e sua análise também convêm serem consideradas junto com a análise de defeitos ou a análise de resultados de teste.

Análise dos Resultados de Teste

Uma abordagem comum para a análise dos resultados de teste é apenas se referir ao número de resultados positivos ou negativos como uma porcentagem do número total de testes executados. Nossa opinião, e opinião também de outro praticante da comunidade de teste, é que esta é uma abordagem simplista e incompleta para a análise dos resultados de teste.

Em vez disso, recomenda-se analisar os resultados de teste em termos de tendência relativa ao longo do tempo. Dentro de cada ciclo de teste, considere a distribuição relativa de defeitos de teste em diferentes dimensões, como a área funcional que está sendo testada, o tipo de riscos de qualidade que estão sendo explorados, a complexidade relativa dos testes e os recursos de teste aplicados a cada área funcional.

Análise de Defeitos

Embora os defeitos estejam obviamente relacionados aos resultados do esforço de teste, a análise dos dados de defeito não fornecem informações úteis sobre o andamento do esforço de teste ou sobre a abrangência desse esforço. Entretanto, um erro cometido por algumas equipes de teste e gerentes de projeto é usar a contagem de defeitos atual para medir o andamento do teste ou como medida padrão da qualidade do software desenvolvido. Nossa opinião, e opinião também de outro praticante da comunidade de teste, é que essa é uma abordagem sem sentido.

Recomenda-se que, em vez disso, você analise a tendência relativa da contagem de defeitos ao longo do tempo para fornecer uma medida de estabilidade relativa. Por exemplo, pressupondo que o esforço de teste permaneça relativamente constante, você normalmente esperaria ver a nova taxa de descoberta de defeitos medida com base em um período de tempo regular como uma curva normal durante o curso da iteração; uma taxa de descoberta crescente que fosse aumentando e, em seguida, diminuindo no final da iteração. No entanto, você precisará fornecer essas informações juntamente com uma análise de outras métricas de defeito, como: taxas de resoluções de defeitos, incluindo uma análise do tipo de resolução; distribuição de defeitos por gravidade; distribuição de defeitos por área funcional.

Com um suporte de ferramenta sofisticado, é possível realizar uma análise complexa dos dados de defeito de modo relativamente simples; sem o suporte de ferramenta apropriado, essa proposição torna-se muito mais difícil.

Apresente as possíveis estratégias aos diversos investidores. Normalmente espera-se que isso inclua um grupo composto das funções a seguir; Gerente de Projeto, Arquiteto de Software, Gerente de Desenvolvimento, Analista de Sistemas, Gerente de Configuração e Mudanças, Gerente de Implementação e Representante do Cliente. Cada um desses papéis possui um envolvimento no modo de avaliação da qualidade.

Dependendo da cultura do projeto, escolha um formato apropriado para apresentar as possíveis estratégias. Isso pode variar de uma ou mais reuniões informais até uma apresentação formal ou sessão de workshop.

Use o feedback obtido nas discussões e refine a estratégia de avaliação para uma única estratégia que atenda às necessidades de todos os investidores.

Apresente a estratégia de avaliação para uma aprovação final.

Conforme mencionado anteriormente, com um suporte de ferramenta sofisticado, é possível realizar uma análise complexa dos dados de métrica de modo relativamente simples; sem o suporte de ferramenta apropriado, essa proposição torna-se muito mais difícil.

Para as categorias a seguir, considere qual suporte de ferramenta será necessário: Cobertura e Rastreabilidade, Análise de Defeito.

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, use as listas de verificação fornecidas no RUP para verificar se a qualidade e a integridade sã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 iterativo 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.