Papéis e Atividades Conjunto de Papéis do Analista > 
Analista de Teste > > Determinar Resultados do Teste
Atividade:
| ||||||||||||||||||||||||||||||||||||||||
| Detalhamentos do Fluxo de Trabalho: |
| Finalidade: | Investigar cada incidente e obter uma noção detalhada dos problemas resultantes. |
Nesta atividade, 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.
| Finalidade: | Inserir informações de solicitação de mudança em uma ferramenta de controle para avaliação, gerenciamento e resolução. |
As diferenças indicam possíveis defeitos nos Itens de Teste-Alvo 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 se há dados precisos de suporte disponíveis. Agrupe os dados para anexação diretamente na Solicitação de Mudança 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.
É 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 curto é útil para listas de defeitos de sumário e discussões em reuniões de status CAB.
É importante que a descrição detalhada da Solicitação de Mudança não seja ambígua e possa ser facilmente interpretada. Convém registrar suas Solicitações de Mudança o mais rápido possível, mas separe um tempo para voltar nelas 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.
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 mostrar a diferença de impacto da Solicitação de Mudança, caso não seja abordado, no ambiente de produção e no esforço de teste. É importante que a equipe de gerenciamento saiba quando um defeito está causando impacto no esforço de teste e também esteja ciente da gravidade para os usuários finais.
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.
Os incidentes normalmente revelam o velho provérbio "Onde há fumaça, há fogo"; ao identificar e registrar uma Solicitação de Mudança, você provavelmente identifica outros problemas que precisam ser abordados. Evite cair na tentação de simplesmente incluir essas outras descobertas à Solicitação de Mudança existente; se as informações estiverem diretamente relacionadas e ajudarem a solucionar melhor o problema existente, não há problema. 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.
| Finalidade: | Calcular e fornecer as principais medidas e os indicadores do teste. |
Subtópicos:
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.
Para avaliar a cobertura de execução do teste, você precisa revisar os Logs de Teste e determinar:
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:
Consulte "Conceitos: Principais Medidas de 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.
Para analisar os defeitos, é necessário que você reveja e analise as medidas escolhidas como parte de sua estratégia de análise de defeitos. As diversas medidas de defeitos mais comuns usadas incluem as seguintes (normalmente exibidas na forma de gráfico):
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.
| Finalidade: | Fornecer feedback sobre a qualidade percebida ou experimentada em relação ao produto de software. |
| Finalidade: | Fornecer feedback sobre quais outras áreas de risco possivelmente colocam mais em perigo o projeto. |
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.
| Finalidade: | Fazer uma avaliação resumida da análise de cobertura do teste. |
Baseado no trabalho do passo cobertura de execução do teste, forneça uma declaração resumida do status e das informações representadas pelos dados.
| Finalidade: | Comunicar os resultados do teste aos envolvidos e fazer uma avaliação objetiva da qualidade e do status do teste. |
Apresentar os Resultados do Teste para este Ciclo de Testes em um Sumário de Avaliação de Testes. Este passo é 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 envolvidos para obter um feedback que possa ser incorporado antes de divulgar para um público maior.
| Finalidade: | Promover e divulgar o Sumário de Avaliação conforme apropriado. |
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 gerente 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.
| Finalidade: | Verificar se a atividade foi concluída corretamente e se os artefatos resultantes são aceitáveis. |
Agora que você concluiu o trabalho, convém verificar se ele foi proveitoso e garantir que você não apenas consumiu uma grande quantidade de papel. Avalie se a qualidade de seu trabalho é apropriada e se ele está completo o suficiente para ser útil aos membros da equipe que o utilizarão depois como entrada em seu próprio trabalho. Sempre que possível, use as listas de verificação fornecidas no RUP para verificar se a qualidade e a abrangência estão satisfatórias.
Faça com que as pessoas que executam as atividades subordinadas e que dependem de seu trabalho como input participem revisando o seu trabalho provisório. Faça isso enquanto ainda dispõe de tempo para executar algum tipo de ação em relação às questões levantadas por elas. Avalie também seu trabalho, comparando-o com os principais artefatos informados para verificar se eles foram representados de forma precisa e satisfatória. Talvez seja útil solicitar ao autor do artefato informado para rever seu trabalho baseado nisso.
Lembre-se de que o RUP é um processo iterativo e de que, em muitos casos, os artefatos evoluem com o tempo. Portanto, normalmente não é necessário — e, em geral, é improdutivo — formar um artefato completo que será usado apenas parcialmente ou que nem será usado no trabalho imediatamente subseqüente. Isso porque há uma grande probabilidade de a situação que envolve o artefato ser alterada — e as suposições feitas no momento de criação do artefato acabarem sendo incorretas — antes de o artefato ser usado, resultando em desperdício de esforço e em um dispendioso retrabalho. Evite também a armadilha de ficar perdendo tempo com inúmeros ciclos de apresentação em detrimento do valor do conteúdo. Em ambientes de projeto em que apresentações têm grande importância e são considerados produtos liberados, utilize um recurso administrativo para tarefas de apresentação.
|
Rational Unified Process |
