Gerenciamento das Atividades de Teste

Um Plano de Teste descreve os objetivos, recursos e processos de um projeto de teste.

• Documenta os meios e o cronograma para atingir os objetivos do teste
• Ajuda a garantir que as atividades de teste realizadas atenderão a critérios estabelecidos.
• Serve como meio de comunicação entre membros da equipe e outros stakeholders
• Demonstra que os testes seguirão a política e a estratégia de testes existentes, ou explica o porquê o desvio delas

O conteúdo inclui:

• Contexto do teste
• Permissões e restrições
• Stakeholders
• Comunicação
• Registro de Risco
• Abordagem de teste
• Orçamento e cronograma

Ocorre nos SDLC's iterativos dois tipos de planejamento, o Planejamento de Liberação e o planejamento de Iteração.

Planejamento de Liberação: Tem como objetivo lançamento de um produto, define e redefine o backlog, refina histórias de usuário maiores em menores. Os testadores participam da escrita das histórias de usuário, critérios de aceite, análise de risco e da qualidade, estimam o esforço do teste relacionado a US, determinam a abordagem de teste e planejam o teste.

Planejamento de Iteração: Tem como objetivo o fim de uma iteração, se preocupando com seu backlog. Os testadores participam da análise de risco da US, determinam sua testabilidade, dividem-as em tarefas, estimam esforço, identificam e refinam aspectos funcionais e não funcionais do objeto de teste.

Critérios de Entrada: São as condições prévias para realizar uma atividade. Se esse critério não for atendido a atividade pode se tornar cara, demorada e arriscada. No desenvolvimento Ágil são chamados de Definição de Pronto - DoR - Definition of Ready.
Critérios de Entrada típicos: Disponibilidade de recursos, material de teste e nível de qualidade inicial do objeto de teste.

Critérios de Saída: Define o que deve ser alcançado para a atividade ser declarada como concluída. Esgotamento dos recursos pode ser considerado um critério de saída válido caso os riscos sejam aceitos pelos stakeholders. No desenvolvimento Agil são chamados de Definição de Feito - DoD - Definition of Done.
Critérios de Saída Típicos: Medidas de precisão e critérios de conclusão.

Critérios de Entrada e Saída devem ser definidos para cada nível de teste e serão diferentes com base no objetivo do teste.

Uma estimativa é a previsão da quantidade de trabalho relacionada ao teste, sendo baseada em suposições e sujeita a erros. Tarefas grandes devem ser decomposta em menores para poder ter uma estimativa mais precisa, entretanto são suposições sujeita a erros e todos os envolvidos devem estar cientes disso. Há 4 técnicas apresentadas aqui, são elas:

• Estimativa baseada em índices: Baseado em métricas. São usados Indicadores Padrão (números coletados de projetos anteriores) para estimar o esfoço do teste do novo projeto.
• Extrapolação: Baseado em métricas. Medições são feitas o mais cedo possível no projeto para coleta de dados, e a estimativa é feita com base na extrapolação desses dados. Muito adequado para SDLC iterativo.
• Wideband Delphi: Baseda em especialistas. São usadas as experiências dos especialistas para estimar o esforço, no qual chegam a um consenso em comum. O Planning Poker é uma variante, mais utilizada no desenvolvimento ágil.
• Estimativa de três pontos: Baseada em especialistas. Onde três estimativas são feitas, são elas:
  • o: a mais otimista
  • m: a mais provável
  • p: a mais pessimista
  • E: estimativa final
  Ela é calculada da seguinte forma:
  
  
  $\mathrm{E}=\frac{\mathrm{o}+\mathrm{4m}+\mathrm{p}}{6}$
  
  O erro de medição (SD) é cáculado da seguinte forma:
  
  $\mathrm{SD}=\frac{\mathrm{(}\mathrm{p}-\mathrm{o})}{6}$
  
  Exemplo de Estimativa em homens/hora:
  o=6, m=9, p=18, então E=10+-2 homens/hora (entre 8 e 12 homens hora (10-2 ou 10+2))
  
  
  $\mathrm{E}=\frac{6+36+18}{6}=10$ e $\mathrm{SD}=\frac{\mathrm{(}18-6)}{6}=2$

Um cronograma de execução dos testes define a ordem de prioridade que os casos de teste devem ser executados, a sua priorização deve levar em conta diversos fatores e estratégias, as mais utilizadas são:

• Priorização baseada em risco: É baseada na análise de risco, onde os casos de teste que abrangem os riscos mais importantes são executados primeiro.
• Priorização baseada em cobertura: É baseada na cobertura, onde os casos de teste que têm maior cobertura são executados primeiro.
• Priorização baseada em requisitos: É baseada nos requisitos, onde os casos de teste que abrangem os requisitos mais importantes são executados primeiro.

Se um caso de teste de prioridade mais alta depender de um caso de teste de prioridade mais baixa, o caso de teste de prioridade mais baixa deve ser executado primeiro. A ordem da execução também deve levar em conta a disponibilidade dos recursos, como tempo, ambiente de teste e disponibilidade de pessoas.

A Pirâmide de Teste é um modelo no qual mostra que os teste podem ter diferentes níveis de minuciosidade, apoiam a equipe na automação de testes e na alocação de esforços, mostrando que diferentes objetivos são apoiados por diferentes níveis.

Camadas: representam grupos de teste. Quanto mais alta a camada menor será a granulariadade (minuciosidade), o isolamento e o tempo de execução do teste.

Os testes da camada inferior são pequenos, isolados, rápidos e verificam uma pequena parte da funcionalidade. Para grandes coberturas é necessário executar muitos deles.

Os testes da camada superior são complexos, de alto nível, lentos e de ponta a ponta. Para grandes coberturas não é necessário executar muitos deles.

O modelo original (Cohn-2009) tem as camadas: Teste de Unidade, Teste de Serviço e Teste de Interface do Usuário.

O modelo popular tem as camadas: Teste de Unidade (componente), Teste de Integração (Integração de componentes) e Teste de Ponta a Ponta (E2E).

Imagine a pirâmide como uma montanha, quanto mais alto você subir na montanha maior será a cobertura de visão ao seu redor, entretanto a dificuldade da subida se torna cada vez maior a cada passo que dá para o pico de mais alto nível. Já no pé da montanha, a dificuldade e esfoço são menores, entretanto a cobertura de visão também é menor.

É um modelo que agrupa os níveis, os tipos, as atividades, as técnicas e os produtos de trabalho dos testes no desenvolvimento ágil de software. Visa ajudar e facilitar a visualização, garantindo que todos os tipos e níveis de teste apropriados sejam incluidos no SDLC e também a diferenciar e descreves os tipos de teste para todos os stakeholders.

Podem ser voltado para os negócios ou tecnologia, orientando o desenvolvimento, e voltado para o produto ou equipe, medindo o comportamento em relação as expectativas.

Quadrante 1: Voltado para Tecnologia, apoia a Equipe. Teste de componentes e de integração de componentes que devem ser automatizados e incluídos no processo de CI.

Quadrante 2: Voltado par aos Negócios, apoia a Equipe. Testes funcionais, exemplos, testes de histórias de usuário, protótipos de experiência do usuário, teste de API e simulações. Verificam os critérios de aceite e podem ser manuais ou automatizados.

Quadrante 3: Voltado para os Negócios, avalia o produto. Testes exploratórios, testes de usabilidade e testes de aceite do usuário. São orientados para os usuários e geralmente manuais.

Quadrante 4: Voltado para Tecnologia, avalia o produto. Smoke Test (Teste de fumaça) e testes não funcionais (menos de usabilidade que está no Quadrante 3). Geralmente são automatizados.

Risco: é um possível evento, perigo, ameaça ou situação que causa um evento adverso.

• Probabilidade: probabilidade de ocorrência do risco.
• Impacto: ou Dano, é a consequência da ocorrência do risco.

Nível do risco: é a medida do risco, quanto maior o nível mais importante deve ser o tratamento para esse risco.

Riscos do Projeto: Estão relacionados ao gerenciamento e ao controle do projeto. Quando ocorrem tem impacto no cronograma, orçamento ou escopo do projeto, impedindo que ele atinja seus objetivos, os problemas incluem:

• Problemas organizacionais
• Problemas de pessoal
• Problemas técnicos
• Problemas de fornecedores

Riscos do Produto: Estão relacionados a características de qualidade do produto, podem resultar em consequências negativas, como :

• Insatisfação do usuário
• Perda de receita, confiança e reputação
• Danos a terceiros
• Altos custos de manutenção e sobrecarga do heldesk
• Penalidades criminais
• Em casos extremos danos físicos, lesões ou morte

Consiste na identificação e avaliação dos riscos do produto. Proporcionando como objetivo uma conscientização desses riscos e concentrando os esforços dos testes nos riscos maiores, minimizando o risco residual do produto. O ideial é que comece no inicio do SDLC.

Identificar consiste em gerar uma lista dos riscos, avaliar consiste em categorizar os riscos identificados de acordo com sua probabilidade, impacto e nível, priorizando e propondo maneiras de lidar com eles.

Na avaliação, pode-se usar as abordagens

• Quantitativa: O nível do risco é a multiplicação da probabilidade do risco e do impacto do risco.
• Qualitativa: O nível do risco é determinado com uma matriz de risco.

Os resultados da Análise de Risco do Produto são utilizados para influenciar:

• Determinar o escopo dos testes a serem realizados
• Determinar os níveis e tipos de teste a serem realizados
• Determinar as técnicas utilizadas e a cobertura a ser alcançada
• Estimar o esforço de teste das tarefas
• Priorização dos teste.
• Determinar se atividades além dos testes devem ser aplicadas para reduzir o risco

Consiste na mitigação e monitoramento de riscos. Ou seja, são as medidas tomadas em resposta aos riscos identificados e avaliados do produto.

Mitigação é a implementação de ações para reduzir o nível de risco, onde as ações são proposta na avaliação de risco. O monitoramento dos riscos garante que as ações de mitigação sejam eficazes, obtendo também mais informações para melhorar a avaliação e identificando novos riscos.

Várias opções de respostas ao risco do produto são possíveis após sua análise, como:

• Mitigação do risco por meio dos testes
• Aceite do risco
• Transferência do risco
• Plano de contigência

As ações que podem ser tomadas para mitigar os riscos por meio dos testes são:

• Selecionar testadores com experiência e habilidades adequadas para determinado tipo de risco
• Aplicar o nível adequado de independência de testes
• Conduzir revisões e aplicar análises estáticas
• Aplicar técnicas de teste e níveis de cobertura adequados
• Aplicar tipos de teste apropriados para as características afetadas
• Realizar testes dinâmicos, incluindo o de regressão

São dados reunidos para mostrar o progresso em relação ao cronograma e orçamento planejados, também mostra a qualidade do objeto atual de teste e a eficácia das atividades em relação aos objetivos.

• Progresso do projeto (ex.: conclusão de tarefas)
• Progresso do teste (ex.: implementação dos TC)
• Qualidade do produto (ex.: tempo de resposta)
• Defeitos (ex.: densidade de defeitos)
• Risco (ex.: nível de risco residual)
• Cobertura (ex.: cobertura de requisitos)
• Custo (ex.: custo de teste)

Os relatórios de teste têm o objetivo de resumir e comunicar as informações do teste durante e após os testes. Existem os relatórios de progresso e os de conclusão. Sua formalidade e frequência dependem do seu público-alvo.

Os relatórios de progresso do teste são realizados durante o monitoramento e controle do teste, dando suporte ao controle do teste e fornecendo informações suficientes para modificar o cronograma, recurso ou o plano de teste quando necessário, além de manter os stakeholders informados. Podem incluir:

• Período de teste
• Progresso do teste, incluindo desvios
• Impedimentos para os testes e suas soluções
• Métricas de teste
• Riscos, novos e alterados
• Testes planejados para o próximo período

Um relatório de conclusão de teste resume um estágio específico do teste (ex.: nível de teste) e pode fornecer informações para os testes seguintes. É criado na conclusão do teste quando os critérios de saída forem atendidos. Relatórios de progresso e outros dados são utilizados para sua criação. Podem incluir :

• Resumo do teste
• Teste e avaliação da qualidade
• Desvios do plano de teste
• Impedimentos e soluções alternativas
• Métricas de teste baseadas nos relatórios de progresso
• Riscos não mitigados e defeitos não corrigidos
• Lições aprendidas

A forma de comunicar o status do teste pode variar de acordo com a organização e seus fatores, mas as opções incluem:

• Comunicação verbal
• Painéis (ex.: painéis de tarefas)
• Canais de documentação eletrônica (ex.: e-mail)
• Documentação on-line
• Relatórios de teste formais

Mais de uma opção pode ser utilizada, devendo ser adaptar ao nível de formalidade exigido e ao interesse do stakeholder de destino.