Plano de Testes - Sport Tech Club

Versão: 1.0.0
Data: 2026-01-09
Status: Em Vigor
Responsável QA: Quality (Senior QA Engineer)

Sumário

1. Introdução
2. Estratégia de Testes
3. Ambiente de Testes
4. Casos de Teste por Módulo
5. Testes de Performance
6. Testes de Segurança
7. Testes de Acessibilidade
8. Automação
9. Cronograma e Recursos
10. Riscos e Mitigações

1. Introdução

1.1 Escopo

Este plano de testes abrange todas as funcionalidades do Sport Tech Club, uma plataforma SaaS multi-tenant para gestão de arenas esportivas, com foco em:

Gestão de arenas e quadras
Sistema de reservas e agendamento
Fila dinâmica e alocação inteligente
Controle de acesso e presença
Pagamentos e wallet digital
Gamificação e rankings
Vídeo e IoT

Fora de Escopo (Fase 1):

Testes de hardware IoT físico (apenas integração simulada)
Patrocínio e anúncios (Fase 3)
Analytics avançado com ML (Fase 3)

1.2 Objetivos

Objetivos Primários:

Garantir 100% de cobertura das funcionalidades MVP
Atingir >= 80% de code coverage em todos os módulos
Detectar e corrigir bugs críticos antes do deploy
Validar segurança e isolamento multi-tenant
Garantir performance adequada (p95 < 500ms)

Objetivos Secundários:

Estabelecer baseline de performance para otimizações futuras
Documentar casos de teste como especificação viva
Automatizar 90% dos testes de regressão
Habilitar continuous testing no CI/CD

1.3 Critérios de Entrada

Antes de iniciar os testes, os seguintes critérios devem ser atendidos:

[ ] Código fonte commitado e build gerado com sucesso
[ ] Ambiente de testes configurado e disponível
[ ] Dados de teste (seed) carregados
[ ] Documentação técnica (API specs) disponível
[ ] User stories com critérios de aceitação definidos
[ ] Testes unitários executados com sucesso (coverage >= 70%)

1.4 Critérios de Saída

Os testes podem ser considerados concluídos quando:

[ ] 100% dos casos de teste críticos executados
[ ] 0 bugs críticos abertos
[ ] <= 5 bugs médios abertos (com plano de correção)
[ ] Code coverage >= 80%
[ ] Performance: p95 < 500ms, p99 < 1s
[ ] Testes de segurança: 0 vulnerabilidades críticas/altas
[ ] Relatório de testes aprovado pelo Product Owner

1.5 Definições de Severidade

Severidade	Descrição	SLA Correção
Crítica	Sistema inoperante, perda de dados, violação de segurança	24h
Alta	Funcionalidade principal quebrada, workaround difícil	72h
Média	Funcionalidade secundária afetada, workaround existe	1 semana
Baixa	Problema cosmético, sem impacto funcional	Backlog

2. Estratégia de Testes

2.1 Níveis de Teste

2.1.1 Testes Unitários (Unit Tests)

Ferramenta: Jest (Node.js) / Vitest (futuros serviços)
Objetivo: Validar lógica de negócio isolada
Responsável: Developers (TDD obrigatório)
Meta de Coverage: >= 80% (>= 90% para Core Domains)

Escopo:

Domain Entities e Value Objects
Use Cases / Application Services
Domain Services
Validações e regras de negócio
Cálculos e algoritmos

Exemplo:

typescript

// courts-service/src/domain/entities/court.spec.ts
describe('Court Entity', () => {
  it('should allocate court when available', () => {
    const court = Court.create({ status: CourtStatus.AVAILABLE });
    const result = court.allocate(players);
    expect(result.success).toBe(true);
  });
});

2.1.2 Testes de Integração (Integration Tests)

Ferramenta: Supertest + Jest
Objetivo: Validar comunicação entre módulos
Responsável: QA + Developers
Meta de Coverage: >= 70%

Escopo:

APIs REST (controllers + services + repositories)
Integração com banco de dados
Integração com message broker (RabbitMQ)
Integração com cache (Redis)
Integração com serviços externos (mocks)

Exemplo:

typescript

describe('POST /v1/courts', () => {
  it('should create court with valid data', async () => {
    const response = await request(app)
      .post('/v1/courts')
      .set('Authorization', `Bearer ${token}`)
      .send({ name: 'Court 1', sport: 'BEACH_TENNIS' })
      .expect(201);
      
    expect(response.body.id).toBeDefined();
  });
});

2.1.3 Testes End-to-End (E2E)

Ferramenta: Playwright + Cucumber (BDD)
Objetivo: Validar jornadas completas do usuário
Responsável: QA
Meta de Coverage: 100% dos fluxos críticos

Escopo:

Jornadas de usuário completas
Multi-browser testing (Chrome, Firefox, Safari)
Mobile responsive
Integração entre todos os componentes

Exemplo:

gherkin

@smoke @booking
Scenario: Create booking successfully
  Given I am logged in as a player
  When I select court "Court 1" for "2024-03-15 18:00"
  And I confirm the booking
  Then I should see "Booking confirmed"
  And I should receive confirmation email

2.1.4 Testes de Performance (Load/Stress)

Ferramenta: k6
Objetivo: Validar comportamento sob carga
Responsável: QA + DevOps

Escopo:

Load testing (carga esperada)
Stress testing (carga acima do esperado)
Soak testing (carga prolongada)
Spike testing (picos repentinos)

Cenários:

100 usuários simultâneos (load)
500 usuários simultâneos (stress)
24h de operação contínua (soak)

2.1.5 Testes de Segurança

Ferramenta: OWASP ZAP + Snyk
Objetivo: Identificar vulnerabilidades
Responsável: Security + QA

Escopo:

OWASP Top 10
Penetration testing
Dependency scanning
Multi-tenant isolation
Authentication/Authorization

2.2 Tipos de Teste

Tipo	Descrição	Quando Executar
Funcional	Valida requisitos funcionais	Toda build
Regressão	Valida que fixes não quebraram funcionalidades existentes	Após cada bug fix
Smoke	Testes básicos de sanidade	Deploy em qualquer ambiente
Sanity	Validação rápida após pequena mudança	Hotfix, patch
UAT	Validação com usuários reais	Antes de produção
A/B	Comparação entre versões (features)	Experimentos

2.3 Pirâmide de Testes

         /\
        /  \
       / E2E \        <- 10% (50 cenários BDD)
      /______\
     /        \
    / Integration\   <- 20% (300 testes API)
   /______________\
  /                \
 /   Unit Tests     \ <- 70% (1500+ testes)
/____________________\

Distribuição Recomendada:

Tipo	%	Quantidade Estimada	Tempo Execução
Unit	70%	1500+ testes	< 2min
Integration	20%	300 testes	5-10min
E2E	10%	50 cenários	15-30min

Justificativa:

Testes unitários são rápidos e detectam bugs na origem
Testes de integração validam contratos entre módulos
Testes E2E garantem experiência do usuário, mas são custosos

3. Ambiente de Testes

3.1 Ambientes

Development (Local)

Propósito: Desenvolvimento e debug
Infraestrutura: Docker Compose
Dados: Seed com dados mínimos

yaml

services:
  - PostgreSQL 16
  - Redis 7
  - RabbitMQ 3.12
  - Keycloak 23

URL: http://localhost:3000

Staging (Pré-Produção)

Propósito: Testes de integração e UAT
Infraestrutura: Kubernetes (cluster dedicado)
Dados: Seed com dados realistas (anonimizados)

URL: https://staging.sport-tech-club.com

Características:

Réplica exata de produção
Dados anonimizados de produção (refresh semanal)
Feature flags habilitados
Integração com gateways de pagamento em sandbox

Production (Produção)

Propósito: Operação real
Infraestrutura: Kubernetes (cluster multi-AZ)
Dados: Dados reais

URL: https://app.sport-tech-club.com

Testes Permitidos:

Smoke tests pós-deploy
Synthetic monitoring
Canary deployments com percentual de tráfego

3.2 Dados de Teste

Seed Data (Development/Staging)

Arenas:

Arena Beach Sports (3 quadras de beach tennis)
Futevôlei Club (2 quadras de futevôlei)

Usuários:

Admin: admin@test.com / Admin@123
Operador: operador@test.com / Operador@123
Jogador 1: jogador1@test.com / Jogador@123
Jogador 2: jogador2@test.com / Jogador@123
Professor: professor@test.com / Professor@123

Quadras:

Court 1 - Beach Tennis (disponível)
Court 2 - Beach Tennis (ocupada)
Court 3 - Beach Tennis (manutenção)
Court 4 - Futevôlei (disponível)
Court 5 - Futevôlei (reservada)

Reservas:

10 reservas futuras
5 reservas em andamento
20 reservas passadas

3.3 Mocks e Stubs

Serviços Externos Mockados:

Serviço	Ferramenta	Escopo
Gateway Pagamento (Stripe)	stripe-mock	Integração
Email (SendGrid)	Mailtrap	E2E
SMS (Twilio)	Twilio Sandbox	E2E
Storage (S3)	LocalStack	Integração
Maps API (Google)	Mock Server	Integração

Factory Helpers:

typescript

// tests/factories/court.factory.ts
export const createTestCourt = (overrides?: Partial<Court>) => {
  return Court.create({
    name: 'Test Court',
    sport: Sport.BEACH_TENNIS,
    status: CourtStatus.AVAILABLE,
    ...overrides
  });
};

3.4 Feature Flags

Ferramenta: LaunchDarkly / Flagsmith

Uso em Testes:

Testar features em desenvolvimento sem afetar usuários
A/B testing controlado
Rollback instantâneo em caso de problemas

Exemplo:

typescript

if (await featureFlags.isEnabled('new-allocation-algorithm', { userId })) {
  return newAllocationEngine.allocate();
} else {
  return legacyAllocationEngine.allocate();
}

4. Casos de Teste por Módulo

Total de casos de teste documentados: 240+

4.1 Autenticação e Autorização (30 casos)

Prioridade: Crítica | Tipo: Funcional, Smoke | Automatizado: Sim (E2E)

Pré-condições:

Usuário cadastrado com email "jogador@test.com" e senha "Jogador@123"

Passos:

Acessar página de login
Preencher email: "jogador@test.com"
Preencher senha: "Jogador@123"
Clicar em "Entrar"

Resultado Esperado:

Redirecionar para página inicial
Exibir nome do usuário no menu
Token JWT armazenado no localStorage

Prioridade: Alta | Tipo: Funcional, Negativo | Automatizado: Sim (E2E)

Prioridade: Alta | Tipo: Funcional, Negativo, Segurança | Automatizado: Sim (E2E)

TC-AUTH-004: Bloqueio após 5 Tentativas Falhas

Prioridade: Crítica | Tipo: Segurança | Automatizado: Sim (Integration)

Prioridade: Alta | Tipo: Funcional, Segurança | Automatizado: Sim (E2E)

TC-AUTH-006: Recuperação de Senha

Prioridade: Alta | Tipo: Funcional | Automatizado: Sim (E2E)

TC-AUTH-007: RBAC - Acesso Admin

Prioridade: Crítica | Tipo: Segurança, Autorização | Automatizado: Sim (Integration)

Passos:

Autenticar como usuário com role "PLAYER"
Tentar acessar endpoint /api/admin/users

Resultado Esperado:

HTTP 403 Forbidden
Mensagem: "Acesso negado"
Log de tentativa de acesso não autorizado

TC-AUTH-008: Multi-Tenant Isolation

Prioridade: Crítica | Tipo: Segurança, Multi-tenant | Automatizado: Sim (Integration)

Passos:

Autenticar como usuário da Arena A
Tentar acessar dados da Arena B via API

Resultado Esperado:

HTTP 403 Forbidden ou 404 Not Found
Nenhum dado da Arena B retornado
Query auditada com tenantId errado

TC-AUTH-009: Token JWT Expirado

Prioridade: Alta | Tipo: Funcional, Segurança | Automatizado: Sim (Integration)

TC-AUTH-010: Refresh Token

Prioridade: Alta | Tipo: Funcional | Automatizado: Sim (Integration)

Casos adicionais (TC-AUTH-011 a TC-AUTH-030):

Logout
Social login (Google, Facebook)
Password policy validation
Account activation
Password reset link expiration
Session management
Concurrent sessions
Device trust
IP whitelist/blacklist
Biometric authentication (mobile)
SSO integration
API key authentication
OAuth2 flows
Account lockout
Password history
Two-factor recovery codes
Email verification
Phone verification
CAPTCHA on suspicious activity
Audit log de autenticação

4.2 Gestão de Arenas e Quadras (25 casos)

TC-ARENA-001: Cadastrar Arena

Prioridade: Crítica | Tipo: Funcional, Smoke | Automatizado: Sim (Integration)

TC-ARENA-002: Cadastrar Arena com CNPJ Inválido

Prioridade: Alta | Tipo: Funcional, Negativo, Validação | Automatizado: Sim (Integration)

TC-COURT-001: Cadastrar Quadra

Prioridade: Crítica | Tipo: Funcional | Automatizado: Sim (Integration)

TC-COURT-002: Listar Quadras Disponíveis

Prioridade: Alta | Tipo: Funcional | Automatizado: Sim (Integration)

TC-COURT-003: Atualizar Status da Quadra

Prioridade: Alta | Tipo: Funcional | Automatizado: Sim (Integration)

TC-COURT-004: Bloquear Horário para Manutenção

Prioridade: Alta | Tipo: Funcional | Automatizado: Sim (E2E)

TC-COURT-005: Validar Capacidade Máxima

Prioridade: Média | Tipo: Funcional, Validação | Automatizado: Sim (Unit)

Casos adicionais (TC-ARENA/COURT-006 a TC-ARENA/COURT-025):

Editar arena
Desativar arena
Upload de fotos da arena
Configurar horário de funcionamento
Configurar feriados
Criar zonas de acesso
Editar quadra
Desativar quadra
Configurar preços por horário
Configurar regras de uso
Definir tipos de jogo suportados
Configurar níveis permitidos
Upload de fotos da quadra
Associar amenidades
Configurar iluminação
Multi-quadras (visualização)
Histórico de manutenções
Calendário de disponibilidade
Reservas bloqueadas vs livres

4.3 Reservas e Agendamento (40 casos)

TC-BOOKING-001: Criar Reserva Simples

Prioridade: Crítica | Tipo: Funcional, Smoke | Automatizado: Sim (E2E)

Passos:

Autenticar como jogador
Selecionar quadra "Quadra 1 - Beach Tennis"
Selecionar data: 2024-03-15
Selecionar horário: 18:00
Duração: 1 hora
Confirmar reserva
Pagar com PIX

Resultado Esperado:

Reserva criada com status PENDING_PAYMENT
QR Code PIX exibido
Após pagamento confirmado: status = CONFIRMED
Email de confirmação enviado
Evento BookingCreated publicado

TC-BOOKING-002: Verificar Disponibilidade em Tempo Real

Prioridade: Alta | Tipo: Funcional | Automatizado: Sim (E2E)

TC-BOOKING-003: Reserva com Conflito de Horário

Prioridade: Alta | Tipo: Funcional, Negativo | Automatizado: Sim (Integration)

Passos:

Criar reserva para Quadra 1 em 2024-03-15 18:00
Tentar criar segunda reserva para mesma quadra e horário

Resultado Esperado:

HTTP 409 Conflict
Erro: "Horário não disponível"
Sugestões de horários alternativos

TC-BOOKING-004: Reserva Recorrente Semanal

Prioridade: Média | Tipo: Funcional | Automatizado: Sim (Integration)

TC-BOOKING-005: Adicionar Participantes

Prioridade: Média | Tipo: Funcional | Automatizado: Sim (E2E)

TC-BOOKING-006: Cancelar Reserva com Antecedência

Prioridade: Alta | Tipo: Funcional | Automatizado: Sim (Integration)

TC-BOOKING-007: Cancelar Reserva em Cima da Hora

Prioridade: Alta | Tipo: Funcional, Regra de Negócio | Automatizado: Sim (Integration)

TC-BOOKING-008: No-Show

Prioridade: Alta | Tipo: Funcional, Regra de Negócio | Automatizado: Sim (Integration)

TC-BOOKING-009: Check-in na Reserva

Prioridade: Crítica | Tipo: Funcional | Automatizado: Sim (E2E)

TC-BOOKING-010: Listar Minhas Reservas

Prioridade: Alta | Tipo: Funcional | Automatizado: Sim (E2E)

Casos adicionais (TC-BOOKING-011 a TC-BOOKING-040):

Editar reserva
Transferir reserva
Day-use booking
Pacote de reservas
Reserva com desconto (cupom)
Reserva para múltiplas quadras
Reserva de evento
Waitlist para horário cheio
Notificação de horário liberado
Lembrete de reserva
Late check-in
Early checkout
Extend booking
Partial refund
Full refund
Charge no-show fee
Rating após reserva
Review de quadra
Upload de fotos após jogo
Share booking with friends
Invite to booking
Accept/decline invite
Booking history
Favorite courts
Recurring booking patterns
Smart suggestions
Peak hours pricing
Off-peak discounts
Group bookings
Corporate bookings

4.4 Fila e Alocação Dinâmica (30 casos)

TC-QUEUE-001: Entrar na Fila

Prioridade: Crítica | Tipo: Funcional | Automatizado: Sim (E2E)

TC-QUEUE-002: Receber Notificação de Chamada

Prioridade: Crítica | Tipo: Funcional, Real-time | Automatizado: Sim (E2E)

TC-QUEUE-003: Perder Vez por Timeout

Prioridade: Alta | Tipo: Funcional, Regra de Negócio | Automatizado: Sim (Integration)

TC-QUEUE-004: Sair da Fila Voluntariamente

Prioridade: Média | Tipo: Funcional | Automatizado: Sim (E2E)

TC-QUEUE-005: Regra Ganha-Fica

Prioridade: Crítica | Tipo: Funcional, Regra de Negócio, Core | Automatizado: Sim (Integration)

Pré-condições:

Quadra configurada com regra "Winner Stays"
Limite de vitórias consecutivas = 3

Passos:

Time A vence Time B
Registrar placar: Time A 6 x 4 Time B

Resultado Esperado:

Time A permanece na quadra
Time B volta ao fim da fila
Próximo time da fila é chamado para enfrentar Time A
Contador de vitórias consecutivas de Time A = 1

TC-QUEUE-006: Limite de Vitórias Consecutivas Atingido

Prioridade: Alta | Tipo: Funcional, Regra de Negócio | Automatizado: Sim (Integration)

TC-QUEUE-007: Prioridade na Fila por Perfil

Prioridade: Média | Tipo: Funcional, Regra de Negócio | Automatizado: Sim (Unit + Integration)

TC-QUEUE-008: Override Manual da Fila

Prioridade: Alta | Tipo: Funcional, Auditoria | Automatizado: Sim (E2E)

TC-QUEUE-009: Motor de Alocação - Balanceamento de Times

Prioridade: Alta | Tipo: Funcional, Core, Algoritmo | Automatizado: Sim (Unit)

Passos:

4 jogadores na fila com níveis: PRO, ADVANCED, INTERMEDIATE, BEGINNER
Alocar para jogo 2x2

Resultado Esperado:

Times balanceados: (PRO + BEGINNER) vs (ADVANCED + INTERMEDIATE)
Match quality score calculado
Algoritmo de matching aplicado

TC-QUEUE-010: Fila Vazia - Liberar Quadra

Prioridade: Média | Tipo: Funcional | Automatizado: Sim (Integration)

Casos adicionais (TC-QUEUE-011 a TC-QUEUE-030):

Fila por esporte
Fila por nível
Fila mista (gênero)
Multiple queues per court
Queue position indicator
Estimated wait time
Queue abandonment
Queue reordering
Priority boost
VIP queue
Group in queue
Solo in queue
Pair matching
Skill-based matching
Random matching
Challenge system
Queue notifications
Queue analytics
Historical wait times
Peak queue times

4.5 Pagamentos (25 casos)

TC-PAY-001: Pagar com PIX

Prioridade: Crítica | Tipo: Funcional, Smoke, Integração | Automatizado: Sim (E2E com mock)

TC-PAY-002: Pagar com Cartão de Crédito

Prioridade: Crítica | Tipo: Funcional, Integração | Automatizado: Sim (E2E com mock)

TC-PAY-003: Falha no Pagamento com Cartão

Prioridade: Alta | Tipo: Funcional, Negativo | Automatizado: Sim (E2E com mock)

TC-PAY-004: Aplicar Cupom de Desconto

Prioridade: Média | Tipo: Funcional | Automatizado: Sim (E2E)

TC-PAY-005: Reembolso

Prioridade: Alta | Tipo: Funcional, Financeiro | Automatizado: Sim (Integration)

TC-PAY-006: Pagamento Recorrente (Mensalidade)

Prioridade: Alta | Tipo: Funcional, Recorrência | Automatizado: Sim (Integration)

TC-PAY-007: Webhook de Pagamento

Prioridade: Crítica | Tipo: Integração, Async | Automatizado: Sim (Integration)

Passos:

Criar pagamento
Simular webhook de confirmação do gateway
Processar webhook

Resultado Esperado:

Idempotência: processar apenas uma vez
Status atualizado
Eventos internos disparados
Retry em caso de falha de processamento

TC-PAY-008: Timeout de Pagamento

Prioridade: Média | Tipo: Funcional, Timeout | Automatizado: Sim (Integration)

TC-PAY-009: Split de Pagamento

Prioridade: Média | Tipo: Funcional, Split Payment | Automatizado: Sim (Integration)

TC-PAY-010: Multi-Tenant - Isolamento de Pagamentos

Prioridade: Crítica | Tipo: Segurança, Multi-tenant | Automatizado: Sim (Integration)

Casos adicionais (TC-PAY-011 a TC-PAY-025):

Boleto bancário
Cartão de débito
Carteiras digitais (PicPay, Mercado Pago)
Parcelamento
Juros de parcelamento
Cashback
Loyalty points
Gift cards
Promotional credits
Pending payment reminder
Payment receipt
Invoice generation
Tax calculation
Currency conversion
International payments

4.6 Wallet e Tokens (20 casos)

TC-WALLET-001: Criar Carteira para Usuário

TC-WALLET-002: Creditar Wallet

TC-WALLET-003: Debitar Wallet

TC-WALLET-004: Saldo Insuficiente

TC-WALLET-005: Transferência P2P

TC-WALLET-006: Apostas em Partida

TC-WALLET-007: Cashback em Consumo

TC-WALLET-008: Event Sourcing - Rebuild de Estado

TC-WALLET-009: Idempotência de Transações

TC-WALLET-010: Congelamento de Wallet

Casos adicionais (TC-WALLET-011 a TC-WALLET-020):

Transaction history
Balance inquiry
Multiple currencies
Token purchase
Token redemption
Wallet statements
Transaction disputes
Refund to wallet
Wallet freeze/unfreeze
Wallet limits

4.7 Gamificação (20 casos)

TC-GAMIF-001: Ganhar XP ao Completar Partida

TC-GAMIF-002: Subir de Nível

TC-GAMIF-003: Desbloquear Conquista

TC-GAMIF-004: Ranking Global

TC-GAMIF-005: Streak de Atividade

Casos adicionais (TC-GAMIF-006 a TC-GAMIF-020):

Badges
Leaderboards
Weekly challenges
Seasonal events
Achievements
Milestones
Trophies
Titles
Profile customization
Social sharing
Friend challenges
Tournament badges
Rare achievements
Hidden achievements
Progress tracking

4.8 Outros Módulos (50 casos)

Acesso e Presença: 10 casos Professores e Aulas: 10 casos Eventos: 10 casos Vídeo e Mídia: 5 casos Analytics e Relatórios: 10 casos Notificações: 5 casos

5. Testes de Performance

5.1 Cenários de Carga

PERF-001: Load Testing - Uso Normal

Ferramenta: k6
Objetivo: Validar performance sob carga esperada

Cenário:

javascript

// tests/performance/load-test.js
export const options = {
  stages: [
    { duration: '2m', target: 50 },   // Ramp-up
    { duration: '5m', target: 100 },  // Stay at 100
    { duration: '2m', target: 0 },    // Ramp-down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1000'],
    http_req_failed: ['rate<0.01'],
  },
};

Endpoints Testados:

GET /api/v1/courts (listar quadras)
POST /api/v1/bookings (criar reserva)
GET /api/v1/queue (consultar fila)
POST /api/v1/access/checkin (check-in)

Métricas Alvo:

p95 < 500ms
p99 < 1s
Taxa de erro < 1%
Throughput: >= 100 req/s

PERF-002: Stress Testing - Pico de Acesso

Cenário:

Evento especial (torneio)
500 usuários simultâneos

Configuração:

javascript

export const options = {
  stages: [
    { duration: '1m', target: 200 },
    { duration: '3m', target: 500 },  // Stress
    { duration: '1m', target: 0 },
  ],
};

Objetivo:

Identificar ponto de quebra
Validar graceful degradation
Testar auto-scaling (K8s HPA)

PERF-003: Soak Testing - Operação Prolongada

Cenário:

50 usuários por 24h

Objetivo:

Detectar memory leaks
Validar estabilidade
Testar garbage collection

PERF-004: Spike Testing - Pico Repentino

Objetivo:

Validar elasticidade
Testar circuit breakers
Validar rate limiting

5.2 Baseline Metrics

Infraestrutura Base:

2x pods (2 CPU, 4GB RAM cada)
PostgreSQL (db.t3.medium)
Redis (cache.t3.small)

Performance Esperada:

Endpoint	p50	p95	p99
GET /courts	50ms	200ms	400ms
POST /bookings	100ms	400ms	800ms
GET /queue	30ms	150ms	300ms
POST /checkin	80ms	300ms	600ms
WebSocket (latência)	10ms	50ms	100ms

5.3 Database Performance

Queries Críticas:

sql

-- Listar quadras disponíveis
SELECT * FROM courts 
WHERE tenant_id = $1 
  AND status = 'AVAILABLE';
-- Alvo: < 50ms

-- Consultar fila
SELECT * FROM queue_entries 
WHERE court_id = $1 
ORDER BY priority DESC, created_at ASC;
-- Alvo: < 30ms

Índices Críticos:

sql

CREATE INDEX idx_courts_tenant_status ON courts(tenant_id, status);
CREATE INDEX idx_bookings_user_tenant ON bookings(user_id, tenant_id, start_time DESC);
CREATE INDEX idx_queue_court_priority ON queue_entries(court_id, priority DESC, created_at ASC);

5.4 Cache Performance

Objetivo: >= 80% cache hit rate

Dados Cacheados:

Listagem de quadras (TTL: 5min)
Configurações da arena (TTL: 1h)
Perfis de usuário (TTL: 15min)

Estratégia:

Cache-aside pattern
Invalidação via eventos

6. Testes de Segurança

6.1 OWASP Top 10

SEC-001: Injection (SQL, NoSQL, Command)

Teste:

Tentar SQL injection em todos os inputs
Exemplo: email = "admin' OR '1'='1"

Mitigação:

Usar ORM (Prisma) com queries parametrizadas
Input validation
Prepared statements

Ferramenta: OWASP ZAP + manual testing

SEC-002: Broken Authentication

Testes:

Brute force em login (deve bloquear após 5 tentativas)
Session fixation
Weak password policy

Mitigação:

Rate limiting
MFA
Strong password policy (min 8 chars, uppercase, lowercase, number, special)
Session rotation

SEC-003: Sensitive Data Exposure

Testes:

Senhas em plain text? (NÃO)
Dados sensíveis em logs?
HTTPS obrigatório?
Tokens em URLs?

Mitigação:

Bcrypt para senhas (salt rounds: 12)
TLS 1.3
Secrets em Vault
PII masking em logs

SEC-005: Broken Access Control

Testes:

Acesso horizontal: Usuário A acessar dados de Usuário B
Acesso vertical: PLAYER acessar endpoint de ADMIN
IDOR: Modificar IDs em URLs

Mitigação:

RBAC rigoroso
Verificação de tenantId em TODAS as queries
Row Level Security (RLS) no PostgreSQL

Casos de Teste:

TC-SEC-005A: Tentar acessar booking de outro usuário
TC-SEC-005B: PLAYER tentar DELETE /api/admin/users
TC-SEC-005C: Modificar arenaId em request

SEC-007: Cross-Site Scripting (XSS)

Testes:

Stored XSS: <script>alert('XSS')</script> em nome de quadra
Reflected XSS: parâmetro de URL
DOM-based XSS

Mitigação:

Sanitização de inputs (DOMPurify)
CSP (Content Security Policy)
Output encoding

SEC-009: Using Components with Known Vulnerabilities

Ferramenta: Snyk, npm audit

Processo:

Scan diário de dependências
Atualização automática de patches
Bloqueio de deploy com vulnerabilidades críticas/altas

bash

npm audit --audit-level=high
snyk test

6.2 Multi-Tenant Security

SEC-TENANT-001: Data Isolation

Teste:

typescript

// Tentar acessar dados de outro tenant
const response = await request(app)
  .get('/api/v1/bookings')
  .set('Authorization', bearerTokenTenantA)
  .set('X-Tenant-ID', 'tenant-B'); // Manipulação maliciosa

// Esperado: 403 Forbidden

Mitigação:

Token JWT contém tenantId
Server-side validation obrigatória
Row Level Security no DB

SEC-TENANT-002: Cross-Tenant Leakage

Exemplo de Vulnerabilidade:

sql

-- ERRADO (vulnerável)
SELECT * FROM bookings WHERE user_id = $1;

-- CORRETO
SELECT * FROM bookings WHERE user_id = $1 AND tenant_id = $2;

Mitigação:

Prisma middleware que injeta tenantId automaticamente
Code review obrigatório
Testes automatizados

6.3 API Security

SEC-API-001: Rate Limiting

Configuração:

typescript

// Global rate limit
@ThrottlerGuard({ limit: 100, ttl: 60 })

// Auth endpoint rate limit (mais restritivo)
@ThrottlerGuard({ limit: 5, ttl: 60 })

Teste:

Enviar 101 requests em 1 minuto
Esperado: HTTP 429 Too Many Requests

SEC-API-002: CORS

Configuração:

typescript

app.enableCors({
  origin: ['https://app.sport-tech-club.com'],
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'PATCH', 'DELETE'],
});

Teste:

Request de origem não autorizada
Esperado: CORS error

6.4 Penetration Testing

Frequência: Trimestral (ou antes de releases maiores)

Escopo:

APIs públicas
Aplicações web
Autenticação
Multi-tenancy

Ferramenta: OWASP ZAP (automated) + manual testing

Deliverable: Relatório de vulnerabilidades com severidades e plano de correção

7. Testes de Acessibilidade

7.1 WCAG 2.1 Level AA

Objetivo: Conformidade com WCAG 2.1 AA

ACC-001: Perceivable (Perceptível)

1.1 Text Alternatives:

Todas as imagens têm alt text
Ícones têm aria-label

1.3 Adaptable:

Conteúdo faz sentido sem CSS
Ordem de leitura lógica
Landmarks semânticos (header, nav, main, footer)

1.4 Distinguishable:

Contraste mínimo 4.5:1 para texto normal
Contraste mínimo 3:1 para texto grande
Texto redimensionável até 200%
Sem informação apenas por cor

ACC-002: Operable (Operável)

2.1 Keyboard Accessible:

Todas as funcionalidades acessíveis por teclado
Tab order lógico
Sem keyboard traps

Teste:

1. Navegar página inteira usando apenas Tab/Shift+Tab
2. Ativar botões usando Enter/Space
3. Fechar modals usando Esc

Ferramentas:

NVDA (Windows)
JAWS (Windows)
VoiceOver (macOS, iOS)
TalkBack (Android)

Cenários de Teste:

Login
Criar reserva
Navegar calendário
Receber notificação

Checklist:

Todos os elementos interativos anunciados
Estado dos elementos (expandido/colapsado, selecionado)
Erros de validação lidos
Loading states anunciados

Teste Manual:

Tab: próximo elemento
Shift+Tab: elemento anterior
Enter/Space: ativar botão
Esc: fechar modal
Arrow keys: navegar listas/menus

Todos os componentes devem ser operáveis:

[ ] Botões
[ ] Links
[ ] Inputs
[ ] Dropdowns
[ ] Modals
[ ] Date pickers
[ ] Carousels

7.4 Automated Testing

Ferramenta: axe-core (integrado com Playwright)

typescript

// tests/e2e/accessibility.spec.ts
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('homepage should not have accessibility violations', async ({ page }) => {
  await page.goto('/');
  
  const accessibilityScanResults = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa'])
    .analyze();
  
  expect(accessibilityScanResults.violations).toEqual([]);
});

Execução: A cada pull request

8. Automação

8.1 CI/CD Integration

Pipeline (GitHub Actions):

yaml

name: Tests

on: [push, pull_request]

jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 20
      - run: npm ci
      - run: npm run test:unit -- --coverage
      - uses: codecov/codecov-action@v3

  integration:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: postgres
      redis:
        image: redis:7
      rabbitmq:
        image: rabbitmq:3.12
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - run: npm run test:integration

  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npm run test:e2e
      - uses: actions/upload-artifact@v3
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm audit --audit-level=high
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

8.2 Test Reporting

Ferramenta: Allure Report

Geração:

bash

npm run test:e2e -- --reporter=allure
allure generate allure-results --clean -o allure-report
allure open allure-report

Informações no Relatório:

Total de testes executados
Pass rate
Tempo de execução
Screenshots de falhas
Logs
Video recordings (E2E)
Trends (histórico)

8.3 Coverage Requirements

Meta Global: >= 80%

Por Tipo de Código:

Tipo	Coverage Mínimo
Domain Entities	90%
Use Cases	85%
Controllers	70%
Repositories	75%
Utils	80%

Configuração (jest.config.js):

javascript

module.exports = {
  coverageThreshold: {
    global: {
      branches: 80,
      functions: 80,
      lines: 80,
      statements: 80
    },
    './src/domain/**/*.ts': {
      branches: 90,
      functions: 90,
      lines: 90,
      statements: 90
    }
  }
};

Bloqueio de Deploy:

Se coverage < 80%: Build FALHARÁ
Exceções via waiver (justificativa obrigatória)

8.4 Parallel Execution

Unit Tests:

Executar todos em paralelo (jest workers = CPU cores)

Integration Tests:

Paralelo com isolamento de banco (database per worker)

E2E Tests:

Playwright parallel workers: 4
Shard tests em diferentes máquinas (CI)

bash

# Shard 1/4
npx playwright test --shard=1/4

# Shard 2/4
npx playwright test --shard=2/4

8.5 Flaky Tests

Política de Tolerância Zero:

Flaky tests devem ser corrigidos imediatamente
Se não puder corrigir: marcar como skip + issue criada

Estratégias de Mitigação:

Aumentar timeouts adequadamente
Usar espera explícita, não sleep
Garantir isolamento entre testes
Evitar dependência de timing

Exemplo (Playwright):

typescript

// ERRADO
await page.click('button');
await page.waitForTimeout(2000); // sleep

// CORRETO
await page.click('button');
await page.waitForSelector('.success-message');

9. Cronograma e Recursos

9.1 Fases de Teste

Fase 1: MVP (Meses 1-4)

Semanas 1-2:

Setup de infraestrutura de testes
Configuração de CI/CD
Definição de padrões

Semanas 3-8:

Testes unitários (contínuo com dev)
Testes de integração para APIs MVP
Testes E2E para fluxos críticos

Semanas 9-12:

Testes de performance (baseline)
Testes de segurança (OWASP Top 10)
UAT com beta testers

Semanas 13-16:

Correção de bugs
Regressão completa
Performance tuning
Go-live preparation

Fase 2: Expansion (Meses 5-8)

Foco:

Gamificação
Wallet completo
Eventos
Analytics

Atividades:

Expandir suite de testes
Performance testing com carga maior
Security audit

Fase 3: Innovation (Meses 9-12)

Foco:

Vídeo e IoT
Patrocínio
ML para analytics

Atividades:

Testes de integração IoT (simulado)
Performance com streaming de vídeo
Penetration testing completo

9.2 Recursos

Time de QA:

1 QA Engineer Sênior (Quality) - full-time
2 QA Engineers - full-time (a partir da Fase 2)

Desenvolvedores:

Responsáveis por testes unitários (TDD)
Participação em testes de integração

DevOps:

Setup e manutenção de ambientes
CI/CD
Monitoramento

Product Owner:

Definição de critérios de aceitação
Participação em UAT
Aprovação final

9.3 Ferramentas e Licenças

Ferramenta	Tipo	Custo Estimado
Jest/Vitest	Open Source	Grátis
Playwright	Open Source	Grátis
k6	Open Source	Grátis
OWASP ZAP	Open Source	Grátis
Snyk	SaaS	$99/mês
Mailtrap	SaaS	$10/mês
LocalStack	Open Source	Grátis
Allure	Open Source	Grátis
Total		~$109/mês

10. Riscos e Mitigações

10.1 Riscos Técnicos

RISCO-001: Ambiente de Testes Instável

Probabilidade: Média
Impacto: Alto

Mitigação:

Infraestrutura como código (Terraform)
Monitoramento de ambiente
Auto-healing de serviços
Backups de configuração

RISCO-002: Dados de Teste Inconsistentes

Probabilidade: Alta
Impacto: Médio

Mitigação:

Seed scripts versionados
Factories para geração de dados
Cleanup automático entre testes
Snapshot testing para validação

RISCO-003: Flaky Tests

Probabilidade: Alta
Impacto: Alto (impede CI/CD confiável)

Mitigação:

Code review rigoroso de testes
Retry automático (max 2x)
Identificação proativa de flakiness
Política de correção imediata

10.2 Riscos de Processo

RISCO-005: Baixa Cobertura de Testes

Probabilidade: Média
Impacto: Alto

Mitigação:

TDD obrigatório
Coverage gates no CI/CD (min 80%)
Code review verifica testes
Relatórios semanais de coverage

10.3 Riscos de Segurança

RISCO-008: Vulnerabilidade Não Detectada

Probabilidade: Baixa
Impacto: Crítico

Mitigação:

Scan automático de dependências (Snyk)
Penetration testing trimestral
Security champions no time
Bug bounty program (futuro)

10.4 Riscos de Negócio

RISCO-010: Funcionalidade Crítica Quebrada em Produção

Probabilidade: Baixa
Impacto: Crítico

Mitigação:

Smoke tests pós-deploy obrigatórios
Canary deployments
Feature flags para rollback rápido
Monitoramento em produção (synthetic transactions)

Apêndices

A. Glossário

Termo	Definição
BDD	Behavior-Driven Development
CQRS	Command Query Responsibility Segregation
E2E	End-to-End
Flaky Test	Teste não determinístico (às vezes passa, às vezes falha)
RBAC	Role-Based Access Control
RLS	Row Level Security
TDD	Test-Driven Development
UAT	User Acceptance Testing
WCAG	Web Content Accessibility Guidelines

B. Contatos

Papel	Nome	Email
QA Lead	Quality	quality@sport-tech-club.com
Tech Lead	Engenheiro	engenheiro@sport-tech-club.com
Product Owner	-	po@sport-tech-club.com

C. Referências

Documentos Relacionados:

Padrões e Frameworks:

ISTQB Foundation Level
Google Testing Blog
Martin Fowler - Testing Strategies
OWASP Testing Guide

Resumo Executivo

Métricas de Qualidade

Métrica	Meta	Status
Code Coverage	>= 80%	🟡 A medir
Testes Automatizados	>= 90%	🟡 A desenvolver
Bugs Críticos Abertos	0	🟡 A iniciar
Performance (p95)	< 500ms	🟡 A testar
Vulnerabilidades Críticas	0	🟡 A escanear

Total de Casos de Teste Documentados

Por Módulo:

Módulo	Casos de Teste
Autenticação	30
Arenas e Quadras	25
Reservas	40
Fila e Alocação	30
Pagamentos	25
Wallet	20
Gamificação	20
Outros módulos	50
TOTAL	240+

Meta atingida: 240 casos de teste documentados (meta: 200+)

Última Atualização: 2026-01-09
Próxima Revisão: 2026-02-09 (mensal)

Aprovações:

Papel	Nome	Data	Assinatura
QA Lead	Quality
Tech Lead	Engenheiro
Product Owner

Este documento é vivo e será atualizado continuamente conforme o sistema evolui.

Quality - Senior QA Engineer
"The first step to fixing a bug is writing a test that fails." — Kent Beck

Plano de Testes - Sport Tech Club ​

Sumário ​

1. Introdução ​

1.1 Escopo ​

1.2 Objetivos ​

1.3 Critérios de Entrada ​

1.4 Critérios de Saída ​

1.5 Definições de Severidade ​

2. Estratégia de Testes ​

2.1 Níveis de Teste ​

2.1.1 Testes Unitários (Unit Tests) ​

2.1.2 Testes de Integração (Integration Tests) ​

2.1.3 Testes End-to-End (E2E) ​

2.1.4 Testes de Performance (Load/Stress) ​

2.1.5 Testes de Segurança ​

2.2 Tipos de Teste ​

2.3 Pirâmide de Testes ​

3. Ambiente de Testes ​

3.1 Ambientes ​

Development (Local) ​

Staging (Pré-Produção) ​

Production (Produção) ​

3.2 Dados de Teste ​

Seed Data (Development/Staging) ​

3.3 Mocks e Stubs ​

3.4 Feature Flags ​

4. Casos de Teste por Módulo ​

4.1 Autenticação e Autorização (30 casos) ​

TC-AUTH-001: Login com Credenciais Válidas ​

TC-AUTH-002: Login com Email Inválido ​

TC-AUTH-003: Login com Senha Incorreta ​

TC-AUTH-004: Bloqueio após 5 Tentativas Falhas ​

TC-AUTH-005: Login com MFA Habilitado ​

TC-AUTH-006: Recuperação de Senha ​

TC-AUTH-007: RBAC - Acesso Admin ​

TC-AUTH-008: Multi-Tenant Isolation ​

TC-AUTH-009: Token JWT Expirado ​

TC-AUTH-010: Refresh Token ​

4.2 Gestão de Arenas e Quadras (25 casos) ​

TC-ARENA-001: Cadastrar Arena ​

TC-ARENA-002: Cadastrar Arena com CNPJ Inválido ​

TC-COURT-001: Cadastrar Quadra ​

TC-COURT-002: Listar Quadras Disponíveis ​

TC-COURT-003: Atualizar Status da Quadra ​

TC-COURT-004: Bloquear Horário para Manutenção ​

TC-COURT-005: Validar Capacidade Máxima ​

4.3 Reservas e Agendamento (40 casos) ​

TC-BOOKING-001: Criar Reserva Simples ​

TC-BOOKING-002: Verificar Disponibilidade em Tempo Real ​

TC-BOOKING-003: Reserva com Conflito de Horário ​

TC-BOOKING-004: Reserva Recorrente Semanal ​

TC-BOOKING-005: Adicionar Participantes ​

TC-BOOKING-006: Cancelar Reserva com Antecedência ​

TC-BOOKING-007: Cancelar Reserva em Cima da Hora ​

TC-BOOKING-008: No-Show ​

TC-BOOKING-009: Check-in na Reserva ​

TC-BOOKING-010: Listar Minhas Reservas ​

4.4 Fila e Alocação Dinâmica (30 casos) ​

TC-QUEUE-001: Entrar na Fila ​

TC-QUEUE-002: Receber Notificação de Chamada ​

TC-QUEUE-003: Perder Vez por Timeout ​

TC-QUEUE-004: Sair da Fila Voluntariamente ​

TC-QUEUE-005: Regra Ganha-Fica ​

TC-QUEUE-006: Limite de Vitórias Consecutivas Atingido ​

TC-QUEUE-007: Prioridade na Fila por Perfil ​

TC-QUEUE-008: Override Manual da Fila ​

TC-QUEUE-009: Motor de Alocação - Balanceamento de Times ​

TC-QUEUE-010: Fila Vazia - Liberar Quadra ​

4.5 Pagamentos (25 casos) ​

TC-PAY-001: Pagar com PIX ​

TC-PAY-002: Pagar com Cartão de Crédito ​

TC-PAY-003: Falha no Pagamento com Cartão ​

TC-PAY-004: Aplicar Cupom de Desconto ​

TC-PAY-005: Reembolso ​

TC-PAY-006: Pagamento Recorrente (Mensalidade) ​

TC-PAY-007: Webhook de Pagamento ​

TC-PAY-008: Timeout de Pagamento ​

TC-PAY-009: Split de Pagamento ​

TC-PAY-010: Multi-Tenant - Isolamento de Pagamentos ​

4.6 Wallet e Tokens (20 casos) ​

Plano de Testes - Sport Tech Club

Sumário

1. Introdução

1.1 Escopo

1.2 Objetivos

1.3 Critérios de Entrada

1.4 Critérios de Saída

1.5 Definições de Severidade

2. Estratégia de Testes

2.1 Níveis de Teste

2.1.1 Testes Unitários (Unit Tests)

2.1.2 Testes de Integração (Integration Tests)

2.1.3 Testes End-to-End (E2E)

2.1.4 Testes de Performance (Load/Stress)

2.1.5 Testes de Segurança

2.2 Tipos de Teste

2.3 Pirâmide de Testes

3. Ambiente de Testes

3.1 Ambientes

Development (Local)

Staging (Pré-Produção)

Production (Produção)

3.2 Dados de Teste

Seed Data (Development/Staging)

3.3 Mocks e Stubs

3.4 Feature Flags

4. Casos de Teste por Módulo

4.1 Autenticação e Autorização (30 casos)

TC-AUTH-001: Login com Credenciais Válidas

TC-AUTH-002: Login com Email Inválido

TC-AUTH-003: Login com Senha Incorreta

TC-AUTH-004: Bloqueio após 5 Tentativas Falhas

TC-AUTH-005: Login com MFA Habilitado

TC-AUTH-006: Recuperação de Senha

TC-AUTH-007: RBAC - Acesso Admin

TC-AUTH-008: Multi-Tenant Isolation

TC-AUTH-009: Token JWT Expirado

TC-AUTH-010: Refresh Token

4.2 Gestão de Arenas e Quadras (25 casos)

TC-ARENA-001: Cadastrar Arena

TC-ARENA-002: Cadastrar Arena com CNPJ Inválido

TC-COURT-001: Cadastrar Quadra

TC-COURT-002: Listar Quadras Disponíveis

TC-COURT-003: Atualizar Status da Quadra

TC-COURT-004: Bloquear Horário para Manutenção

TC-COURT-005: Validar Capacidade Máxima

4.3 Reservas e Agendamento (40 casos)

TC-BOOKING-001: Criar Reserva Simples

TC-BOOKING-002: Verificar Disponibilidade em Tempo Real

TC-BOOKING-003: Reserva com Conflito de Horário

TC-BOOKING-004: Reserva Recorrente Semanal

TC-BOOKING-005: Adicionar Participantes

TC-BOOKING-006: Cancelar Reserva com Antecedência

TC-BOOKING-007: Cancelar Reserva em Cima da Hora

TC-BOOKING-008: No-Show

TC-BOOKING-009: Check-in na Reserva

TC-BOOKING-010: Listar Minhas Reservas

4.4 Fila e Alocação Dinâmica (30 casos)

TC-QUEUE-001: Entrar na Fila

TC-QUEUE-002: Receber Notificação de Chamada

TC-QUEUE-003: Perder Vez por Timeout

TC-QUEUE-004: Sair da Fila Voluntariamente

TC-QUEUE-005: Regra Ganha-Fica

TC-QUEUE-006: Limite de Vitórias Consecutivas Atingido

TC-QUEUE-007: Prioridade na Fila por Perfil

TC-QUEUE-008: Override Manual da Fila

TC-QUEUE-009: Motor de Alocação - Balanceamento de Times

TC-QUEUE-010: Fila Vazia - Liberar Quadra

4.5 Pagamentos (25 casos)

TC-PAY-001: Pagar com PIX

TC-PAY-002: Pagar com Cartão de Crédito

TC-PAY-003: Falha no Pagamento com Cartão

TC-PAY-004: Aplicar Cupom de Desconto

TC-PAY-005: Reembolso

TC-PAY-006: Pagamento Recorrente (Mensalidade)

TC-PAY-007: Webhook de Pagamento

TC-PAY-008: Timeout de Pagamento

TC-PAY-009: Split de Pagamento

TC-PAY-010: Multi-Tenant - Isolamento de Pagamentos

4.6 Wallet e Tokens (20 casos)