Papéis e Atividades > Conjunto de Papéis do Analista > 
Analista de Teste > 
Definir Necessidades de Avaliação e Rastreabilidade
Atividade:
| ||||||||||||||||||||||||||||||||||||||||||||||
Finalidade
|
|
Passos
|
|
| Artefatos Informados: | Artefatos Resultantes: |
| Freqüência: Normalmente, esta atividade é executada várias vezes em cada iteração. | |
| Papel: Analista de Teste | |
| Mentores de Ferramentas: | |
| Informações Adicionais: |
|
| Detalhamentos do Fluxo de Trabalho: |
| Finalidade: | Entender os produtos liberados para o processo de avaliação de software e identificar os requisitos associados. |
Reveja o Plano de Iteração e identifique as necessidades de avaliação específicas para este próximo corpo de trabalho. Pergunte aos envolvidos 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. Os requisitos de auditoria formais podem necessitar da retenção de documentações e registros adicionais como provas da execução de testes suficientes.
| Finalidade: | Identificar as restrições que afetarão a capacidade (ou a necessidade) de implementação dos requisitos. |
Embora haja normalmente uma lista interminável de "necessidades" que possam ser consideradas como requisitos para as estratégias de rastreabilidade e avaliação, é importante que você se concentre nas "necessidades" mais importantes que a) Forneçam informações essenciais para a equipe de projeto e b) Possam ser realmente controladas 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:
É importante identificar o nível de qualidade considerado como "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 envolvidos, durante todo o ciclo de vida do projeto.
Reveja o Plano de QA, o Plano de Desenvolvimento de Software e entreviste diretamente os principais envolvidos para determinar o que eles consideram como um nível de qualidade aceitável.
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 impor restrições na rastreabilidade: por exemplo, se for desejável a rastreabilidade dos testes para requisitos de motivação, mas os próprios requisitos não estiverem sendo cuidadosamente gerenciados, talvez seja 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.
| Finalidade: | Identificar e descrever uma ou mais estratégias que facilitarão o processo de avaliação necessário. |
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 de possíveis estratégias, sugerimos a leitura do documento "
Measurement of the Extent of Testing", de Cem Kaner, publicado em outubro de 2000.
Subtópicos:
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 da métrica 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.
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.
Recomenda-se que, em vez disso, você analise seus resultados de teste em termos de tendência relativa ao longo do tempo e, em cada ciclo de teste, considere a distribuição relativa de falhas de teste por diferentes dimensões, como a área funcional testada, o tipo de riscos de qualidade explorados e a complexidade relativa dos testes e dos recursos de teste aplicados a cada área funcional. This information
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, considerando que o esforço de teste permaneça relativamente constante, você geralmente esperaria ver a nova taxa de detecção de defeitos medida em um período de tempo regular como uma curva ascendente durante o curso da iteração, ou seja, uma taxa de detecção crescente que fosse aumentando, e não diminuindo, à medida que o fim da iteração fosse se aproximando. Entretanto, você precisará fornecer essas informações junto 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.
| Finalidade: | Reunir feedback através da revisão inicial dos envolvidos e ajustar as estratégias conforme necessário. |
Apresente as possíveis estratégias aos diversos envolvidos. Tipicamente, espera-se que isso inclua um grupo composto destes papéis: Gerente de Projeto, Arquiteto de Software, Gerente de Desenvolvimento, Analista de Sistemas, Gerente de Configuração e Mudanças, Gerente de Implantaçã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 desde uma ou mais reuniões informais até uma apresentação formal ou uma sessão de workshop.
| Finalidade: | Obter a aprovação dos envolvidos sobre a estratégia a ser usada. |
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 envolvidos.
Apresente a estratégia de avaliação para uma aprovação final.
| Finalidade: | Definir os requisitos de configuração da ferramenta de suporte que permitirão o processo de avaliação. |
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.
Considere qual suporte de ferramenta será necessário para estas categorias: Cobertura e Rastreabilidade, Análise de Defeitos.
| 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 |
