# Sprint 3 QA Playbook (Extended)

## 1) Goal
This playbook defines an extended Sprint 3 QA cycle for MBTaller, focused on:
- Real workshop usage on tablet and desktop.
- End-to-end OT flow with evidence and quotation.
- Offline queue integrity and later synchronization.
- Data quality hardening for vehicle fields (marca/modelo by selection).

## 2) Scope
In scope modules:
- Authentication and dashboard access.
- Clientes and Vehiculos.
- OT creation, OT detail, OT edit.
- Danos, Fotos, Firmas, PDF.
- Cotizacion and state transitions.
- Historial and Reportes.
- Catalogos (tipos, vehicular chain).
- Offline queue + sync pull/push behavior.

Out of scope:
- ERP stock live integration.
- Chunked resumable uploads at binary level.
- Performance benchmarking under synthetic load.

## 3) Environment Matrix
Run each test block at least in:
- Desktop Chrome latest.
- Desktop Edge latest.
- Tablet viewport (DevTools iPad profile is acceptable for pre-check).

Network modes to cover:
- Stable online.
- Offline at creation time.
- Online -> offline -> online transitions.
- Intermittent network while creating OT evidence.

## 4) Preconditions
Before execution:
1. `docker compose up -d --build`
2. `docker compose exec backend sh -lc "npm run migration:run"`
3. Log in with default credentials (`admin` / `admin123`) or approved QA user.
4. Confirm APIs:
   - Frontend: `http://localhost:4000`
   - Backend: `http://localhost:3001/api/v1`
   - Swagger: `http://localhost:3001/api/docs`
5. Ensure browser storage can be cleared between rounds.

## 5) Test Data Baseline
Create and reuse:
- 3 clientes:
  - `QA-CLI-001` (NIT normal)
  - `QA-CLI-002` (NIT with dash format)
  - `QA-CLI-003` (no optional contact fields)
- 4 vehiculos with distinct combinations:
  - Carro / Toyota / Corolla
  - Moto / Honda / CB190
  - Pickup / Ford / Ranger
  - SUV / Hyundai / Tucson
- 1 product set in quotation:
  - 2 items `estaller=true`
  - 1 service
  - 1 item non-taller

## 6) Execution Plan

### Block A - Smoke (10 to 15 min)
1. Login and open dashboard.
2. Go to `/dashboard/ots/nueva`.
3. Select cliente.
4. Register new vehiculo and confirm:
   - `tipo de vehiculo` required.
   - `marca` select required.
   - `modelo` select required.
5. Create OT and open detail.
Expected:
- No crash.
- OT generated with route and visible vehicle card.

### Block B - Vehiculo Data Integrity
1. Open `/dashboard/vehiculos`.
2. Try to save with placa + tipo only.
3. Confirm save is blocked with validation message.
4. Select marca and modelo from catalog, then save.
5. Edit same vehicle and verify values persist.
Expected:
- Save blocked without marca/modelo.
- Save succeeds with valid chain.
- Stored values are trimmed and stable.

### Block C - OT Full Lifecycle
1. Create OT with existing vehicle.
2. Add cosas trae.
3. Add danos (multiple zones).
4. Upload fotos (general + documento).
5. Save firmas (cliente + recepcion).
6. Create cotizacion and adjust quantities.
7. Approve cotizacion.
8. Transition OT state until `entregada` with `fecha_salida`.
Expected:
- No invalid state transition.
- Totals recalculate correctly.
- Entregada OT becomes locked.

### Block D - Offline Creation and Sync
1. Disconnect network.
2. Create cliente, vehiculo and OT.
3. Add at least one local OT change.
4. Reconnect network.
5. Trigger sync and observe queue drain.
Expected:
- Local events queued.
- Mapping local -> server IDs applied.
- No duplicate vehicle records.

### Block E - Mixed Connectivity Evidence
1. Start OT online.
2. Go offline before uploading fotos.
3. Add local foto/dano updates while offline.
4. Return online and sync.
Expected:
- Pending artifacts sync without losing references.
- OT timeline remains coherent in detail and historial.

### Block F - Historial Accuracy
1. Search by cliente in `/dashboard/historial`.
2. Search by placa.
3. Open OT from historial shortcut.
Expected:
- Same OT count from both views for same plate owner context.
- Evidence blocks (danos/fotos/firmas/pdf) aligned with OT detail.

### Block G - Catalog Chain Regression
1. Open `/dashboard/catalogos` vehicular chain.
2. Add a new marca under specific tipo.
3. Add modelo under that marca.
4. Confirm it appears in:
   - Vehiculos module select.
   - OT new vehicle select.
Expected:
- New catalog records visible without breaking old data.

### Block H - Security/Validation Defensive Checks
1. Attempt API payload with empty marca/modelo in vehicle create.
2. Attempt payload with blank spaces for placa/marca/modelo.
3. Attempt tipoVehiculoId `0` or invalid.
Expected:
- Backend rejects invalid payload.
- Error messages are explicit and no partial record is created.

## 7) Detailed Acceptance Criteria
Release gate is met only if all pass:
1. OT creation supports both existing and new vehicles.
2. New vehicle path enforces catalog-based marca/modelo.
3. Vehiculos module cannot save incomplete marca/modelo.
4. Offline queue remains consistent after reconnect.
5. Historial reflects synchronized evidence correctly.
6. Frontend build and backend build pass in clean state.

## 8) Evidence Collection Standard
For each failed or blocked test:
- Capture screenshot or short screen recording.
- Include test ID from matrix (`S3-###`).
- Include exact timestamp and browser.
- Include expected vs actual behavior.
- Include console/API error if present.

## 9) Defect Severity Model
- Sev 1: Data corruption, OT not recoverable, sync breaks mappings.
- Sev 2: Core flow blocked (cannot create or close OT).
- Sev 3: Functional issue with workaround.
- Sev 4: Cosmetic issue without flow impact.

## 10) Exit Checklist
Before sprint sign-off:
1. Matrix execution >= 95%.
2. No open Sev 1 or Sev 2 defects.
3. All Sev 3 defects triaged with owner and ETA.
4. Build commands green:
   - Frontend typecheck + build.
   - Backend typecheck + build.
5. QA summary comment posted in ticket/PR with:
   - Pass rate.
   - Open issues.
   - Go / no-go recommendation.