Skip to main content

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.

Back to top