Teste de Software - Documentação

A documentação de teste envolve a documentação de artefatos que devem ser desenvolvidos antes ou durante o teste do Software.

A documentação para teste de software ajuda a estimar o esforço de teste necessário, cobertura de teste, rastreamento / rastreamento de requisitos, etc. Esta seção descreve alguns dos artefatos documentados comumente usados ​​relacionados ao teste de software, como -

  • Plano de teste
  • Cenário de Teste
  • Caso de teste
  • Matriz de rastreabilidade

Plano de teste

Um plano de teste descreve a estratégia que será usada para testar um aplicativo, os recursos que serão usados, o ambiente de teste no qual o teste será executado e as limitações do teste e o cronograma das atividades de teste. Normalmente, o líder da equipe de garantia de qualidade será responsável por escrever um plano de teste.

Um plano de teste inclui o seguinte -

  • Introdução ao documento do Plano de Teste
  • Suposições ao testar o aplicativo
  • Lista de casos de teste incluídos no teste do aplicativo
  • Lista de recursos a serem testados
  • Que tipo de abordagem usar ao testar o software
  • Lista de entregas que precisam ser testadas
  • Os recursos alocados para testar o aplicativo
  • Quaisquer riscos envolvidos durante o processo de teste
  • Uma programação de tarefas e marcos a serem alcançados

Cenário de Teste

É uma instrução de uma linha que notifica qual área do aplicativo será testada. Os cenários de teste são usados ​​para garantir que todos os fluxos do processo sejam testados de ponta a ponta. Uma área específica de um aplicativo pode ter de apenas um cenário de teste a algumas centenas de cenários, dependendo da magnitude e da complexidade do aplicativo.

Os termos 'cenário de teste' e 'casos de teste' são usados ​​alternadamente, no entanto, um cenário de teste tem várias etapas, enquanto um caso de teste tem uma única etapa. Visto dessa perspectiva, os cenários de teste são casos de teste, mas incluem vários casos de teste e a sequência em que devem ser executados. Além disso, cada teste depende da saída do teste anterior.

Caso de teste

Os casos de teste envolvem um conjunto de etapas, condições e entradas que podem ser usadas durante a execução de tarefas de teste. O objetivo principal desta atividade é garantir que um software seja aprovado ou reprovado em termos de funcionalidade e outros aspectos. Existem muitos tipos de casos de teste, como funcional, negativo, erro, casos de teste lógicos, casos de teste físicos, casos de teste de IU, etc.

Além disso, os casos de teste são escritos para controlar a cobertura de teste de um software. Geralmente, não há modelos formais que podem ser usados ​​durante a escrita do caso de teste. No entanto, os seguintes componentes estão sempre disponíveis e incluídos em cada caso de teste -

  • ID do caso de teste
  • Módulo de produto
  • Versão do produto
  • Histórico de Revisão
  • Purpose
  • Assumptions
  • Pre-conditions
  • Steps
  • Resultado esperado
  • Resultado real
  • Post-conditions

Muitos casos de teste podem ser derivados de um único cenário de teste. Além disso, às vezes, vários casos de teste são escritos para um único software, conhecidos coletivamente como suítes de teste.

Matriz de rastreabilidade

A Matriz de Rastreabilidade (também conhecida como Matriz de Rastreabilidade de Requisito - RTM) é uma tabela usada para rastrear os requisitos durante o Ciclo de Vida de Desenvolvimento de Software. Pode ser usado para rastreamento direto (ou seja, de Requisitos para Projeto ou Codificação) ou para trás (ou seja, de Codificação para Requisitos). Existem muitos modelos definidos pelo usuário para RTM.

Cada requisito no documento RTM está vinculado ao seu caso de teste associado para que o teste possa ser feito de acordo com os requisitos mencionados. Além disso, o Bug ID também está incluído e vinculado a seus requisitos e casos de teste associados. Os principais objetivos desta matriz são -

  • Certifique-se de que o software seja desenvolvido de acordo com os requisitos mencionados.
  • Ajuda a encontrar a causa raiz de qualquer bug.
  • Ajuda no rastreamento dos documentos desenvolvidos durante as diferentes fases do SDLC.