Sustituye el encargo genérico por una regla observable
Una prueba negativa empieza con una regla verificable, como impedir que un colaborador lea solicitudes de otro cliente. Especifica quién intenta actuar, sobre qué registro y en qué condiciones. El resultado debe describir el rechazo y el estado que tiene que permanecer intacto después de realizar el intento de acceso o modificación.
“Prueba la seguridad” deja demasiado espacio para interpretaciones. La IA puede comprobar el inicio de sesión, abrir algunas páginas y concluir que no ha encontrado errores. Eso no responde a la pregunta de negocio: ¿una persona con acceso a un proyecto puede consultar otro para el que nunca recibió autorización?
Imagina un portal hipotético con dos proyectos y dos cuentas de colaboradores. Cada cuenta solo debe ver su proyecto. Pide una prueba en la que la primera cuenta intente abrir un registro del segundo proyecto. El resultado esperado incluye no recibir el contenido de ese registro, aunque conozca su dirección.
Añade la acción de modificar. Una persona puede tener permiso para leer una propuesta, pero no para aprobar su ejecución. La prueba debe comprobar si el intento de aprobación se rechaza y si la propuesta conserva el estado anterior. La lectura autorizada no resuelve la cuestión independiente del permiso de escritura.
Estas reglas deben surgir al planificar la aplicación antes de programar. Hacer preguntas en esta fase permite aclarar decisiones que la IA no puede tomar por el negocio. Si nadie ha definido quién puede aprobar, una prueba superada solo confirma una suposición introducida durante el desarrollo.
Para preparar el siguiente paso, consulta Seguridad de aplicaciones desarrolladas con IA.
Elige cuentas y datos que revelen la diferencia
Prepara identidades de prueba con permisos distintos y registros que pertenezcan a cada una. Incluye una persona sin sesión iniciada y otra con acceso limitado. Utiliza información ficticia que permita reconocer una exposición indebida, evitando datos reales de clientes y cualquier envío o cambio fuera del entorno previsto para el ensayo.
En el portal hipotético, llamaría a los registros “Proyecto de prueba A” y “Proyecto de prueba B”. La diferencia debe ser visible para quien lee el informe. Si todas las cuentas son administradoras o comparten los mismos datos, el ensayo no puede demostrar que existe aislamiento entre usuarios con responsabilidades distintas.
También prepararía una cuenta cuyo acceso se haya retirado. El comportamiento esperado debe quedar definido: esa persona ya no puede consultar ni modificar el proyecto protegido. Probar únicamente cuentas recién creadas deja sin observar qué ocurre cuando cambian las responsabilidades y termina un acceso que antes era válido.
Indica a la IA qué puede ejecutar. Por ejemplo, crear registros ficticios, iniciar sesiones de prueba y consultar resultados en ese entorno. Excluye envíos reales, cobros y cambios en cuentas de clientes. Un encargo de pruebas necesita límites operativos tan claros como los de la funcionalidad que se está comprobando.
Registra el punto de partida antes del intento. En una aprobación, guarda el estado y la versión de la solicitud; en un valor, guarda el importe actual. Sin esa referencia, un informe puede mostrar un mensaje de error y pasar por alto un cambio que se produjo a pesar del rechazo presentado.
Prueba caminos distintos para la misma acción
El rechazo debe mantenerse en los caminos que permiten llegar a la acción, incluidas las peticiones directas al servidor. No limites la comprobación a la ausencia de un botón en pantalla. Pide a la IA que relacione las pruebas con los puntos de entrada de tu aplicación y presente las comprobaciones que logró ejecutar.
Una interfaz puede ocultar la opción de borrar y el servidor seguir aceptando la operación. En un ensayo autorizado de la propia aplicación, la comprobación debe confirmar que la regla se aplica donde se procesa la petición. El aspecto de la pantalla informa sobre la interfaz; por sí solo, no prueba la autorización efectiva.
El mismo cuidado se aplica a anexos y exportaciones. Si la página de un proyecto está protegida, pero su documento queda accesible para cualquier cuenta, la prueba debe identificar esa diferencia. Incluye los recursos que forman parte de la tarea, en lugar de probar únicamente la primera pantalla que ve la persona.
Si hay varios tipos de usuario, combina casos permitidos y rechazados. El colaborador autorizado debe poder consultar su proyecto; la misma cuenta debe tener bloqueado el acceso al otro. Un sistema que lo bloquea todo también supera una comprobación mal diseñada que busque exclusivamente rechazos sin verificar el recorrido permitido.
Pide un informe con el caso ejecutado, el resultado esperado y el observado. Si la IA no logró iniciar una sesión o alcanzar un punto de entrada, debe figurar como prueba no ejecutada. No aceptes que la ausencia de resultado se resuma como éxito ni que una descripción del código sustituya una ejecución solicitada.
Incluye datos inválidos y estados que impiden avanzar
Además de los permisos, prueba entradas que incumplen las reglas del proceso: campos obligatorios vacíos, valores fuera de los límites y cambios sobre una versión antigua. Define la respuesta esperada en cada caso. La aplicación debe explicar el rechazo de forma útil y evitar guardar una operación parcial que deje el trabajo incoherente.
En un ejemplo hipotético de solicitud de compra, la cantidad puede tener que ser positiva y la justificación obligatoria por encima de un límite definido por la empresa. La IA necesita esas condiciones antes de construir los casos. No le pidas que invente valores aceptables únicamente para completar una tabla de pruebas.
Prueba los límites exactos, incluido el valor permitido y el primer valor que deja de aceptarse. Esa comparación muestra si la regla se ha implementado con el significado previsto. El mismo razonamiento sirve para los límites de una automatización que cambia el presupuesto de los anuncios, donde una interpretación equivocada puede tener consecuencias concretas.
Considera también una solicitud ya completada. Si la regla dice que una aprobación solo puede producirse una vez, repetir la acción no debe crear otra ejecución ni una notificación indebida. El equipo debe decidir cómo tratar la repetición y pedir una prueba de ese comportamiento, incluido lo registrado después de ambos intentos.
En una edición simultánea, alguien puede intentar guardar una versión desactualizada. El resultado esperado puede ser pedir que recargue la información, en lugar de sustituir silenciosamente el trabajo más reciente. Este caso prueba una regla de colaboración e integridad de los datos, aunque todas las personas implicadas tengan permisos legítimos.
Utiliza los fallos para corregir la regla y repetir la prueba
Cuando una prueba falla, conserva el caso que reveló el problema y confirma la corrección con el mismo intento. Vuelve a ejecutar el recorrido permitido relacionado. La revisión termina con una lista clara de resultados y carencias, para que el equipo sepa qué se ha demostrado y qué sigue necesitando comprobación.
Si una cuenta abrió un registro que no debía, el siguiente trabajo es corregir la autorización y probar de nuevo ese acceso. No basta con ocultar la dirección o retirar el botón que hizo visible el fallo. La regla debe resistir el mismo intento donde la aplicación decide entregar los datos.
Si la prueba estaba equivocada, corrígela con una decisión explícita sobre el comportamiento previsto. Puede que un supervisor deba acceder a ambos proyectos y que la cuenta elegida tuviera ese papel. En ese caso, el resultado revela un problema del ensayo, no necesariamente un fallo de la propia aplicación.
Guarda estos casos para los cambios posteriores. Una nueva exportación, un nuevo perfil o un cambio en la forma de guardar documentos puede abrir un camino todavía no comprobado. El conjunto de pruebas debe acompañar esos cambios, con casos vinculados a las reglas que siguen siendo relevantes para el negocio.
Este trabajo complementa el proceso de probar una automatización antes de entregarla al equipo. La IA ayuda a preparar y ejecutar comprobaciones, pero los resultados necesitan evidencia y límites claros. Un informe útil distingue lo que funciona, lo que se rechazó correctamente y lo que quedó sin probar.