Plano de Teste - Padrão IEEE 829-1998

O ideal seria que sempre houvesse uma equipe destinada a realizar testes de software, produzindo os relatórios necessários para que os problemas possam ser estudados e resolvidos. Mas nem todas as empresas possuem estrutura que suporte ter uma equipe que siga todas as instruções para a realização de testes.

Nestes casos, uma boa saída é nomear alguém da empresa que não esteja envolvido na produção do sistema para realizar os testes. Claro que nestes casos as empresas devem definir quais os principais testes devem ser realizados de forma a atingir as partes mais críticas do sistema.

Os erros encontrados devem ser documentados com informações suficientes que ajudem na reprodução do erro, facilitando assim a solução do problema. A documentação do erro deve ser definida pela empresa. É importante manter um histórico de falhas encontradas, pois assim, ao final do projeto, pode ser feito um estudo e obter um aprendizado em cima dos erros que foram encontrados.

Uma atividade de testes bem organizada pressupõe planejamento. O plano de testes facilita a comunicação entre os envolvidos no desenvolvimento do software ao propor um padrão de referência a ser seguido.

O padrão apresentado a seguir é uma adaptação do padrão de plano de testes do IEEE[1998], abrangendo o planejamento, especificação e documentação dos testes. Caso sejam necessárias mais seções, estas devem ser incluídas após a última.

PADRÃO IEEE 829-1998:

Plano de Teste - Padrão IEEE 829-1998

• Propósito - descreve o escopo, os recursos, a abordagem e o tempo alocado para as atividades de teste. Identifica os itens e funcionalidades a serem testados, os responsáveis e os riscos.
• Identificador – associa um identificador único ao plano de testes específico.
• Introdução – resume os itens e funcionalidades a serem testados. Pode haver referências a outros documentos do processo de desenvolvimento.
• Itens – Identifica os itens a serem testados, incluindo versão.
• Funcionalidades – Identifica as funcionalidades que serão testadas ou não, assim como os motivos.
• Abordagem – especifica as principais atividades, técnicas e ferramentas usadas para o teste das funcionalidades. O detalhamento deve ser suficiente para permitir identificação das principais tarefas de teste e a estimativa de tempo para cada uma. As restrições significativas como recursos e prazos, devem ser identificadas.
• Critérios de aceite – especifica os critérios de aceite para cada item.
• Suspensão – especifica os critérios para suspender parte ou toda a atividade de teste.
  Especifica as atividades que devem ser repetidas quando o teste for retomado.
• Produtos – identifica os documentos produzidos, como planos, procedimentos, logs e relatórios.
• Tarefas de teste – identifica as atividades necessárias para preparar e executar os testes, bem como todas as dependências entre as tarefas.
• Ambiente – identifica as atividades necessárias para preparar e executar os testes, bem como todas as dependências entre as tarefas.
• Responsabilidades – identifica os grupos responsáveis por gerenciar, projetar, executar, verificar e resolver os testes. Identifica os grupos responsáveis pelo ambiente e pelos itens de teste.
• Treinamento – especifica as necessidades de treinamento e identifica as opções.
• Cronograma – identifica as atividades e os prazos de conclusão. Para cada recurso, como pessoas e ferramentas, especifica os períodos de alocação.
• Riscos – identifica os maiores riscos e os planos de contingência.
• Aprovações – especifica os nomes e cargos dos responsáveis por aprovar o plano.
  Devem ser inclusos espaços para assinaturas e data.

Veja também:
Fases de Testes:
Fases de Testes

Tipos de Testes:
Teste de Caixa-Preta
Teste de Caixa-Branca
Testes de Estresse
Teste de Integração
Teste de Orientado a Objetos
Teste de Aceitação


QABI Consultoria

Compartilhar no Facebook:
Compartilhar no Linkedin: