Estrategia de Testes - Contrasync

Escopo

Este documento define a estrategia geral de Quality Assurance do Contrasync, incluindo niveis de teste, ambientes, gestao de dados de teste, abordagem de regressao e definicoes de severidade e prioridade.

Niveis de teste

Testes unitarios

• Ferramenta: Vitest
• Alvo: Funcoes utilitarias, composables, stores (Pinia), validacoes
• Cobertura minima: 80% para logica de negocio
• Responsavel: Desenvolvedores
• Execucao: A cada commit (CI/CD)

Testes de integracao

• Ferramenta: Vitest + Vue Test Utils
• Alvo: Interacao entre componentes, chamadas a servicos com MSW
• Cobertura minima: Fluxos criticos de cada modulo
• Responsavel: Desenvolvedores
• Execucao: A cada pull request

Testes end-to-end (E2E)

• Ferramenta: Cypress ou Playwright
• Alvo: Fluxos completos do usuario (login ate assinatura)
• Cobertura minima: Caminhos criticos (happy path + principais erros)
• Responsavel: QA / Desenvolvedores
• Execucao: Antes de cada release

Testes manuais

• Alvo: Usabilidade, design, responsividade, exploratorio
• Responsavel: QA
• Execucao: Sprints de QA, antes de releases

Ambientes de teste

Ambiente	Dados	API	Proposito
Local (MSW)	Mocks locais	MSW intercepta	Desenvolvimento rapido, testes unitarios
Desenvolvimento	Banco de dados de dev	API real (dev)	Integracao continua, testes de integracao
Staging	Banco espelhado	API real (staging)	Validacao pre-release, testes E2E
Producao	Dados reais	API real (prod)	Smoke tests pos-deploy

Estrategia de dados de teste

MSW (Mock Service Worker)

• Mocks definidos em src/mocks/handlers/ e src/mocks/data/
• Cobrem cenarios de sucesso e erro para cada endpoint
• Dados consistentes entre si (IDs, referencias)
• Resetados a cada execucao de teste

Dados de teste em ambientes reais

• Usuarios de teste com roles definidos (provider, borrower, user)
• Empresas de teste com CNPJs validos para teste
• Templates pre-criados para fluxos de contrato
• Workflows configurados para cada cenario

Regras de dados de teste

• Nunca usar dados reais de clientes em ambientes de teste
• CPFs e CNPJs devem ser numeros validos mas ficticios
• Emails de teste devem usar dominio @teste.contrasync.com
• Dados de teste devem ser limpos semanalmente em ambientes compartilhados

Abordagem de regressao

Regressao automatizada

• Suite de testes E2E executada antes de cada release
• Testes unitarios executados em CI a cada commit
• Testes de integracao executados em CI a cada pull request

Regressao manual

• Checklist de regressao documentado em checklist-regressao.md
• Executado antes de releases maiores
• Foco em caminhos criticos e integracoes entre modulos

Priorizacao de regressao

1. Autenticacao e seguranca - Sempre testar
2. Contratos (fluxo completo) - Sempre testar
3. Assinatura - Sempre testar
4. Modulos afetados pela mudanca - Testar especificamente
5. Demais modulos - Smoke test

Definicoes de severidade de bugs

Severidade	Descricao	Exemplo	SLA de correcao
Critica (S1)	Sistema inacessivel ou perda de dados	Login quebrado, contrato salvo com dados corrompidos	4 horas
Alta (S2)	Funcionalidade principal bloqueada, sem workaround	Nao consegue criar contrato, assinatura falha	24 horas
Media (S3)	Funcionalidade impactada, com workaround	Filtro de pesquisa nao funciona, mas listagem exibe todos	1 semana
Baixa (S4)	Problema cosmetico ou de usabilidade menor	Texto desalinhado, cor errada em dark mode	Proximo sprint

Definicoes de prioridade

Prioridade	Descricao
P1 - Urgente	Impacta producao ou bloqueia release. Correcao imediata.
P2 - Alta	Funcionalidade critica afetada. Correcao na sprint atual.
P3 - Media	Funcionalidade secundaria afetada. Proximo sprint.
P4 - Baixa	Melhoria ou bug cosmetico. Backlog.

Definition of Done para QA

Uma funcionalidade e considerada validada quando:

• [ ] Todos os cenarios de teste do plano foram executados
• [ ] Todos os cenarios de prioridade Alta passaram
• [ ] Cenarios negativos foram testados
• [ ] Casos extremos foram verificados
• [ ] Funcionalidade testada em dark mode e light mode
• [ ] Funcionalidade testada nos idiomas pt-BR e en
• [ ] Responsividade verificada (desktop e tablet, no minimo)
• [ ] Nenhum bug de severidade Critica ou Alta em aberto
• [ ] Testes de regressao nos modulos impactados passaram
• [ ] Evidencias de teste documentadas (screenshots/videos quando aplicavel)

Metricas de QA

• Cobertura de testes automatizados (%)
• Numero de bugs encontrados por sprint
• Bugs encontrados em producao vs. staging
• Tempo medio de correcao por severidade
• Taxa de regressao (bugs que retornam)