LalakinSkywalker Auditoría profunda — El auditor quisquilloso
"La app compila, los tests pasan, la validación visual aprueba todos los flujos. Aun así, el usuario configura 50% de comisión en Ajustes, y el motor sigue calculando 30% porque el valor está hardcodeado en el código. Eso es lo que esta skill caza."
Mientras validacion-visual pregunta "¿la app funciona?", ésta pregunta "¿la app respeta lo que el usuario le dice?". Es la diferencia entre un botón que abre un modal (visible) y una configuración que se guarda pero nunca se aplica (invisible, y la que hace que un cliente pierda la confianza).
Las 5 dimensiones
D1 — Coherencia configuración ↔ comportamiento
¿Cuando el usuario cambia un ajuste, ese cambio realmente afecta la feature que depende de él?
Método (A/B sistemático): por cada configuración detectada — capturar el valor actual → cambiarlo → ejecutar la feature que debería leerlo → comparar el resultado → si NO cambió cuando debía cambiar, es un bug (valor hardcodeado o config ignorada) → restaurar el valor original.
Hallazgos típicos: "tarifa por km configurable, pero el motor usa un valor fijo en el código"; "toggle 'enviar email' configurable, pero el flag se ignora en la acción del servidor".
D2 — Persistencia
¿Lo que el usuario guarda sigue ahí tras refrescar, cerrar sesión, volver a entrar, o abrir en otro dispositivo?
Método: guardar → ver el mensaje de éxito → refrescar y verificar → cerrar sesión y volver a entrar y verificar → confirmar con una query directa a la base que el dato realmente llegó. El bug clásico: la UI dice "guardado" pero la acción del servidor nunca hizo el UPDATE.
D3 — Permisos / RLS
¿Un usuario solo ve y edita lo suyo, sin filtrarse a datos de otros?
Método (dos usuarios A y B): A crea un recurso → capturar su ID → entrar como B → intentar acceder por URL directa al recurso de A (no debería verse) → intentar modificarlo/borrarlo → confirmar que los listados de B no muestran nada de A. Si la app es multi-tenant, cruzar tenants. El bug clásico: la API no valida ownership en el servidor — basta pegar la URL.
D4 — Casos extremos
¿La app maneja los límites del rango, o se rompe / produce resultados absurdos?
- Numéricos: 0, negativos, decimales minúsculos, valores enormes, NaN/Infinity.
- Texto: vacío, solo espacios, emojis y acentos (ñ, Á), comillas/backticks, cadenas de 10.000 caracteres.
- Fechas: pasadas/futuras extremas, fecha imposible (31 de febrero), choques de zona horaria.
- Combinaciones imposibles: fecha fin < fecha inicio, descuento de 150%, tarifa 0 en campo obligatorio.
Hallazgos típicos: "tarifa 0 → división por cero → pantalla blanca"; "descuento 150% → totales negativos aceptados"; "fecha de 1900 → métricas en NaN".
D5 — Coherencia dashboard ↔ base de datos
¿Lo que muestra la UI coincide con lo que realmente hay en la base?
Método: por cada KPI/contador/listado, leer el número de la UI y compararlo con una query directa (SELECT count(*), SELECT sum(...) con los filtros equivalentes). Si no coinciden, es un bug (caché desactualizado, agregación incorrecta, o filtro distinto entre la UI y la base).
El flujo
- Detectar el alcance: la app completa, o lo que el usuario indique. Si no está claro, preguntar — nunca asumir.
- Setup (si hay auth): usuario QA primario + un segundo usuario para las pruebas de permisos (D3). Borrar al final.
- Recorrer las 5 dimensiones con navegador real + queries directas a la base para contrastar UI contra datos.
- Loop bug-arreglo-revalidación: diagnosticar la causa raíz (no parchar), arreglar, re-validar. Pausar y preguntar si el bug exige una decisión de arquitectura, toca datos reales de producción, o se sale del alcance.
- Limpieza OBLIGATORIA: todo registro de prueba borrado, toda configuración tocada restaurada a su valor original, la base idéntica al estado previo.
- Reporte + autorización. El push/deploy final SIEMPRE lo autoriza el dueño.
Reglas duras
- Caza coherencia, no solo funcionamiento — el valor hardcodeado que ignora la config es el bug estrella.
- Contrastar SIEMPRE la UI contra la base de datos real, no confiar en lo que dice la pantalla.
- Loop bug-arreglo-revalidación hasta que una pasada salga limpia.
- Restaurar toda configuración tocada durante el A/B testing — la base queda idéntica.
- Pausar por decisión de arquitectura / datos reales / fuera de alcance, no por dificultad.
- El push/deploy lo autoriza el dueño.
Anti-patrones (prohibidos)
- "El botón guarda y muestra éxito, listo." → Falta confirmar que el dato llegó a la base Y que se aplica.
- "Probé con valores normales." → Los bugs viven en los extremos (0, negativos, vacío, fechas imposibles).
- "El dashboard muestra un número, le creo." → Contrastarlo con la base; el caché miente.
- "Cambié la config para probar y la dejé así." → Restaurar siempre el valor original.