Nesta tarefa, os Logs de Teste são analisados para determinar os Resultados de Teste significativos em relação às diferenças entre os resultados esperados e os resultados reais de cada teste. Identifique e analise cada incidente e falha sucessivamente. Aprenda o máximo que puder sobre cada ocorrência.

Procure por incidentes duplicados, sintomas comuns e outros relacionamentos entre os incidentes. Essas condições normalmente permitem um insight valioso sobre a causa original de um grupo de incidentes.

As diferenças indicam possíveis defeitos nos Itens de Objetivo do Teste e devem ser inseridos em um sistema de controle como incidentes ou Solicitações de Mudança, contendo uma indicação das ações corretivas apropriadas a serem tomadas.

Subtópicos:

• Verificar fatos do incidente
• Esclarecer detalhes do Controle de Mudanças
• Indicar a gravidade relativa do impacto e a prioridade de resolução
• Registrar Controles de Mudanças adicionais separadamente

Verificar Fatos do Incidente

Verificar se há dados precisos de suporte disponíveis. Agrupe os dados para anexação diretamente no Controle de Mudanças ou indique onde esses dados podem ser obtidos separadamente.

Sempre que possível, verifique se o problema é reproduzível. Os problemas reproduzíveis têm muito mais probabilidade de receberem a atenção do desenvolvedor e serem corrigidos subseqüentemente; um problema que não pode ser reproduzido tanto frustra a equipe de desenvolvimento quanto desperdiça recursos valiosos de programação em uma pesquisa inútil. Recomenda-se que você continue registrando esses incidentes, mas tenha o cuidado de identificar os incidentes irreproduzíveis separados dos reproduzíveis.

Esclarecer Detalhes do Controle de Mudanças

É importante que as Solicitações de Mudança possam ser entendidas, principalmente o título. Verifique se o título está claro e conciso, expressando claramente a questão específica. Um título breve é útil para listagens resumidas de defeitos e discussões em reuniões de status CCB.

É importante que a descrição detalhada do Controle de Mudanças não seja ambígua e possa ser facilmente interpretada. Convém registrar seus Controles de Mudanças o mais rápido possível, mas separe um tempo para voltar neles, a fim de melhorar e expandir as descrições antes que elas sejam visualizadas pela equipe de desenvolvimento.

Forneça o maior número de sugestões de solução possíveis. Isso ajudará a reduzir qualquer ambigüidade que ainda exista na descrição e normalmente ajuda a esclarecer. Também aumenta a probabilidade de que seja encontrada uma solução mais de acordo com suas expectativas. Além disso, mostra que a equipe de teste está preparada não só para localizar os problemas, mas também para ajudar a identificar as soluções apropriadas.

Outros detalhes que você deve incluir são capturas de imagens de tela, arquivos de Dados de Teste, Scripts de Teste automatizados, saída dos utilitários de diagnóstico e qualquer outra informação que possa ajudar os desenvolvedores a isolar e corrigir o erro subjacente.

Indicar a Gravidade Relativa do Impacto e a Prioridade de Resolução

Fornecer uma indicação para a equipe de gerenciamento e desenvolvimento sobre a gravidade do problema. Em equipes maiores, a determinação da prioridade de resolução real é responsabilidade da equipe de gerenciamento; entretanto, você pode permitir que as pessoas indiquem sua prioridade de resolução preferencial e ajustem subseqüentemente, conforme necessário. Como regra geral, recomenda-se que você atribua, por padrão, uma prioridade de resolução média para as Solicitações de Mudança, aumentando ou diminuindo essa prioridade em cada caso, conforme necessário.

Você talvez precise diferenciarentre o impacto do Controle de Mudanças, caso não tenha sido abordado, no ambiente de produção e no esforço de teste. É tão importante que a equipe de gerenciamento saiba quando um defeito está causando impacto no esforço de teste e quanto é importante estar ciente da gravidade para os usuários.

Algumas vezes, é difícil perceber antecipadamente por que os dois atributos são necessários. É possível que um incidente seja realmente grave, como uma pane do sistema, mas as ações necessárias para reproduzi-lo têm pouca probabilidade de ocorrer. Nesse caso, a equipe pode indicar essa gravidade como alta e uma prioridade de resolução muito baixa.

Registrar Controles de Mudanças Adicionais separadamente

Os incidentes geralmente revelam o velho provérbio "Onde há fumaça, há fogo"; ao identificar e registrar um Controle de Mudanças, você geralmente identifica outros problemas que precisam ser tratados. Evite a tentação de simplesmente incluir essas descobertas adicionais no Controle de Mudanças existente: se as informações estiverem diretamente relacionadas e ajudarem a resolver melhor o problema existente, então está OK. Se os outros problemas forem diferentes e você identificá-los em uma CR existente, eles poderão não ser processados, poderão não obter a prioridade apropriada a que têm direito ou poderão causar um impacto na velocidade de tratamento dos outros problemas.

Subtópicos:

• Distribuição de incidentes
• Cobertura de execução do teste
• Estatísticas de controle de mudanças

Distribuição de Incidentes

Analise os incidentes baseado em sua distribuição, por exemplo, área funcional, risco de qualidade, testador e desenvolvedor atribuídos.

Procure padrões na distribuição, como áreas funcionais que pareçam ter uma contagem de defeitos acima da média. Procure identificar se há desenvolvedores ou testadores que possam estar sobrecarregados e que estejam apresentando problemas de qualidade.

Cobertura de Execução do Teste

Para avaliar a cobertura de execução do teste, você precisa revisar os Logs de Teste e determinar:

• A relação entre a quantidade de testes (Scripts de Teste ou Casos de Teste) realizados neste Ciclo de Teste e o número total de testes para todos os Itens de Objetivo do Teste pretendidos.
• O número de casos de teste executados com êxito.

O objetivo é garantir que um número suficiente de testes destinados a este Ciclo de Teste tenham sido executados de forma proveitosa. Se isso não for possível ou para aumentar esses dados de execução, um mais critérios de cobertura de teste adicionais poderão ser identificados, com base em:

• Risco de Qualidade ou prioridade
• Cobertura baseada em especificações (Requisitos etc.)
• Prioridade ou necessidade de negócio
• Cobertura baseada em códigos

Consulte Conceito: Principais Medidas do Teste, Cobertura de Teste Baseada em Requisitos.

Registre e apresente os Resultados do Teste em um Relatório de Avaliação de Testes para este Ciclo de Teste.

Estatísticas de Controles de Mudanças

Para analisar defeitos, é necessário revisar e analisar as medidas escolhidas como parte da estratégia de análise de defeitos. As medidas de defeito mais comuns são as seguintes (geralmente exibidas em forma de gráfico):

• Densidade de Defeitos - o número de defeitos é mostrado como uma função de um ou dois atributos de defeitos (como distribuição por área funcional ou risco de qualidade comparado ao status ou à gravidade).
• Tendência a Defeitos - a contagem de defeitos é mostrada como uma função ao longo do tempo.
• Tempo de Permanência de Defeitos - um relatório especial de densidade de defeitos em que as contagens de defeitos são mostradas como uma função do período de tempo que um defeito permaneceu em um determinado status (aberto, novo, aguardando verificação etc.)

Compare as medidas deste Ciclo de Teste com os totais cumulativos da Iteração atual e com os da análise das iterações anteriores para compreender melhor as tendências emergentes ao longo do tempo.

Você deve apresentar os resultados na forma de diagrama com as descobertas feitas para justificar a solicitação.

Identifique e explique essas áreas que ainda não foram abordadas em termos de riscos de qualidade e indique qual o impacto e o perigo resultantes para a equipe.

Forneça uma indicação da prioridade de cada risco de qualidade iminente e use a prioridade para indicar a ordem de abordagem desses problemas.

Com base no trabalho na etapa cobertura de execução do teste, forneça uma breve instrução resumida do status e das informações representadas pelos dados.

Apresentar os Resultados do Teste para este Ciclo de Testes em um Sumário de Avaliação de Testes. Esta etapa é desenvolver o rascunho inicial do sumário. Realizado por meio da montagem das informações anteriores, reunidas em um relatório de sumário legível. Dependendo dos participantes e do contexto do projeto, o formato real e o conteúdo do sumário serão diferentes.

Normalmente, é uma boa idéia distribuir o rascunho inicial a um subconjunto de investidores para obter um feedback que possa ser incorporado antes de divulgar para um público maior.

Publique essas informações usando qualquer método apropriado. Recomenda-se que você divulgue-as em um site de projeto centralizado ou apresente-as nas freqüentes reuniões de avaliação de status para que seja possível reunir feedback e determinar as próximas ações.

Lembre-se de que disponibilizar publicamente os sumários de avaliação pode às vezes ser um problema político delicado. Negocie com o gerenciador de desenvolvimento para apresentar os resultados de uma maneira que eles reflitam um sumário honesto e preciso das suas descobertas, respeitando o trabalho dos desenvolvedores.

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.