Aula 07 — Dev + QA: Frontend, Testes e Qualidade

---

Módulo 2 · RockQuiz: Pipeline Completo Duração: 4 horas Agentes praticados: @dev, @qa Projeto: RockQuiz

---

🏆 Vitória desta aula

Frontend funcional integrado à API + testes com cobertura sólida + QA review completo com ciclo de correções aprovado.

Critério binário: App jogável no browser + testes passando + QA aprovou.

---

Conceito

O QA: o par crítico que torna o código profissional

Até agora o @dev implementou sozinho. A partir desta aula, o @qa entra como par crítico. Ele não procura bugs triviais (testes fazem isso) — ele avalia qualidade holística em 10 fases, cada uma olhando por uma lente diferente:

Fase	Lente
1	Conformidade com acceptance criteria
2	Qualidade e legibilidade do código
3	Robustez do error handling
4	Cobertura e qualidade dos testes
5	Edge cases não cobertos
6	Consistência com Architecture Doc
7	Segurança
8	Performance
9	Manutenibilidade
10	Documentação

O ciclo de feedback é formal:

@qa encontra issues → *request-fix → @dev corrige → *apply-qa-fix → @qa verifica → *verify-fix

O princípio aplicado ao QA

Você não vai dizer ao QA o que procurar — ele sabe (as 10 fases são seu checklist interno). Você vai pedir o review, ler o relatório, e garantir que o Dev corrige o que foi encontrado. Seu papel é orquestrar o ciclo, não dirigir a análise.

---

Contexto

Nesta aula fazemos três coisas: o Dev implementa o frontend (story correspondente), o Dev escreve testes, e o QA faz review de tudo (backend + frontend + testes). O QA vai encontrar problemas — e cada fix melhora o projeto.

---

Prática

Passo 1 — Dev implementa o frontend

cd ~/aiox-bootcamp/rockquiz
claude

@dev

Dex, leia a story de frontend em docs/stories/ e o UX Spec 
em docs/ux-spec.md.

Implemente o frontend completo do RockQuiz. A Uma (UX Expert) 
definiu o design, o fluxo de telas e os padrões visuais no 
UX Spec. A Aria (Architect) definiu a stack e a estrutura no 
Architecture Doc.

Preciso de:
- Todas as telas que o UX Spec define (landing, quiz, resultado, ranking)
- A integração com a API que você implementou na aula anterior
- O feedback visual que a Uma especificou (acerto/erro/streak/timer)
- Responsividade (funcionar em mobile e desktop)

Siga os acceptance criteria da story. Se algo do UX Spec 
não estiver claro para implementar, me pergunte.

Como verificar: Abra o browser e teste o fluxo completo.

# Garantir que API está rodando
cd packages/api && npm run dev &

# Iniciar frontend
cd packages/web && npm run dev

# Abrir http://localhost:3000

Checklist de verificação visual (teste você mesmo no browser)

• Landing carrega com campo de nickname e opções de modo
• Clicar para jogar inicia um jogo e mostra pergunta
• Alternativas são clicáveis com feedback visual
• Timer funciona (se o UX Spec definiu timer)
• Score atualiza a cada resposta correta
• Streak é visualmente indicado
• Tela de resultado mostra score e estatísticas
• Ranking carrega e mostra dados
• Funciona razoavelmente em tela pequena (redimensione o browser)

Se algo não funcionar ou não corresponder ao UX Spec:

Dex, a tela de quiz não mostra feedback quando erro uma 
pergunta — só pula para a próxima. O UX Spec diz que a 
alternativa errada deve ficar vermelha e a correta deve 
aparecer em verde com a explicação. Corrija.

Dex, no mobile as 4 alternativas ficam espremidas. 
Verifique a responsividade — em telas < 640px as 
alternativas devem empilhar verticalmente.

🏆 Checkpoint 1: App jogável no browser — fluxo completo funciona.

---

Passo 2 — Dev escreve testes

Dex, agora preciso de testes para garantir que o que 
construímos não vai quebrar quando fizermos mudanças.

Olhe os acceptance criteria de TODAS as stories implementadas 
(backend + frontend). Cada cenário de aceitação deve ter pelo 
menos um teste correspondente.

Preciso de:
- Testes unitários para a lógica de negócio (scoring, quiz engine)
- Testes de integração para os endpoints da API (com banco real)
- Pelo menos um teste E2E que percorra o fluxo completo no browser

Os testes devem cobrir tanto o caminho feliz (tudo funciona) 
quanto os caminhos de erro (input inválido, recurso não encontrado, 
estado inconsistente).

Consulte o Architecture Doc para a estratégia de testes que a 
Aria definiu.

Como verificar:

# Rodar testes
cd packages/api
npm test

# Com cobertura
npm test -- --coverage

Checklist de testes

• Testes passam sem erros?
• Cobertura de linhas é razoável (≥80%)?
• Há testes para o scoring (a lógica mais complexa)?
• Há testes de erro (o que acontece com input inválido)?
• Há teste E2E (fluxo completo funciona no browser)?

Se a cobertura estiver baixa:

Dex, a cobertura está em 65%. Os acceptance criteria do PRD 
definem vários cenários de scoring (speed bonus, streak, 
cap de multiplicador, erro). Verifique se cada cenário 
tem teste correspondente.

🏆 Checkpoint 2: Testes passando com cobertura adequada.

---

Passo 3 — QA Review

Agora vem o momento mais importante da aula. O QA analisa tudo:

*exit

@qa

Quinn, faça review completo do RockQuiz.

Analise todo o código implementado (backend e frontend), 
todos os testes, e verifique contra os acceptance criteria 
das stories em docs/stories/ e contra o Architecture Doc 
em docs/architecture.md.

Aplique suas 10 fases de review. Para cada issue encontrada, 
classifique por severidade (critical, high, medium, low) e 
explique exatamente o que está errado e por quê.

*review-build

O que esperar: O QA vai retornar um relatório com issues organizadas por severidade. Exemplos reais do tipo de coisa que o QA encontra e que testes não pegam:

• "O scoring service usa números hardcoded (100, 1.5, 0.8). Extrair para constantes nomeadas melhora manutenibilidade." (Fase 9)
• "Se Redis estiver indisponível, a API retorna erro 500 sem mensagem útil. Implementar fallback ou mensagem clara." (Fase 3)
• "O endpoint POST /api/games não valida se playerId existe antes de criar o jogo. Vai gerar erro de FK." (Fase 5)
• "O frontend não desabilita o botão após clicar uma alternativa. Double-click envia duas respostas." (Fase 5)
• "Nenhum endpoint tem rate limiting. Um usuário pode enviar 1000 requests/segundo." (Fase 7)
• "A query de listagem de rankings faz N+1 para buscar nicknames." (Fase 8)

Como avaliar o review do QA:

Checklist de qualidade do review

• O QA cobriu as 10 fases (não apenas testou se funciona)?
• Cada issue tem severidade clara?
• Cada issue explica o problema E por que é problema?
• Há issues de segurança (fase 7)?
• Há issues de performance (fase 8)?

Se o review parecer superficial:

Quinn, o review não mencionou segurança. O RockQuiz tem 
endpoints que aceitam input do usuário (nickname, respostas). 
Verifique se há validação adequada contra injection, XSS, 
e payloads malformados. Também verifique se o correctAnswer 
não vaza em nenhuma resposta antes do jogador responder.

---

Passo 4 — Ciclo de correções

O QA encontrou issues. Agora o Dev corrige:

*exit

@dev

Dex, o QA (Quinn) encontrou issues no review. Leia o relatório 
e aplique as correções para todas as issues de severidade 
critical e high.

*apply-qa-fix

Para cada correção:
1. Implemente o fix
2. Adicione teste que cobre o cenário (se não existia)
3. Rode os testes para garantir que não quebrou nada existente

Como acompanhar: O Dev vai listar as correções que aplicou. Verifique que cada issue crítica e alta foi endereçada:

Dex, o QA reportou 3 issues critical e 4 high. Confirme 
que todas as 7 foram corrigidas. Liste cada issue e o que 
você fez para resolver.

Se o Dev disser que uma issue "não é problema":

Dex, você diz que o rate limiting não é necessário porque 
"o projeto é pequeno". O QA classificou como HIGH porque 
sem rate limit qualquer script pode derrubar a API. 
Implemente — é uma prática de segurança básica.

---

Passo 5 — QA verifica as correções

*exit

@qa

Quinn, o Dev aplicou correções para as issues que você encontrou.

*verify-fix

Verifique:
1. Cada issue critical e high foi realmente corrigida?
2. As correções não introduziram novos problemas (regressão)?
3. Os testes cobrem os cenários que estavam faltando?

O QA deve confirmar: "Todas as issues critical/high foram resolvidas. Sem regressão detectada."

Se o QA encontrar que algo não foi corrigido adequadamente, o ciclo repete:

@qa → *request-fix (issue específica) → @dev → *apply-qa-fix → @qa → *verify-fix

Repita até o QA aprovar.

🏆 Checkpoint 3 — VITÓRIA DA AULA: QA aprovou após ciclo de correções.

---

Passo 6 — Commit consolidado

*exit

git add .
git commit -m "feat: frontend + tests + QA review fixes

- Frontend complete (all pages + components + API integration)
- Unit tests for scoring and quiz engine
- Integration tests for all API endpoints
- E2E test for complete quiz flow
- QA fixes: input validation, error handling, rate limiting,
  loading states, code quality improvements"

---

Reflexão

Testes vs QA: complementares, não redundantes

O que testes automatizados verificam	O que o QA verifica além dos testes
"Dado input X, retorna Y?"	"O código é legível para o próximo dev?"
Caminho feliz funciona	Edge cases não óbvios
Regressão (nada quebrou)	Segurança (injection, XSS, data leak)
Cobertura de linhas	Performance (N+1 queries, missing indexes)
	Manutenibilidade (magic numbers, coupling)
	Consistência com Architecture Doc

Testes garantem que funciona. QA garante que é bom. Ambos são necessários.

O conceito-chave

O ciclo QA → Dev → QA é onde a qualidade real emerge. Cada issue encontrada e corrigida torna o projeto mais robusto de uma forma que testes sozinhos não conseguem. O QA é o agente que vê o que ninguém mais vê.

Conexão com a próxima aula

Na Aula 08, o @devops fecha o RockQuiz: CI/CD com GitHub Actions, observabilidade com métricas e dashboards, e deploy. Após a Aula 08, o RockQuiz estará completo, protegido e observável.

---

Anterior: Aula 06 — Dev: Backend Próxima: Aula 08 — DevOps: CI/CD, Observabilidade e Deploy