Desafio Técnico – QA (API de Pedidos)

---

📌 Índice dos Entregáveis

Este documento mapeia cada item solicitado no desafio técnico para o arquivo ou seção onde está atendido.

Arquivo: Este README.md

O plano de testes está neste README.md e contém:

Requisito	Onde está no README.md
Escopo	Seção "1. Escopo"
Estratégia	Seção "2. Estratégia"
Matriz de risco	Seção "3. Matriz de Risco"
Principais casos de teste	Seção "4. Principais Casos de Teste"
O que automatizar primeiro	Seção "5. O que Automatizar Primeiro"

---

Suíte de testes automatizados de API

Arquivo: tests/orders.test.ts. Como rodar: ver seção "Suíte de Testes Automatizados".

Requisito	Implementado em
Happy path	Teste: "happy path - cria pedido e consulta até PROCESSED"
Validação de contrato/payload	Testes: "validação de contrato - falta orderId" e "total como string inválida"
Idempotência (mesmo orderId duas vezes)	Teste: "idempotência - mesmo orderId duas vezes não duplica"
Cenários de erro (payload inválido)	Testes de contrato + "cenário de erro - consulta pedido inexistente"
Fluxo assíncrono (POST + consulta até PROCESSED)	Happy path com polling em waitForStatus() até status PROCESSED

---

Bug report

Arquivo: BUG_REPORT.md

Contém:

• Passos para reproduzir — Seção 2
• Resultado esperado — Seção 3
• Resultado atual — Seção 4
• Evidências — Seção 5
• Severidade — Seção 6

Exemplo: bug de idempotência (mesmo orderId gerando processamento duplicado).

---

Relatório de resultados

Arquivo: RELATORIO_RESULTADOS.md — resultado dos testes funcionais e de performance, evidências e como reproduzir.

---

Plano de Testes

Contexto da API

• POST /orders — Campos: orderId (string), customer (string), total (number)
• GET /orders/{orderId} — Retorna status: PENDING | PROCESSED | FAILED
• Regras: orderId idempotente; após alguns segundos do POST o status deve evoluir para PROCESSED (processamento assíncrono).

Obs. (uso do mock): Os testes e o teste de performance podem rodar sem API real usando o servidor mock (mock-server.js). Em um terminal execute npm run mock e, em outro, npm test ou npm run performance. O mock simula POST/GET, validação de contrato, idempotência e processamento assíncrono (PENDING → PROCESSED). Para usar a API real, defina a variável de ambiente BASE_URL com a URL da API e não inicie o mock.

---

1. Escopo

Incluído:

• Testes funcionais de API dos endpoints POST /orders e GET /orders/{orderId}
• Validação de regras de negócio: criação de pedido, idempotência por orderId, fluxo assíncrono (PENDING → PROCESSED/FAILED)
• Validação de contrato (campos obrigatórios, tipos, formato de resposta)
• Cenários de erro (payload inválido, tipos errados, campos ausentes)
• Testes automatizados de API (Node + Jest + Axios)

Fora de escopo:

• Interface gráfica (frontend)
• Integrações externas reais (pagamento, ERP, etc.)
• Segurança avançada
• Testes de banco de dados diretos

---

2. Estratégia

• Nível: Testes funcionais de API em nível de integração (caixa-preta).
• Abordagem: Suíte automatizada que envia requisições HTTP reais (via BASE_URL), verifica status HTTP e corpo da resposta e aguarda processamento assíncrono com polling.
• Ferramentas: Jest, Axios; servidor mock (Express) para testes locais.
• Ambiente: URL base configurável por BASE_URL; orderId gerado dinamicamente quando necessário; casos de idempotência com orderId fixo.

---

3. Matriz de Risco

ID	Funcionalidade	Impacto	Prob.	Risco	Justificativa
R1	Criação de pedido (POST /orders)	Alto	Alto	Alto	Falha impede todo o fluxo.
R2	Idempotência por orderId	Alto	Médio	Alto	Risco de pedidos duplicados.
R3	Processamento assíncrono	Alto	Médio	Alto	Inconsistência de status.
R4	Consulta de pedido (GET /orders)	Médio	Alto	Alto	Dependência de consumidores.
R5	Validação de contrato/payload	Médio	Médio	Médio	Quebra de integrações.
R6	Tratamento de erros (400 Bad Request / 500 Internal Server Error)	Médio	Médio	Médio	Dificulta troubleshooting.

---

4. Principais Casos de Teste

4.1. Happy path

• Criar pedido com payload válido → esperar HTTP 201 (Created) ou 200 (OK) e corpo com orderId e status inicial (ex.: PENDING).
• Consultar pedido em polling até status PROCESSED (ex.: GET a cada 1s, até 30s).

4.2. Validação de contrato/payload

• Ausência de orderId → HTTP 400.
• total como string ou tipo inválido → HTTP 400.
• total negativo ou zero → HTTP 400 (conforme regra).
• orderId vazio ou inválido → HTTP 400.

4.3. Idempotência

• Enviar POST /orders duas vezes com o mesmo orderId → segunda resposta 200 ou 201 (mesmo recurso) ou 409 (Conflict); não criar novo pedido.

4.4. Cenários de erro

• JSON malformado → HTTP 400.
• GET /orders/{orderId} para pedido inexistente → HTTP 404 (Not Found) (ou 200 com status FAILED, conforme especificação).

4.5. Fluxo assíncrono

• POST + consulta até PROCESSED dentro do timeout; ou validar permanência em PENDING/evolução para FAILED se aplicável.

---

5. O que Automatizar Primeiro

1. Happy path completo (R1, R3, R4) — criação + consulta até PROCESSED.
2. Idempotência (R2) — mesmo orderId duas vezes.
3. Validação de contrato (R5) — campos obrigatórios e tipos.
4. Cenários de erro (R6) — pedido inexistente, payload inválido.
5. Fluxo assíncrono em falha — status FAILED quando aplicável.

---

Suíte de Testes Automatizados

Arquivo: tests/orders.test.ts

A suíte cobre no mínimo:

• Happy path — cria pedido e consulta até PROCESSED (com polling).
• Validação de contrato/payload — falta orderId; total como string.
• Idempotência — mesmo orderId duas vezes; mesma resposta/consistência.
• Cenários de erro — payload inválido (contrato) e consulta pedido inexistente.
• Fluxo assíncrono — POST + consulta até status PROCESSED.

Como executar:

npm install
npm run mock    # terminal 1
npm test        # terminal 2 (BASE_URL=http://localhost:3000 por padrão)

Para API externa: definir BASE_URL e rodar npm test.

---

Diferenciais (opcionais)

Teste de performance (k6)

• Script: performance/orders.k6.js
• Execução: com mock rodando, npm run performance (ou k6 run performance/orders.k6.js).
• Cenário de carga (ramp-up, pico, ramp-down), métricas e thresholds configurados.

Pipeline CI

• Workflow: .github/workflows/ci.yml
• Execução automática em push e pull requests (testes funcionais; teste de performance em push para main).

---

Organização dos Entregáveis

Entregável	Arquivo / local
Plano de testes	Este README.md (seções acima)
Suíte de testes	tests/orders.test.ts
Bug report	BUG_REPORT.md
Teste de performance	performance/orders.k6.js
Pipeline CI	.github/workflows/ci.yml
Relatório de resultados	RELATORIO_RESULTADOS.md

Demais arquivos do repositório (mock, configs) são de apoio para execução dos testes.