01. Plan General de QA
1.1. Objetivo
Validar que el ecosistema ZEUMAX funciona correctamente desde la perspectiva del usuario final y del operador del restaurante, garantizando que los flujos críticos de pedidos, pagos, gestión de mesas, notificaciones y seguridad operan sin errores bloqueantes antes de una entrega o despliegue.
1.2. Alcance
Incluido en este manual:
- Web Cliente (Next.js)
- App QR para Mesas (Vite + React)
- Orden Receiver (React Native + Expo)
- TPV (React Native + Expo)
- Flujos de pedidos entre canales
- Roles, autenticación y permisos
No incluido en este manual:
- Pruebas unitarias o de integración del backend/API.
- Pruebas de carga, estrés o rendimiento.
- Pruebas de seguridad avanzadas (pentesting).
- Pruebas de la app de repartidor externa hotpack_rider.
1.3. Entornos de prueba
| Entorno | URL / Dispositivo | Uso |
|---|---|---|
| Local / Desarrollo | http://localhost:3000 (web), emulador Android (apps) |
Pruebas de desarrollo |
| Staging | URL proporcionada por el equipo técnico | Pruebas de validación previas |
| Producción | URL real del cliente | Solo smoke test controlado |
1.4. Tipos de prueba
| Tipo | Descripción | Cuándo aplicar |
|---|---|---|
| Smoke test | Validar que la aplicación arranca y las funciones críticas son accesibles. | Al inicio de cada ciclo de pruebas. |
| Funcional | Verificar que cada funcionalidad cumple lo especificado. | En cada release o entrega. |
| Regresión | Confirmar que cambios nuevos no rompieron funcionalidades anteriores. | Antes de pasar a producción. |
| End-to-end (E2E) | Probar flujos completos de principio a fin. | Para pedidos delivery, takeaway y mesa. |
| Usabilidad / UI | Validar navegación, diseño responsive, mensajes de error claros. | Siempre que se modifique una pantalla. |
| Compatibilidad | Probar en diferentes navegadores, tamaños de pantalla y versiones de Android. | Ante cambios de dependencias o UI. |
1.5. Severidad de defectos
| Severidad | Definición | Ejemplo |
|---|---|---|
| Crítica | Bloquea el flujo principal; el usuario no puede completar la acción. | No se puede finalizar un pedido en la web. |
| Alta | Funcionalidad importante falla o hay workaround complejo. | El carrito no persiste al recargar la página. |
| Media | Fallo menor o molesto, pero no bloquea el flujo principal. | Mensaje de error poco claro. |
| Baja | Problema cosmético o de bajo impacto. | Icono desalineado en una pantalla secundaria. |
1.6. Formato de reporte de bug
Cada bug debe reportarse con al menos:
- ID del caso de prueba relacionado.
- Título breve del problema.
- Pasos para reproducir (numerados).
- Resultado esperado.
- Resultado actual.
- Evidencia (captura de pantalla, video, log).
- Severidad.
- Entorno (navegador, dispositivo, versión de la app).
1.7. Datos de prueba
Para ejecutar los casos de prueba se necesitan como mínimo:
- Un usuario cliente registrado con dirección y teléfono.
- Un usuario manager / recepcionista con acceso al Orden Receiver.
- Un usuario cajero con acceso al TPV.
- Un usuario admin con acceso al panel de administración.
- Una sucursal configurada con productos, categorías, mesas, zonas y al menos una impresora térmica.
- Una pasarela de pago configurada en modo sandbox (Stripe, MONEI, PayPal, etc.).
1.8. Definición de listo para entrega
Una release se considera lista cuando:
- Todos los casos de prueba de severidad Crítica y Alta han pasado.
- No hay bugs Críticos abiertos.
- Los bugs de severidad Alta tienen plan de corrección o workaround documentado.
- El checklist de regresión tiene al menos un 95% de casos pasados.
- Las pruebas E2E de pedidos (delivery, takeaway, mesa, TPV) han pasado.