Recorre la tarea completa con datos de prueba
Empieza por la tarea que justifica la aplicación y síguela desde la entrada hasta el resultado que alguien utiliza. Emplea datos preparados para pruebas y comprueba qué se guarda, qué aparece después y qué ocurre al regresar. Abrir las pantallas por separado no confirma que el recorrido funcione en conjunto.
Imagina una asociación que está construyendo una aplicación para inscribirse en actividades. El recorrido principal puede incluir elegir una sesión, completar los datos necesarios y consultar el estado de la solicitud. Para probarlo, debes confirmar que la sesión elegida llega correctamente al registro que gestionará el equipo.
Después cierra la página y vuelve a consultar la solicitud. Si la información solo existía mientras el formulario estaba abierto, la demostración inicial no validó la persistencia. La comparación debe utilizar el resultado esperado definido para la aplicación, incluidos los campos que deben seguir disponibles después del envío.
Prueba también un recorrido con una diferencia relevante, como una sesión sin plazas o una inscripción ya registrada. Elige esos casos por la regla que ejercitan. No necesitas inventar decenas de escenarios sin propósito, pero sí verificar los que pueden cambiar la decisión de la persona o del equipo.
Los criterios deben proceder del trabajo de planificar la aplicación antes de programar. Si no existe una respuesta clara sobre lo que debería ocurrir, registra una decisión pendiente. Una prueba no resuelve por sí sola la ambigüedad de un requisito que todavía admite comportamientos incompatibles.
Para preparar el siguiente paso, consulta Seguridad de aplicaciones desarrolladas con IA.
Comprueba qué ocurre con datos incompletos o inválidos
Las pruebas deben incluir información ausente, valores fuera de las reglas e intentos de repetir una acción. Confirma que la aplicación explica la situación y no guarda un resultado incoherente. La validación visible en el formulario ayuda a la persona, pero las reglas deben seguir aplicándose cuando la solicitud llega al sistema.
En la inscripción hipotética, comprueba qué ocurre cuando falta un contacto necesario o alguien selecciona una sesión que entretanto dejó de aceptar solicitudes. El mensaje debe orientar la corrección sin presentar como completada una inscripción que el sistema no pudo registrar. Observa también si se conservan los demás datos introducidos.
Para una acción de envío, prueba la repetición relevante para tu caso. Una persona puede pulsar de nuevo porque no entendió si terminó la primera solicitud. El comportamiento esperado debe evitar confundir una inscripción nueva legítima con la repetición de la misma solicitud, según la regla definida por el proyecto.
Pide al agente que distinga las pruebas de presentación de las pruebas de reglas aplicadas por el servidor. Un botón desactivado puede mejorar el recorrido y seguir siendo insuficiente como control. El informe debe explicar qué comportamiento se ejercitó, con qué entrada y qué resultado se observó en cada comprobación.
Utiliza cuentas con responsabilidades diferentes
Prueba los accesos con los tipos de usuario previstos e incluye a alguien sin sesión iniciada. Verifica tanto las acciones permitidas como las que deben rechazarse. Una cuenta de administrador no demuestra los límites de las demás, porque puede tener acceso legítimo a información que debe permanecer oculta para ellas.
En la asociación, una persona inscrita puede necesitar consultar su propia solicitud, mientras el equipo organiza todas las inscripciones de una actividad. Prepara registros ficticios para dos personas distintas y confirma la separación. La prueba debe observar los datos entregados por el sistema, además de las opciones que aparecen en el menú.
Esta comprobación debe realizarse en un entorno que controlas y con identidades de prueba. No utilices cuentas de clientes reales para intentar descubrir el alcance de un fallo. El objetivo es reproducir las condiciones de acceso sin exponer información ni realizar acciones sobre personas que no participan en la validación.
Antes de empezar, confirma adónde envía solicitudes el entorno local. Una aplicación abierta en tu ordenador puede estar conectada a servicios reales. Preparar el entorno y los accesos para trabajar con Claude Code debe incluir esa identificación para que la prueba no produzca efectos fuera del espacio previsto.
Observa la respuesta cuando falla una dependencia
Una aplicación puede funcionar mientras todos los servicios responden y fallar de forma confusa cuando una conexión tarda o deja de estar disponible. Simula esas condiciones en el entorno de prueba. Confirma que el usuario recibe información útil y que la aplicación no presenta una conclusión que todavía no pudo confirmar.
Si el servicio que guarda la inscripción no responde, la página no debe mostrar éxito solo porque se envió el formulario. Necesitas saber si la solicitud quedó pendiente, falló o se registró realmente. La respuesta determina si la persona debe esperar, corregir algo o repetir la operación.
También interesa comprobar qué ocurre al retomar. Un intento repetido no debe crear efectos duplicados por accidente y un fallo parcial debe poder investigarse. Guarda información suficiente para identificar el paso que falló, evitando incluir en registros técnicos datos personales o credenciales innecesarios.
El principio es el mismo de probar una automatización antes de entregarla: verificar el recorrido normal y las excepciones que modifican el resultado. Una prueba deliberada de fallo puede aclarar más sobre la preparación de la aplicación que repetir varias veces el camino que ya sabes que funciona.
Cierra las pruebas locales e identifica qué falta online
Antes de publicar, confirma que la versión de entrega supera las comprobaciones técnicas definidas para el proyecto y puede prepararse sin errores conocidos que lo impidan. Añade ese resultado a las pruebas de comportamiento. Si una condición depende del alojamiento o de una integración externa, regístrala como pendiente de validación en el entorno correspondiente.
Pide una lista breve que relacione cada verificación con la versión analizada. Distingue pruebas ejecutadas de recomendaciones pendientes y puntos evaluados solo leyendo el código. Esa diferencia permite decidir según la evidencia disponible, en lugar de interpretar una frase general de aprobación como una revisión integral.
La dirección pública, las configuraciones del alojamiento y las conexiones entre servicios pueden introducir condiciones distintas de las del ordenador local. Por eso, la publicación debe tener comprobaciones propias después de la transición, con autorización y datos adecuados. El éxito local es una etapa necesaria del proceso definido, sin sustituir la observación del entorno final.
Si existe un fallo que afecta al recorrido principal, corrígelo y repite las comprobaciones relacionadas antes de avanzar. Cuando la evidencia esté organizada, podrás explicar qué está listo, cuáles son los límites conocidos y qué se confirmará después. Esa claridad hace más responsable la decisión de poner la aplicación online.