QA Smoke Tests

QA smoke test post-deploy

Ejecuta estos pasos despues de cada despliegue production-like y antes de exponer usuarios reales. Usa usuarios QA ficticios y datos no reales.

El smoke test no busca probar todo el sistema. Busca responder rapidamente:

• el frontend carga;
• el backend responde;
• la autenticacion por cookies funciona sin exponer tokens;
• CSRF/CORS estan cerrados;
• logout, refresh, 401 y Super Admin close limpian correctamente;
• tenant restricted queda bloqueado como fue aprobado;
• el flujo clinico minimo no rompe.

Si una prueba toca password, OTP, token, cookie o dato clinico, registra solo el resultado. No pegues valores sensibles en tickets, logs ni capturas.

Evidencia aceptable

Evidencia	Permitida
Status HTTP, ruta, metodo, hora y resultado	Si
Nombres de cookies sin valor	Si
Flags de cookies	Si
Conteo de errores o requests	Si
Passwords, OTPs, tokens, cookies completas	No
Datos clinicos reales	No

1. Backend basico

• GET /api/auth/session sin cookies devuelve no autenticado.
• GET /api/auth/csrf desde origen permitido devuelve token CSRF.
• Preflight CORS permitido devuelve 204 y credentials.
• Preflight desde origen no permitido devuelve 403.
• Logs no muestran secretos.

2. Frontend carga

• https://app.<dominio> carga sin mixed content.
• Assets cargan por HTTPS.
• Fallback SPA funciona al refrescar rutas internas.
• Build corresponde a version esperada.

3. Login con cookies

1. Abrir DevTools Network/Application.
2. Cargar /auth/login.
3. Confirmar request a /api/auth/csrf.
4. Hacer login con usuario QA.
5. Confirmar POST /api/auth/login con X-CSRF-Token.
6. Confirmar respuesta JSON sin token ni refresh_token.
7. Confirmar cookies access/refresh HttpOnly.
8. Confirmar /api/auth/session devuelve authenticated:true.

4. Storage y cookies

• localStorage no contiene token, refreshtoken, refresh_token, permissions, business, tenantOperational.
• sessionStorage no contiene access/refresh token.
• document.cookie no muestra access/refresh.
• document.cookie puede mostrar cookie CSRF.
• Solo medsync.auth.rememberedIdentifier.v1 puede persistir como auth-related long-lived.

5. CSRF

Prueba	Resultado esperado
Mutacion con token valido	2xx o respuesta de negocio.
Mutacion sin header	403.
Mutacion con header invalido	403.
Mutacion sin cookie CSRF	403.
Origin no permitido	403.

6. CORS

Prueba	Resultado esperado
Origin https://app.<dominio>	Allow-Origin exacto, credentials true.
Origin malicioso	No credentials, preflight 403.
Wildcard con credentials	No debe aparecer.

7. Refresh

• Esperar expiracion o forzar flujo QA.
• POST /api/auth/refreshToken no envia token en body para navegador.
• Refresh lee cookie HttpOnly.
• Cookies nuevas se setean.
• /api/auth/session sigue autenticado.

Nota: el refresh cookie-only ya se corrigio y valido localmente; repetir este smoke en production-like.

8. Logout y 401

• Logout llama /api/auth/close.
• Cookies access/refresh/CSRF se expiran.
• Runtime Vuex queda anonimo.
• Session posterior devuelve no autenticado.
• 401 por sesion cerrada limpia storage/runtime y redirige a login.

9. Roles, tenant y Super Admin

• Usuario bloqueado/inactivo hace hard-block en login: error generico, sin sesion, sin access cookie y sin refresh cookie.
• Tenant restricted/suspended/inactive hace hard-block en login: error generico, sin sesion, sin access cookie, sin refresh cookie y sin datos clinicos.
• /tenant-restricted se prueba solo con una sesion ya existente que luego recibe tenantOperational.allowed=false, por cambio de estado del tenant o por /api/auth/session.
• No debe existir login limitado para tenant restricted en el rollout inicial.
• Super Admin puede cerrar sesion individual QA.
• Super Admin puede cerrar sesiones masivas QA.
• Usuario afectado recibe 401 en siguiente request.

10. Reset password

• sendOtp con SMTP sandbox envia correo seguro.
• validateOtp acepta codigo valido.
• resetPassword actualiza password.
• Password anterior falla.
• Password nueva funciona.
• Sesiones y refresh tokens previos quedan invalidados.

11. Flujo clinico minimo

Con doctor QA y paciente QA ficticio:

• Abrir dashboard.
• Abrir paciente.
• Consultar historia clinica.
• Consultar documentos/firmas.
• Consultar treatment plan.
• Ejecutar una mutacion clinica no destructiva o fixture controlado con CSRF valido.
• Confirmar que no hay Authorization manual ni tokens en storage.