Casos de prueba UAT — US-050¶

Epic 9 — Acceso y seguridad. Ver la historia completa: US-050.

Reporte el resultado de cada caso con el control al pie de ese caso — el comentario es obligatorio si lo marca como Rechazado. Para ver el estatus general de todos los casos, consulte la Hoja de control.

Los casos de esta lista son sugeridos por Kaeus como punto de partida; la lista definitiva debe ser validada o completada por el cliente.

UAT-050-01 — Filtro combinado de fecha, usuario y acción en el audit log¶

Rol: admin · ACs cubiertos: 2, 3, 4

Filtrado combinado del audit log por fecha, usuario y acción

Pasos:

1. El admin inicia sesión en el backoffice y accede a la sección "Audit log".
2. Aplica de forma combinada un filtro por rango de fechas, un filtro por usuario/actor y un filtro por acción, y ejecuta la búsqueda.

Resultado esperado:

• El sistema muestra los resultados que cumplen con todos los filtros aplicados en conjunto (combinados con AND), paginados y ordenados por fecha y hora descendente por defecto.

Datos de prueba (seed canónico): admin@demo.com aplica filtros combinados (fecha + recurso + usuario) en el Audit log.

UAT-050-02 — Acceso al audit log vedado al rol operator¶

Rol: operator · ACs cubiertos: 1

Restricción de acceso al audit log para el rol operator

Pasos:

1. Un usuario con rol operator inicia sesión en el backoffice e intenta acceder a la sección "Audit log", ya sea por el menú o escribiendo la URL directamente.

Resultado esperado:

• El sistema deniega el acceso: el backend responde 403 y la sección no está disponible en el menú del rol operator.

Datos de prueba (seed canónico): operator@demo.com intenta acceder al Audit log (sin permiso).

UAT-050-03 — Anonimización retroactiva de PII en el audit log¶

Rol: admin · ACs cubiertos: 7

Anonimización de PII en entradas históricas del audit log tras la eliminación de datos del titular

Pasos:

1. El admin ejecuta una solicitud de eliminación de datos del titular (ver US-061) sobre un cliente que tiene entradas previas en el audit log con su información personal (por ejemplo, nombre o correo en el diff de un evento).
2. Una vez completada la eliminación, el admin vuelve a la sección "Audit log" y consulta las entradas históricas relacionadas con ese cliente.

Resultado esperado:

• Las entradas históricas del audit log que contenían PII del cliente eliminado muestran esa información reemplazada por el marcador "[anonimizado]", conservando el resto del registro (timestamp, actor, tipo de recurso, acción).
• La operación de anonimización queda registrada a su vez como un evento separado del audit log.

Datos de prueba (seed canónico): admin@demo.com ejecuta eliminación de datos de un cliente (el cliente estándar) con entradas previas en el audit log.