Define la tarea que debe completar la aplicación
El criterio de aceptación debe describir una tarea del usuario, el resultado esperado y las condiciones en que sucede. Evita cerrar el trabajo únicamente porque existen las pantallas. Un conjunto de páginas puede estar diseñado mientras el proceso que motivó la aplicación sigue dependiendo de pasos manuales que querías eliminar.
Al planificar una aplicación de pronósticos deportivos, definí que los resultados de los partidos debían recogerse y utilizarse para calcular las clasificaciones. La intención era evitar introducir esa información manualmente. Tener una tabla bonita de partidos no sería suficiente para demostrar que ese objetivo se había cumplido.
Ese ejemplo muestra la diferencia entre una funcionalidad visible y una tarea completa. Hay un origen de datos, una actualización, una regla de cálculo y un resultado presentado a las personas. La aceptación debe recorrer esa secuencia y comprobar si cada parte contribuye al comportamiento solicitado para el proyecto.
En una aplicación hipotética de citas, la tarea puede empezar al elegir un horario y terminar con la reserva confirmada para las personas adecuadas. Ver el calendario no basta. Hay que entender si el horario deja de estar disponible después de reservar y si la información guardada corresponde a la elección realizada.
Estos criterios deben escribirse al planificar la aplicación antes de empezar a programar. Si aparecen solo al final, el equipo puede estar evaluando un objetivo distinto del que orientó la construcción. Definir pronto el resultado permite pedir demostraciones concretas, en lugar de discutir de forma genérica si todo está listo.
Para preparar el siguiente paso, consulta Crear productos digitales con IA.
Comprueba los datos y el estado después de cada acción
Una tarea solo queda demostrada cuando la información recibida, guardada y presentada corresponde a la regla definida. Compara el estado anterior con el resultado de la acción y vuelve a abrir el registro. La interfaz puede mostrar una confirmación sin que la operación haya producido el efecto esperado en el sistema que sostiene la aplicación.
En el ejemplo de las citas, reserva un horario con una cuenta de prueba y consulta la reserva desde la vista del equipo. Comprueba la fecha, el servicio y el estado. Después cierra la sesión y vuelve a entrar. El objetivo es distinguir un resultado persistente de una actualización temporal que solo existió en pantalla.
Si hay cálculos, prepara ejemplos cuyo resultado puedas confirmar. Una suma, una clasificación o una regla de distribución necesita valores de entrada conocidos. No aceptes únicamente que la aplicación presenta un número. Quien valida debe poder explicar por qué ese es el resultado correcto para el caso ensayado.
Observa también las actualizaciones incompletas. Una fuente externa puede no devolver todos los campos o estar indisponible. Define qué muestra la aplicación en esa situación y cómo se evita presentar información antigua como actual. El criterio de conclusión debe incluir una respuesta comprensible a los fallos relevantes de ese proceso.
El trabajo de probar una automatización antes de entregarla al equipo ayuda a organizar estas pruebas. Reúne el caso preparado, el resultado esperado y la evidencia observada. Si el ensayo utilizó datos simulados, identifica ese alcance para no convertir una simulación en una confirmación de la integración real.
Valida quién puede realizar cada parte del trabajo
La aceptación debe incluir los perfiles que utilizarán la aplicación y las acciones que cada uno puede ejecutar. Comprueba accesos permitidos y rechazados con cuentas adecuadas al ensayo. Una demostración realizada solo con la cuenta de administración no prueba que el equipo tendrá los permisos correctos cuando empiece a trabajar.
En el ejemplo hipotético, quien atiende a los clientes puede necesitar consultar citas, mientras otra persona gestiona la disponibilidad. Si ambas reciben acceso total para que la demostración salga bien, queda sin resolver una decisión operativa. Las cuentas de prueba deben representar las responsabilidades que existirán en el uso normal.
También importa comprobar la ubicación del proyecto y el control de los servicios. Ya tuve que corregir la creación de un repositorio en mi cuenta personal cuando el objetivo era dejarlo en la cuenta de la empresa. El código existía, pero el equipo no tenía la continuidad prevista desde sus propios accesos.
Este cuidado no obliga a entregar todo de la misma forma en todos los proyectos. Exige que la organización sepa quién controla el código, los datos y la operación según el modelo elegido. La entrega está incompleta cuando solo quien construyó puede explicar dónde quedó el trabajo o publicar una corrección necesaria.
Por eso, definir quién aprueba qué al trabajar con un equipo externo también forma parte de la aceptación. La decisión sobre el contenido y la decisión técnica pueden pertenecer a personas distintas. Identifica quién confirma cada dimensión sin convertir una prueba técnica en una aprobación de negocio que nadie dio.
Distingue el entorno probado del entorno entregado
El resultado debe comprobarse en las condiciones en que estará disponible, con la configuración y los accesos previstos. Una prueba local puede demostrar parte del trabajo sin confirmar el servicio publicado. Registra el entorno utilizado y las dependencias que todavía necesitan configuración o validación antes de que el equipo utilice la aplicación.
Una aplicación puede funcionar en el ordenador de quien la creó porque allí existen archivos o configuraciones que no se han preparado en otro entorno. La prueba de entrega debe revelar esas dependencias. Quien recibe necesita saber qué está disponible, qué debe configurar y quién asume esa tarea antes del uso habitual.
Las integraciones merecen una distinción parecida. El sistema puede mostrar un mensaje de “enviado” porque la prueba simuló la respuesta de un servicio. Eso permite comprobar el comportamiento interno, pero no confirma la recepción por una persona real. Cuando esa confirmación forma parte del objetivo, hace falta un ensayo autorizado y una comprobación apropiada.
Evita resolver esta diferencia enviando mensajes o creando operaciones reales sin control. Prepara destinatarios, datos y condiciones de prueba acordados. La aceptación debe producir evidencia sin introducir trabajo indebido en la operación del negocio. El plan del ensayo debe aclarar qué efectos están permitidos y cómo se reconocerán cuando sucedan.
Después de ponerla a disposición del equipo, confirma de nuevo los recorridos esenciales desde una sesión normal de uso. Comprueba también un dispositivo relevante, como el móvil de quien gestiona citas fuera de la oficina. La conclusión debe corresponder al contexto de uso previsto, más allá de la demostración que resulte más cómoda.
Cierra con pendientes explícitos y responsabilidades definidas
El cierre debe indicar qué se ha aceptado, qué pruebas lo respaldan y qué asuntos pendientes tienen responsable y siguiente paso. Distingue una mejora futura de un fallo que impide cumplir el objetivo principal. El equipo puede decidir con mayor claridad cuando recibe un estado concreto, en lugar de un mensaje genérico de conclusión.
Un informe breve puede asociar cada requisito con la prueba realizada y su resultado. Si la reserva funciona, pero la recuperación de acceso todavía falla, ambas informaciones deben aparecer separadas. El agente no debe presentar el promedio del trabajo como éxito cuando una condición necesaria para utilizarlo sigue sin cumplirse.
Hay diferencias que se pueden aceptar conscientemente. Una exportación adicional puede quedar para una fase posterior si no era necesaria para el objetivo acordado. Perder reservas o exponer datos de otra persona cambia las condiciones de uso. La prioridad debe resultar del impacto en el proceso y de las decisiones de los responsables.
Registra también quién atiende los fallos después de la entrega y dónde está la información necesaria para investigarlos. Eso incluye el historial de cambios y las instrucciones de operación adecuadas al alcance del proyecto. Quien utilizará la aplicación no necesita memorizar su construcción, pero debe saber cómo obtener ayuda y mantener la continuidad.
Daría el trabajo por terminado cuando una persona autorizada puede realizar las tareas acordadas, los resultados se han comprobado y las responsabilidades posteriores están claras. La IA puede ayudar a organizar toda esa evidencia. La frase “he terminado” resulta útil cuando viene acompañada de pruebas que permiten aceptar la aplicación en las condiciones acordadas.