Plano de Teste

Quando criar um Plano de Teste

O Plano de Teste deve ser criado sempre que a demanda:

introduz nova lógica de negócio
altera regras existentes
impacta múltiplas rotinas ou relatórios
possui risco médio ou alto
exige validação estruturada e rastreável

Na DBSeller, o Plano de Teste é especialmente indicado para:

melhorias funcionais relevantes
alterações em cálculos, regras ou integrações
demandas que afetam mais de um módulo

Correções simples e isoladas normalmente não exigem um plano completo, podendo ser validadas apenas com estratégia + casos direcionados.

Relação entre Plano de Teste e Estratégia de Teste

A estratégia de teste define o como pensar.
O plano de teste define o como executar.

Antes de escrever um plano, a estratégia já deve ter respondido:

onde estão os riscos
quais tipos de teste serão usados
quais rotinas precisam de regressão

O Plano de Teste transforma isso em algo executável, verificável e documentado.

Estrutura de um Plano de Teste (explicada passo a passo)

A seguir está a explicação de cada seção do plano, usando como base o modelo real utilizado na DBSeller

1. Contexto e descrição da demanda

Objetivo da seção
Explicar o que mudou e por que mudou, sem entrar em solução técnica.

O que deve conter

problema atual do sistema
impacto no uso real
qual regra está sendo alterada ou criada

Boas práticas

escrever em linguagem clara
evitar termos técnicos desnecessários
permitir que qualquer pessoa entenda o cenário

Essa seção é fundamental para o QA não testar “no escuro”.

2. Pré-requisitos

Objetivo da seção
Garantir que qualquer QA consiga executar os testes sem dependências implícitas.

O que deve conter

acessos necessários
ambiente correto
dados mínimos obrigatórios
ferramentas que serão utilizadas

Exemplo de uso prático:

acesso VPN
base com dados específicos
ambiente correto de validação
ferramenta de evidência

Isso evita perda de tempo durante a execução.

3. Estratégia de Testes (resumo aplicado)

Objetivo da seção
Registrar como a estratégia definida será aplicada nesta demanda específica.

O que deve conter

tipos de teste utilizados
foco principal da validação
preocupações de regressão
pontos sensíveis da regra

Aqui não se repete a teoria de estratégia, apenas se aplica ao caso real.

4. Cenários de Teste

Essa é a parte central do Plano de Teste.

Na DBSeller, os cenários são descritos em BDD (Given, When, Then) porque:

facilitam entendimento
reduzem ambiguidade
aproximam QA, Dev e Produto

4.1 Cenários principais de regra de negócio

Objetivo
Validar diretamente a nova regra ou comportamento criado.

Boas práticas

cobrir cenários positivos e negativos
variar combinações de dados
validar exceções
garantir que a regra não se aplique onde não deveria

Esses cenários validam se a regra funciona corretamente em condições normais e extremas.

4.2 Cenários de consistência entre rotinas

Objetivo
Garantir que o mesmo dado gere o mesmo resultado em diferentes telas ou relatórios.

Importância
Essa seção é crítica em sistemas integrados como o E-Cidade, onde:

uma informação aparece em múltiplas rotinas
divergências geram inconsistência de dados

Aqui o QA valida coerência sistêmica, não apenas cálculo isolado.

4.3, 4.4 e 4.5 Cenários específicos por rotina

Objetivo
Validar comportamentos particulares de cada rotina afetada.

Essas seções existem para:

validar ordenação
exportação
navegação
atualização dinâmica
consistência visual

O QA deve pensar:
“Essa rotina tem alguma característica própria que pode quebrar com a mudança?”

4.6 Cenários técnicos e regressivos

Objetivo
Garantir que a melhoria não quebrou nada que já funcionava.

Inclui:

filtros
performance
dados incompletos
comportamento padrão para casos fora do escopo

Essa seção protege o sistema como um todo.

Conclusão Final

Objetivo da seção
Consolidar tudo o que foi validado e deixar claro o que o plano garante.

Uma boa conclusão:

resume a regra validada
reforça os pontos críticos cobertos
deixa explícito o que não foi impactado
dá segurança para decisão de liberação

Ela facilita muito decisões de Go ou No-Go.