Skip to main content

Plano de Regressão

O que é regressão

Regressão é o processo de validar se uma correção ou melhoria não causou impactos negativos em funcionalidades que já funcionavam corretamente.

Na DBSeller, regressão é especialmente crítica porque os sistemas possuem:

  • alto nível de integração entre módulos

  • rotinas reutilizadas em múltos contextos

  • comportamento dependente de filtros, abas e estados da tela

Ou seja, corrigir um bug isolado não garante que o sistema permaneça estável como um todo.

Por que o Plano de Regressão existe na DBSeller

Diante do grande volume de integrações e da recorrência de correções em funcionalidades já existentes, foi criado o Plano de Regressão como um documento específico para bugs.

O objetivo do Plano de Regressão é:

  • documentar todos os cenários relacionados ao bug

  • validar não apenas a correção, mas seus efeitos colaterais

  • evitar regressões silenciosas

  • garantir estabilidade do fluxo corrigido

Diferente do Plano de Teste, que é mais comum em novas funcionalidades, o Plano de Regressão nasce a partir de um bug.

Quando aplicar um Plano de Regressão

Um Plano de Regressão deve ser criado quando:

  • o bug afeta uma rotina crítica

  • o erro envolve estado, filtros, abas ou carregamento dinâmico

  • a correção altera comportamento existente

  • há risco de impacto em outras partes do sistema

  • o bug envolve dados persistentes ou históricos

Bugs simples e isolados podem não exigir um plano completo, mas bugs comportamentais quase sempre exigem.

Relação com o Fluxo de Regressão

O Plano de Regressão é a materialização do Fluxo de Regressão.

O fluxo responde quando testar.
O plano responde o que testar e como validar.

Ele serve como guia para:

  • execução do reteste

  • validação dos impactos

  • evidência da estabilidade da correção

Como construir um Plano de Regressão (passo a passo)

A seguir, um exemplo completo e comentado, baseado em um bug real, porém descrito de forma institucional.

🐞 Exemplo de Bug (fictício)

Bug: Consulta de Horários do Professor não exibe vínculos ao alterar ano
Módulo: Educação > Escola > Cadastros > Recursos Humanos
Problema resumido:
Ao alternar o filtro de ano na aba de consulta de horários, os vínculos deixam de ser exibidos e não retornam ao selecionar novamente o ano original.

Esse tipo de bug é clássico de:

  • problema de estado

  • carregamento assíncrono

  • perda de contexto após filtro

Ou seja, alto risco de regressão.

📘 Exemplo de Plano de Regressão

1. Objetivo do Plano de Regressão

O objetivo deste plano é validar que a aba Consulta de Horários passou a se comportar corretamente ao alternar o ano no filtro, garantindo que os vínculos:

  • sejam exibidos corretamente para cada ano

  • retornem ao alternar novamente o filtro

  • não desapareçam permanentemente

  • não causem instabilidade na tela

Essa seção deixa claro o que significa “bug corrigido”.

2. Pré-requisitos

  • cadastro ativo de professor com vínculos em mais de um ano

  • anos distintos com dados válidos

  • acesso ao ambiente de validação

  • acesso à rotina:
    Educação > Escola > Cadastros > Recursos Humanos > Alteração

  • ferramenta de evidência disponível

Essa seção garante reprodutibilidade do teste.

3. Escopo da Regressão

Aqui o QA expande o olhar além da correção pontual.

A) Correção principal

  • exibição correta dos vínculos ao mudar o ano

  • recarregamento adequado dos dados

  • retorno correto ao ano anterior

B) Situações derivadas do erro

  • alternância repetida de anos

  • seleção de ano sem vínculos

  • troca de abas durante a consulta

  • carregamento incompleto

C) Estabilidade geral

  • a interface não deve limpar dados indevidamente

  • outras abas do cadastro não devem ser afetadas

  • não deve haver impacto em salvamento ou navegação

Essa seção é o coração da regressão.

4. Cenários de Teste (BDD)

4.1 Cenários principais

Cenário: Exibir vínculos corretamente ao alterar o ano
Dado que o professor possui vínculos em diferentes anos
Quando altero o filtro de ano
Então os vínculos correspondentes ao ano selecionado devem ser exibidos

Cenário: Retornar para o ano anterior deve restaurar os vínculos
Quando retorno o filtro para o ano inicial
Então os vínculos devem voltar a ser exibidos normalmente

4.2 Cenários derivados

Cenário: Selecionar ano sem vínculos
Quando seleciono um ano sem registros
Então a lista deve ficar vazia
E ao retornar para um ano com vínculos
Então os dados devem reaparecer

Cenário: Trocar de aba não deve limpar a consulta
Quando navego para outra aba
E retorno para a aba de consulta
Então os vínculos devem permanecer conforme o filtro

4.3 Cenários regressivos

Cenário: Outros cadastros não são afetados
Quando acesso outros professores
Então a consulta de horários deve funcionar normalmente

Cenário: Performance permanece estável
Quando alterno o ano repetidamente
Então a tela deve responder sem lentidão ou falhas

5. Conclusão

O plano de regressão garante que:

  • a correção resolve o problema original

  • não há perda de dados após interação

  • a navegação permanece estável

  • não foram introduzidas novas falhas

Ele cobre:

  • a correção

  • os impactos indiretos

  • a estabilidade do módulo como um todo

Como o Plano de Regressão ajuda o QA

Um bom Plano de Regressão permite:

  • testar além do óbvio

  • evitar bugs reincidentes

  • documentar conhecimento do sistema

  • dar segurança para liberação

Na DBSeller, ele é uma ferramenta estratégica, não apenas um checklist.

Diferença entre Plano de Teste e Plano de Regressão

  • Plano de Teste: nasce de uma funcionalidade ou melhoria

  • Plano de Regressão: nasce de um bug

Ambos se complementam e fazem parte da governança de qualidade.

Back to top