Estratégia de Testes de Regressão

Objetivo: Definir o modelo de execução de testes para garantir que novas alterações no código não causem efeitos colaterais em funcionalidades que já estavam funcionando.

1. Níveis de Regressão

Nem toda alteração exige que testemos o sistema inteiro. Dividimos nossa regressão em dois níveis:

Nível 1: Smoke Test (Sanidade)

• O que é: Um teste rápido nos fluxos vitais (Cenários Críticos).

• Quando rodar: Em todo deploy para o ambiente de QA ou Produção.

• Foco: Cadastro de bots e publicação básica. Se o Smoke Test falhar, a build é rejeitada imediatamente.

Nível 2: Regressão Full (Completa)

• O que é: Execução de todos os cenários documentados nesta seção (Bot Builder + Voz Dani + Integrações).

• Quando rodar: Antes de grandes liberações (Releases) ou quando houver mudanças estruturais no core da plataforma.

• Foco: Garantir que fluxos complexos e regras de negócio específicas (como as travas de data da Dani) continuam íntegras.

2. Critérios de Seleção

Para otimizar o tempo do QA, selecionamos os cenários de regressão baseados em:

1. Frequência de uso: Funcionalidades que o cliente usa todo dia.

2. Risco: Áreas que sofreram muitas mudanças recentes no código.

3. Histórico de bugs: Funcionalidades que costumam quebrar com frequência.

Cronograma de Execução

• Sprints: Durante a sprint, o QA foca nos testes das novas histórias. A regressão dos itens afetados deve ser feita antes de mover a tarefa para "Done".

• Pré-Release: Uma janela de tempo dedicada exclusivamente para rodar a suite de regressão completa antes do deploy em Produção.

Responsabilidades

• QA: Responsável por manter os roteiros de regressão atualizados e reportar falhas.

• Desenvolvedores: Devem garantir que os testes unitários cubram a base para reduzir a necessidade de regressão manual exaustiva (Shift-Left).

Ferramentas de Apoio

• Manuais: Seguir os roteiros desta seção no Confluence.

• Automatizados: Ver seção de Automação para scripts que validam APIs de forma contínua.

💡 Dica para o QA:

Sempre que encontrar um bug que "já estava funcionando antes", esse cenário deve se tornar obrigatoriamente um novo item na nossa lista de regressão para que não volte a acontecer (Bug de Regressão).