Plan de pruebas — Metodología

Este plan de pruebas verifica, de forma rigurosa, el comportamiento real de cada módulo de la aplicación: casos felices, variantes de tipo, campos omitidos o con valores inválidos, límites de permisos por rol, errores típicos que comete una persona usando el sistema, y el aislamiento de datos entre empresas (multi-tenant) introducido en la migración de seguridad de octubre 2026.

No es un manual de uso (eso ya existe en Introducción y las páginas de “Crear…”). Este plan existe para encontrar fallas y oportunidades de mejora de usabilidad, no para describir el flujo feliz.

Entorno de pruebas

• URL: https://staging.clickstock.lat.
• La base de datos de staging se reinició por completo el 2026-10-09 (ver incidente de migración en el historial del proyecto) — al iniciar este plan, no hay ninguna empresa ni usuario creado. El primer ciclo de ejecución debe partir de cero.
• El login en staging lo hace manualmente el usuario humano (no Claude) por regla de seguridad — staging no es localhost.

Qué queda excluido de este plan (y por qué)

Si en el futuro estos módulos quedan listos, se debe agregar una página facturacion-electronica.mdx y integraciones-pago.mdx siguiendo esta misma convención.

Convención de caso de prueba

Cada caso de prueba usa un identificador ÁREA-NN (ej. CAT-03, MT-12) y esta estructura:

CP ÁREA-NN: nombre descriptivo

• Objetivo: qué comportamiento se está verificando.
• Precondición: estado previo necesario (datos, rol, sesión).
• Pasos: secuencia exacta y reproducible.
• Resultado esperado: qué debería pasar según el código/reglas de negocio.
• Resultado obtenido: se llena al ejecutar — Pendiente / ✅ Correcto / ❌ Falla (con detalle) / ⚠️ Correcto pero con problema de usabilidad.
• Captura: referencia a /images/pruebas/área/CP-ÁREA-NN.png, agregada al ejecutar.

Al final de cada página hay una sección Notas de usabilidad y sugerencias, que se llena durante la ejecución con observaciones que no son un “bug” pero sí friction points (ej. “el formulario no indica que el campo es obligatorio hasta que falla el submit”).

Historial de ejecución

Cada página tiene su propia tabla de historial al inicio. Formato:

Un “ciclo” es una pasada completa por todos los casos de una página, típicamente después de un despliegue o un cambio relevante en ese módulo. No se borra el historial de ciclos anteriores — se agrega una fila nueva, así se puede comparar regresión entre ciclos.

Cómo resetear datos entre ciclos

Si un ciclo de pruebas deja la base de staging en un estado inconsistente (o simplemente se quiere repetir desde cero):

ssh -i <llave>.pem ubuntu@<host> '
docker exec staging-postgres psql -U $(docker exec staging-postgres printenv POSTGRES_USER) -d $(docker exec staging-postgres printenv POSTGRES_DB) -c "
DROP SCHEMA public CASCADE;
CREATE SCHEMA public;
"
docker restart staging-backend
'

Esto borra todos los datos de todas las empresas en staging. Después hay que volver a registrar las empresas de prueba (ver 1. Autenticación y usuarios).

Para el caso del módulo 2 (Aislamiento multi-tenant), que requiere dos empresas con datos propios en paralelo, no se debe resetear la base entre la creación de datos de la Empresa A y la Empresa B dentro del mismo ciclo — solo entre ciclos completos.