Plan general y setup

Guía para validar manualmente que todas las funcionalidades de HUMAE operan correctamente. Complementa la suite automatizada del backend (Pest) y del frontend (Vitest + Playwright).

Audiencia

• QA manual: ejecuta estos planes antes de cada release.
• Product / stakeholders: validación final de negocio en staging.
• Desarrolladores nuevos: familiarizarse con flujos completos.
• Soporte: reproducir bugs reportados por usuarios.

Cuándo correr estas pruebas

Momento	Alcance
Pre-commit del developer	Solo la suite automatizada (composer check, npm run test)
Pre-release (QA semanal)	Smoke tests: Checklist de regresión
Post-release inicial	Smoke tests + 1 flujo end-to-end real con cuenta propia
Antes de cada deploy a prod	Checklist de regresión completo
Tras bug reportado	Casos específicos del flujo afectado
Validación trimestral	Todo el plan completo (≈ 1 día persona)

Formato de cada caso de prueba

Cada caso sigue este formato:

### TC-XXX-001 · Nombre descriptivo

Severidad: 🔴 Crítica / 🟠 Alta / 🟡 Media / 🟢 Baja

Precondiciones:
- Qué debe existir antes de ejecutar

Pasos:
1. Acción concreta
2. Acción concreta
3. ...

Resultado esperado:
- Qué debe pasar (UI, DB, notificaciones)

Variaciones:
- Si X, entonces Y
- Si el usuario hace Z, el sistema debe responder W

Niveles de severidad

• 🔴 Crítica — bloquea la operación del negocio (pagos, auth, datos personales).
• 🟠 Alta — funcionalidad core afectada, hay workaround molesto.
• 🟡 Media — degradación de UX pero no bloqueante.
• 🟢 Baja — cosmético, inconsistencia menor.

Ambiente de pruebas

Opción A: Local (recomendada para dev)

# Backend
cd humae_backend
php artisan serve

# Frontend
cd ../humae_frontend
npm run dev

# Docker (levanta mysql + redis + mailhog)
cd ..
docker compose up -d

URLs:

• Backend: http://localhost:8000
• Frontend: http://localhost:3000
• MailHog (correos): http://localhost:8025

Opción B: Staging

Si existe un ambiente staging desplegado:

• Backend: https://api.staging.humae.com.mx
• Frontend: https://staging.humae.com.mx

Credenciales y datos de prueba provistos por el equipo DevOps.

Opción C: Producción

⚠️ Pruebas en producción deben ser NO destructivas. No crear membresías con tarjetas reales a menos que se haga refund inmediato.

Cuentas de prueba

Los seeders crean roles + permisos pero no users. Para testing manual:

cd humae_backend
php artisan tinker

// Admin
$admin = \App\Models\User::factory()->create([
    'name' => 'Test Admin',
    'email' => 'admin@test.humae',
    'password' => bcrypt('Password123'),
]);
$admin->assignRole('admin');
$admin->markEmailAsVerified();

// Recruiter
$recruiter = \App\Models\User::factory()->create([
    'name' => 'Test Recruiter',
    'email' => 'recruiter@test.humae',
    'password' => bcrypt('Password123'),
]);
$recruiter->assignRole('recruiter');
$recruiter->markEmailAsVerified();

// Company user (requiere crear Company primero)
$company = \App\Models\Company::factory()->create(['name' => 'Acme Corp']);
$companyUser = \App\Models\User::factory()->create([
    'name' => 'Test Company',
    'email' => 'company@test.humae',
    'password' => bcrypt('Password123'),
]);
$companyUser->assignRole('company_user');
$companyUser->markEmailAsVerified();
\App\Models\CompanyMember::create([
    'company_id' => $company->id,
    'user_id' => $companyUser->id,
    'role' => 'owner',
]);

// Candidato (lo crearás desde el flujo de registro público)

Script de setup

Para evitar escribir esto cada vez, crea un seeder TestAccountsSeeder y córrelo con php artisan db:seed --class=TestAccountsSeeder. NO incluirlo en DatabaseSeeder principal — solo bajo demanda.

Herramientas necesarias

Herramienta	Uso
Browser (Chrome/Firefox/Safari)	Ejecutar flujos UI
DevTools del browser	Inspeccionar Network, Console, Cookies
Postman / Insomnia / HTTPie	Llamar a la API directamente
Stripe CLI	Disparar webhooks, validar firmas
MailHog (local) o /var/log/mail.log + mailq (prod)	Verificar correos enviados por el Postfix local
mysql CLI o TablePlus/DBeaver	Inspeccionar estado de DB
redis-cli	Inspeccionar cache + queue
Laravel Tinker	REPL para cambiar estado rápido

Datos de prueba

Stripe test cards (test mode)

Tarjeta	Resultado esperado
4242 4242 4242 4242	Pago exitoso
4000 0000 0000 9995	Pago fallido (fondos insuficientes)
4000 0025 0000 3155	Requiere 3D Secure (SCA)
4000 0000 0000 0002	Tarjeta rechazada (generic decline)
4000 0000 0000 0069	Tarjeta expirada
4000 0000 0000 0119	Error de procesamiento

Todas: CVC cualquiera, fecha futura cualquiera, ZIP cualquiera.

Imágenes de prueba

Para subir avatars/logos sin descargar nada:

• https://picsum.photos/512 — imagen aleatoria 512×512
• https://placebear.com/400/400 — placeholder

PDFs / documentos de prueba

• PDF generado por el mismo sistema: GET /api/v1/me/profile/cv.pdf
• Dummy PDF: https://www.w3.org/WAI/WCAG20/Techniques/pdf/

Reportar un bug

Si durante las pruebas encuentras un bug, documéntalo con:

TÍTULO: [TC-CAND-005] Verificación de email falla con URL expirada

AMBIENTE: staging / local
ROL: candidato
NAVEGADOR: Chrome 124 / macOS Sonoma

PASOS PARA REPRODUCIR:
1. Registrar nuevo candidato
2. Esperar 61 minutos
3. Clic en link de verificación del email

RESULTADO ACTUAL:
Pantalla blanca con error 500.

RESULTADO ESPERADO:
Mensaje "Link expirado, solicita uno nuevo" con botón de reenvío.

ADJUNTOS:
- Screenshot: ...
- Network log: ...
- Laravel log fragment: ...

SEVERIDAD: 🟠 Alta (los candidatos quedan bloqueados si tardan en ver el correo)

Canal de reporte:

• Linear / Jira / GitHub Issues del equipo
• Slack #humae-qa
• Email a qa@humae.com.mx

Cómo está organizado el plan

Secciones por flujo:

Sección	# Casos	Duración estimada
Flujo del candidato	~20	60 min
Flujo del reclutador	15	45 min
Flujo de la empresa	9	25 min
Flujo del administrador	~15	50 min
Auto-registro y aprobación	14	40 min
Integraciones externas	~10	30 min
Casos edge y what-ifs	~15	45 min
Checklist de regresión	smoke	20 min

Total completo: ~4h 30min persona para ejecutar todo el plan (sin contar el setup inicial).

Siguiente

Empezar por el flujo más crítico: Flujo del candidato →