Skip to main content

Elaboração do Planejamento de Testes

 Objetivo desta página

Esta página descreve de forma completa, prática e aplicada como ocorre a Elaboração do Planejamento de Testes na DBSeller, dentro do item QA – Elaboração.

Ela existe para deixar claro como o QA transforma a estratégia em ação, estruturando tudo o que será feito antes da execução dos testes. Aqui, o QA deixa de apenas “pensar sobre testes” e passa a organizar, documentar e preparar a execução real.

Esta página se conecta diretamente com os seguintes documentos já definidos na wiki:

  • Elaboração de Estratégia de Teste da Task

  • Automação de Testes – Boas Práticas, Decisão e Manutenção

  • Planejamento de Testes

  • Plano de Teste

  • Plano de Regressão

  • Tipos de Teste

  • Critérios de Entrada e Saída

  • Critérios de Aceite

O Planejamento de Testes é a ponte entre pensar qualidade e executar qualidade.

2. Diferença entre Estratégia de Teste e Planejamento de Testes

Antes de avançar, é essencial reforçar a diferença entre duas etapas que se complementam, mas não se confundem.

Estratégia de Teste da Task

  • Define como pensar a validação.

  • Mapeia riscos.

  • Define tipos de teste.

  • Estabelece foco e prioridades.

  • Delimita o que fica fora do escopo.

A estratégia é mental, analítica e decisória.

Planejamento de Testes

  • Define como executar.

  • Cria os planos de teste.

  • Define cenários detalhados.

  • Organiza pré-requisitos, dados e ambientes.

  • Prepara regressão, automação e acompanhamento.

O planejamento é operacional, documental e prático.

Sem estratégia, o planejamento vira checklist vazio.
Sem planejamento, a estratégia nunca sai do papel.

3. Quando o Planejamento de Testes acontece

Na DBSeller, o Planejamento de Testes ocorre:

  • Após a definição da Estratégia de Teste da Task.

  • Enquanto o desenvolvimento ainda está em andamento.

  • Antes do início da execução formal dos testes.

Isso permite que o QA:

  • Antecipe dúvidas e lacunas.

  • Prepare dados e acessos.

  • Evite atrasos na fase de execução.

  • Atue de forma paralela ao desenvolvimento.

Planejar testes não é esperar o código ficar pronto. É trabalhar antes para executar melhor depois.

4. Visão geral do fluxo de Planejamento de Testes

Fluxo macro:

[Estratégia de Teste Definida]
           |
           v
[Definir Tipo de Plano]
           |
           v
[Criar Plano de Teste ou Regressão]
           |
           v
[Definir Cenários (BDD)]
           |
           v
[Preparar Pré-requisitos e Dados]
           |
           v
[Planejamento Pronto para Execução]

Esse fluxo garante previsibilidade, organização e rastreabilidade.

5. Tipos de Planejamento de Testes

O QA deve decidir qual tipo de planejamento será aplicado, com base na estratégia.

5.1 Planejamento com Plano de Teste

Indicado quando a demanda:

  • Introduz nova lógica de negócio.

  • Altera regras existentes.

  • Impacta múltiplas rotinas.

  • Possui risco médio ou alto.

5.2 Planejamento com Plano de Regressão

Indicado quando a demanda nasce de:

  • Correção de bug.

  • Ajuste em comportamento existente.

  • Problema recorrente ou sistêmico.

5.3 Planejamento híbrido

Em alguns casos, o QA pode:

  • Criar um Plano de Teste para a melhoria.

  • Criar um Plano de Regressão complementar.

Isso é comum em demandas que corrigem um bug e alteram comportamento.

6. Estrutura do Planejamento de Testes

O Planejamento de Testes se materializa principalmente por meio de planos documentados, seguindo o padrão da DBSeller.

6.1 Contexto e descrição da demanda

Objetivo:

  • Garantir entendimento comum do que está sendo validado.

Boas práticas:

  • Linguagem clara.

  • Foco no comportamento do sistema.

  • Evitar termos técnicos excessivos.

Exemplo:

"Hoje, o sistema recalcula a taxa de seguro e exibe valores divergentes entre telas. A demanda ajusta a regra de cálculo para garantir consistência entre simulação, resumo e contrato."

6.2 Pré-requisitos

Objetivo:

  • Garantir que qualquer QA consiga executar os testes sem dependências ocultas.

Exemplos de pré-requisitos:

  • Usuário com perfil específico.

  • Empresa com parâmetro habilitado.

  • Dados previamente cadastrados.

  • Ambiente correto.

Pré-requisitos evitam o clássico: “não consegui reproduzir”.

6.3 Aplicação da Estratégia no Planejamento

Nesta seção, o QA traduz a estratégia em ações concretas:

  • Quais tipos de teste serão executados.

  • Onde haverá foco maior.

  • Onde a validação será mais superficial.

  • Se haverá automação ou não.

Aqui não se reexplica a estratégia, apenas se aplica.

Perfeito, ótima escolha de task.
Abaixo está o Item 7 completo, mantendo toda a explicação, tabelas e fluxos, com TODOS os exemplos reescritos e contextualizados na task real #33313 – Relatório Dados da Escola (e-Cidade).

Texto 100% final, pronto para colar na wiki.

7. Definição de Cenários de Teste

A definição de cenários de teste é o ponto central do Planejamento de Testes. É nesta etapa que o QA transforma regras, requisitos e riscos em validações claras, executáveis e rastreáveis, garantindo que o comportamento do sistema esteja alinhado com o esperado pelo cliente e pelas regras de negócio.

Enquanto a estratégia define o que precisa ser garantido, os cenários definem:

  • Em quais condições o sistema será utilizado

  • Quais ações serão realizadas

  • Qual comportamento o sistema deve apresentar

Um cenário bem definido elimina interpretações subjetivas e reduz retrabalho durante a execução.

7.1 O que é BDD e o que é Gherkin

BDD (Behavior Driven Development) é uma abordagem que descreve o comportamento esperado do sistema a partir da perspectiva de uso e das regras de negócio.

Em vez de focar em implementação técnica, o BDD responde perguntas como:

  • O que o usuário espera fazer?

  • Em qual contexto?

  • Qual deve ser o resultado?

Gherkin é a linguagem estruturada utilizada para escrever esses comportamentos de forma simples, padronizada e compreensível por diferentes áreas.

Principais palavras-chave:

Palavra-chave Função
Dado que Define o contexto inicial
E Complementa contexto ou ação
Quando Define a ação executada
Então Define o resultado esperado

Essa estrutura cria uma narrativa lógica, clara e objetiva do comportamento do sistema.

7.2 Por que utilizar BDD e Gherkin na DBSeller

A utilização de BDD com Gherkin na DBSeller é uma decisão estratégica, especialmente considerando sistemas complexos como o e-Cidade, que envolvem múltiplas regras, relatórios e impactos legais.

Benefícios diretos:

Benefício Impacto prático
Linguagem comum Facilita alinhamento entre QA, desenvolvimento e atendimento
Menos ambiguidade Reduz falhas de interpretação
Revisão antecipada Cenários podem ser validados antes da execução
Base para automação Cenários reutilizáveis
Documentação viva O comportamento fica registrado

Em demandas, onde há layout, dados, regras e exceções, o BDD evita validações superficiais.

7.3 Estrutura padrão de um cenário de teste

Estrutura recomendada:

Cenário: Descrição clara do comportamento
Dado que [contexto inicial]
E [condições adicionais]
Quando [ação executada]
Então [resultado esperado]

Boas práticas obrigatórias:

  • Um cenário valida um comportamento principal

  • Linguagem funcional, nunca técnica

  • Resultado sempre verificável

7.4 Tipos de cenários no Planejamento de Testes

Durante o planejamento, os cenários devem ser classificados para garantir cobertura adequada.

Tipo de cenário Objetivo
Positivo Validar comportamento esperado
Negativo Validar tratamento de erro
Exceção / Borda Validar limites e casos extremos
Regressivo Garantir que nada foi quebrado

Fluxo conceitual:

[Requisitos da Task]
        |
        v
[ Cenários Positivos ]
        |
        v
[ Cenários Negativos ]
        |
        v
[ Cenários de Exceção ]
        |
        v
[ Cenários Regressivos ]

7.5 Cenários Positivos

Cenários positivos validam o comportamento do sistema quando todas as condições estão corretas.

Pergunta-chave:

O sistema faz exatamente o que foi solicitado?

Exemplo – Cenário positivo

Cenário: Gerar relatório de dados da escola conforme layout definido
Dado que existe uma escola cadastrada com todos os dados obrigatórios preenchidos
E existe um modelo oficial de Ficha Cadastral da Unidade Escolar
Quando o usuário acessa a rotina EDUCAÇÃO > Escola > Relatórios > Dados da Escola
E solicita a geração do relatório
Então o sistema deve gerar o relatório respeitando integralmente o layout definido
E os dados exibidos devem corresponder às informações cadastradas da escola

Valida:

  • Geração do relatório

  • Fidelidade ao layout oficial

  • Consistência dos dados

7.6 Cenários Negativos

Cenários negativos validam o comportamento do sistema diante de condições inválidas ou inconsistentes.

Pergunta-chave:

O sistema impede comportamentos incorretos de forma controlada?

Exemplo real – Cenário negativo

Cenário: Não exibir cursos inativos no relatório de dados da escola
Dado que a escola possui cursos vinculados com status inativo
Quando o usuário gera o relatório de dados da escola
Então o sistema não deve exibir cursos marcados como inativos

Valida:

  • Regra de negócio

  • Prevenção de uso incorreto de informações

  • Consistência entre tela e relatório

7.7 Cenários de Exceção e de Borda

Esses cenários validam situações menos comuns, mas críticas.

Exemplos típicos:

  • Múltiplos Atos Legais

  • Volume de dados maior que uma página

  • Ausência de gestor ativo

Tabela de apoio:

Situação Risco
Mais de um Ato Legal Corte de informação
Muitos registros Quebra de layout
Gestor excluído Dado inconsistente

Exemplo – Cenário de exceção

Cenário: Exibir múltiplos Atos Legais no relatório em mais de uma folha
Dado que a escola possui mais de um Ato Legal vinculado
Quando o usuário gera o relatório de dados da escola
Então o relatório deve exibir todos os Atos Legais
E deve gerar novas páginas sempre que o conteúdo ultrapassar o limite da folha

Valida:

  • Completeness dos dados

  • Comportamento correto do layout

  • Regra explícita do requisito

7.8 Cenários Regressivos

Cenários regressivos garantem que ajustes não quebrem comportamentos existentes.

Fluxo regressivo:

[Correção ou Melhoria]
        |
        v
[Análise de Impacto]
        |
        v
[Seleção de Cenários Existentes]
        |
        v
[Execução de Regressão]

Exemplo real – Cenário regressivo

Cenário: Relatório não exibe gestor excluído da escola
Dado que um gestor foi removido da aba gestor nos dados da escola
Quando o usuário gera o relatório de dados da escola
Então o gestor excluído não deve constar no relatório

Protege:

  • Integridade da informação

  • Confiabilidade do relatório

  • Alinhamento com a tela de cadastro

7.9 Boas práticas na escrita de cenários

  • Escrever sempre sob a ótica do uso real

  • Evitar termos técnicos ou de banco de dados

  • Usar dados representativos do cliente

  • Manter cenários objetivos e claros

  • Atualizar cenários quando regras mudarem

Checklist rápido:

Item OK
Cenário claro ⬜
Resultado verificável ⬜
Regra de negócio coberta ⬜
Risco mitigado ⬜

7.10 Resultado esperado da definição de cenários

Quando os cenários são bem definidos no planejamento, a DBSeller garante:

  • Execução previsível

  • Menos dúvidas durante testes

  • Menos retrabalho

  • Base sólida para Go ou No-Go

  • Documentação clara do comportamento do sistema

Um bom cenário de teste é aquele que, ao ser lido, não deixa espaço para interpretação.

8. Planejamento de Regressão

Sempre que houver risco de impacto em funcionalidades existentes, o QA deve planejar a regressão.

O planejamento de regressão envolve:

  • Identificar rotinas afetadas.

  • Selecionar cenários existentes.

  • Ajustar testes antigos, se necessário.

Exemplo de cenário regressivo

Cenário: Simulações antigas permanecem inalteradas
Dado que existe uma simulação criada antes da alteração
Quando acesso o resumo da simulação
Então os valores exibidos devem permanecer conforme a regra vigente à época

9. Planejamento da Automação

Durante o planejamento, o QA deve:

  • Avaliar cenários candidatos à automação.

  • Registrar essa decisão.

  • Definir se a automação será imediata ou futura.

Essa decisão segue o documento:
Automação de Testes – Boas Práticas, Decisão e Manutenção.

10. Acompanhamento do Desenvolvimento

O Planejamento de Testes não é estático.

Durante o desenvolvimento, o QA deve:

  • Acompanhar mudanças de escopo.

  • Ajustar cenários.

  • Atualizar planos quando necessário.

Planejamento bom é planejamento vivo.

11. Critérios de Entrada para Execução

Antes de iniciar a execução, o QA deve validar:

  • Ambiente disponível.

  • Funcionalidade implementada.

  • Dados preparados.

  • Plano revisado.

Sem critérios de entrada atendidos, a execução perde eficiência.

12. Resultado Esperado do Planejamento de Testes

Ao final do planejamento, espera-se que:

  • Todos saibam o que será testado.

  • Os riscos estejam mapeados e cobertos.

  • A execução ocorra sem improvisos.

  • A decisão de Go ou No-Go tenha base sólida.

13. Conclusão

A Elaboração do Planejamento de Testes é onde o QA materializa tudo o que foi pensado anteriormente.

É nesta etapa que:

  • Estratégia vira plano.

  • Risco vira cenário.

  • Intenção vira execução.

Back to top