Como qualquer processo formal, atividades de teste tipicamente são precedidas por amplo planejamento e preparações. O principal objetivo deste estágio é garantir que o time entenda os objetivos do cliente, o principal propósito do produto, os principais riscos que eles devem enfrentar, e os resultados que eles esperam atingir.  Um dos documentos criados neste estágio, a missão ou desígnio dos testes, serve para resolver esta tarefa. Ele ajuda alinhar as atividades do teste com o proposito geral do produto e coordena o esforço de testes com o resto do trabalho do time.    

Roger S. Pressman, um engenheiro de software profissional, autor famoso, e consultor, diz: “Estratégia para testes de software provê um roadmap que descreve os passos para serem conduzidos como parte dos testes, quando estes passos são planejados e então seguidos, e quanto esforço, tempo e recursos serão necessários.”    

Também se refere á abordagem dos testes ou a arquitetura, a estratégia dos testes é outro artefato do estágio do planejamento. James Bach, um guru do teste que criou o Rápido curso de Testes de Software, identificou o proposito de uma estratégia de testes como “para clarificar as maiores tarefas e desafios do projeto de testes.” Uma boa estratégia, em sua opinião, é específica ao produto, pratica e justificada.  

Dependendo de quando exatamente no processo elas serão utilizadas, as estratégias podem ser classificadas como preventivas ou reativas. Em adição a isso, existem vários tipos de estratégias que podem ser usadas em conjunção ou separadamente:

Os sete tipos de estratégias de testes

Enquanto uma estratégia de testes é um documento de alto nível, o plano de teste têm uma abordagem mais “mão na massa”, descrevendo em detalhes o que testar, como testar, quando testar e quem fará o teste. Diferente do documento de estratégia, ele se refere ao projeto como um todo, o plano de teste cobre cada fase separadamente e é frequentemente atualizado pelo gestor do teste ao longo de todo o processo.

De acordo com IEEE standard for software test documentation, o documento de plano de teste deve conter a seguinte informação:

  • Identificador do plano de Teste
  • Introdução
  • Referencias (lista de documentos relacionados)
  • Itens do Teste (o produto e suas versões)
  • Características a serem testadas
  • Características que não serão testadas
  • Critério de Aprovação ou falha dos Itens
  • Abordagem dos Testes (níveis dos testes, tipos, técnicas)
  • Critérios de Suspensão
  • Entregáveis (Plano de Teste (documento em sí), Casos de Teste, Scripts de Teste, Logs de Defeitos/melhoramentos, Relatórios de Teste)
  • Ambientes de Teste (hardware, software, ferramentas)
  • Estimativas
  • Agendas
  • Recursos pessoais e necessidades de treinamentos
  • Responsabilidades
  • Riscos
  • Suposições e Dependências
  • Aprovação/Consentimentos

Escrever um plano que contenha todas as informações listadas, é uma tarefa que consome bastante tempo. Em metodologias ágeis, com o foco no produto ao invés da documentação, tal gasto de tempo parece insuficiente. 

Para resolver este problemas, James Whittaker, um Evangelista Técnico na Microsoft e antigo Diretor Engenheiro no Google, introduziu a abordagem do Plano de Testes de 10 minutos.  A principal ideia por traz deste conceito é focar no essencial primeiro, cortando todos adereços usando tabelas e listas simples ao invés de grandes parágrafos e detalhadas descrições. Enquanto a premissa de 10 minutos parece um pouco irrealista (nenhum dos times no experimento original conseguiu cumprir este requisito), a ideia de reduzir e limitar o tempo de planejamento em sí é altamente razoável. Como resultado, 80% do planejamento pode ser concluído em apenas 30 minutos.  

_______________________________________________________________________________________________________________

Data: 28/11/2019
Fonte: altexsoft.com
Tradução: Michael Mendes