Una pantalla puede funcionar y, aun así, el cambio no resolver el problema que motivó su desarrollo. Puede aceptar datos que deberían rechazarse, calcular un importe incorrecto o dejar una operación a medias en un sistema conectado. Por eso, las pruebas de aceptación basadas en reglas de negocio no se limitan a revisar controles visuales: comprueban si el proceso produce el resultado esperado para las personas y la organización.
La clave es partir de decisiones operativas concretas y convertirlas en escenarios que puedan verificarse con datos, resultados y evidencias. Así, producto, negocio, QA y tecnología comparten una definición práctica de qué significa aceptar el cambio.
Comprobar una pantalla no es validar una regla
Una prueba de interfaz puede confirmar que un botón aparece, que un formulario permite escribir o que se muestra un mensaje. Esas comprobaciones pueden ser necesarias, pero no demuestran por sí solas que se respete una política de negocio. Para eso hay que seguir la relación entre una condición y su consecuencia.
Por ejemplo, la pregunta no es solo si una solicitud se puede enviar. También hay que saber qué condiciones determinan su aprobación, qué ocurre cuando falta un dato y qué estado deben recibir los casos que requieren revisión. La regla puede aplicarse en una pantalla, en un servicio o en un proceso manual posterior; la aceptación debe comprobar el resultado relevante sin presuponer dónde está implementada.
Una regla útil para probar expresa una decisión observable: dadas ciertas condiciones de entrada, el proceso debe producir un resultado identificable. Si la regla depende de interpretación, conviene aclararla antes de redactar el caso. Una prueba no debería ser el lugar donde se descubre por primera vez qué significa una política.
Identificar reglas, actores, datos y resultados
Antes de escribir escenarios, reúne a quienes conocen el proceso y a quienes lo implementan. El objetivo es describir qué decisión se toma, quién participa y qué información cambia esa decisión. No hace falta documentar cada detalle del sistema: sí hay que hacer explícitas las condiciones que alteran el resultado.
- Actor: quién inicia o revisa la operación, como una persona usuaria o un perfil de supervisión.
- Condiciones: reglas, permisos, estados previos y restricciones que afectan la decisión.
- Datos de entrada: valores necesarios para ejecutar el escenario, incluidos los que pueden faltar o ser inválidos.
- Resultado esperado: estado final, acción permitida o denegada, cálculo, notificación o tarea que debe generarse.
- Evidencia: cómo se comprobará el resultado, por ejemplo, mediante el estado registrado, una respuesta visible o una actividad en el sistema correspondiente.
Conviene anotar las dudas y asignarles una persona responsable de resolverlas. Si una regla tiene excepciones, identifica quién puede autorizarlas y cómo queda constancia. No conviertas una suposición del equipo en un requisito silencioso.
Convertir reglas en escenarios claros y observables
Redacta cada escenario con contexto suficiente para que otra persona pueda ejecutarlo y evaluar el resultado. Una estructura sencilla es: dadas unas condiciones, cuando se realiza una acción, entonces se espera un resultado concreto. La forma importa menos que la precisión: entradas y expectativas deben ser explícitas.
- Describe una situación de negocio reconocible, no un recorrido de clics sin propósito.
- Indica los datos y el estado inicial necesarios para reproducirla.
- Expresa qué acción inicia la decisión o el proceso.
- Define el resultado que debe observarse y dónde verificarlo.
Un criterio como “el sistema gestiona correctamente la solicitud” no puede aprobarse de manera consistente. En cambio, un criterio verificable especifica qué solicitudes se aceptan, cuáles se rechazan o derivan a revisión, y qué estado queda registrado. Si el resultado esperado admite varias interpretaciones, el criterio todavía necesita trabajo.
Evita mezclar demasiadas reglas en un solo escenario. Cuando falle, el equipo debe poder identificar qué comportamiento no coincide con lo acordado. A la vez, no dupliques pruebas que comprueban el mismo resultado con datos equivalentes sin aportar una cobertura distinta.
Cubrir límites y excepciones sin multiplicar casos
El caso habitual sirve para confirmar el recorrido principal, pero rara vez es suficiente. Las reglas suelen cambiar de resultado en un límite, ante un dato ausente o cuando se combinan condiciones. Empieza por preguntar qué dato podría cambiar la decisión y qué ocurre justo antes, justo en el límite y justo después.
Prioriza variaciones que alteren la salida del proceso: valores permitidos y no permitidos, permisos distintos, estados incompatibles, duplicados o información incompleta, siempre que correspondan a las reglas reales. Si varias condiciones son independientes, puedes diseñar una selección representativa en lugar de probar todas las combinaciones posibles. Si una combinación puede cambiar la decisión, debe estar cubierta.
También conviene separar excepción de negocio de error técnico. Una solicitud denegada por una política puede ser un resultado correcto; una interrupción que impide guardar el estado es otra situación. Acordar esa diferencia evita rechazar un cambio porque una regla se aplicó como debía, o aceptar un fallo operativo como si fuera una excepción prevista.
Validar recorridos completos entre sistemas
Cuando intervienen varias aplicaciones o equipos, comprueba el recorrido de extremo a extremo desde el hecho que inicia el proceso hasta el resultado que necesita la operación. No basta con verificar que un sistema envió información: hay que confirmar que el sistema receptor la interpretó y que el estado final es coherente.
Identifica puntos de traspaso, responsables y señales observables. Por ejemplo, ¿qué ocurre si el segundo sistema no está disponible?, ¿se reintenta la operación?, ¿queda pendiente para revisión?, ¿cómo se evita procesarla dos veces? Las respuestas deben reflejar el comportamiento acordado, no capacidades supuestas. Si el recorrido no puede probarse de forma integrada en un entorno disponible, documenta qué tramo se valida por separado y qué incertidumbre queda pendiente.
Un mapa breve del flujo ayuda a distinguir las comprobaciones que pertenecen a la aceptación de las pruebas técnicas de cada componente. La aceptación se centra en la consecuencia operativa; las pruebas de componentes y de integración aportan otras evidencias, pero no sustituyen la validación del resultado de negocio.
Acordar evidencias, responsables y decisión
Antes de ejecutar, acuerda quién prepara los datos, quién realiza cada escenario y quién decide ante una discrepancia. Negocio debe confirmar que el resultado responde a la regla; producto coordina el alcance y las prioridades; QA puede facilitar la cobertura y registrar resultados; tecnología ayuda a diagnosticar el comportamiento. Las responsabilidades pueden variar, pero no deberían quedar implícitas.
Define qué cuenta como evidencia suficiente y cómo se registra: escenario, datos utilizados, resultado observado, estado de aprobación y cualquier incidencia. No es necesario recopilar información sensible que no aporte a la comprobación. Usa datos representativos y autorizados, y prepara una alternativa controlada cuando no sea apropiado emplear datos reales.
La decisión también debe ser explícita. Un fallo en una regla crítica puede bloquear la aceptación; una discrepancia menor podría aceptarse con una acción acordada, si las personas responsables tienen autoridad para decidirlo. En todos los casos, registra el impacto, el responsable y el siguiente paso. No escondas una condición pendiente bajo un “aprobado” ambiguo.
Errores frecuentes y lista de comprobación
Los problemas más comunes son criterios vagos, escenarios centrados solo en el caso ideal, datos que no representan el proceso y pruebas que repiten otras comprobaciones sin verificar una decisión nueva. También es arriesgado validar cada sistema por separado y asumir que el flujo completo funcionará automáticamente. El remedio no es añadir casos sin criterio, sino revisar qué regla, excepción o traspaso todavía no tiene una evidencia clara.
Antes de la sesión de aceptación, comprueba lo siguiente:
- ¿Las reglas y sus excepciones están confirmadas por las personas responsables?
- ¿Cada escenario tiene condiciones iniciales, datos, acción y resultado observable?
- ¿Están cubiertos el recorrido principal, los límites relevantes y las denegaciones esperadas?
- ¿Los casos entre sistemas comprueban el estado final y los fallos de traspaso pertinentes?
- ¿Se sabe quién ejecuta, quién aporta evidencia y quién toma la decisión final?
- ¿Las discrepancias, riesgos pendientes y acuerdos quedan registrados?
Una aceptación eficaz no busca demostrar que todo funciona en cualquier circunstancia. Busca aportar evidencia suficiente de que las reglas relevantes se cumplen en escenarios representativos y de que las excepciones importantes tienen una respuesta acordada. Ese enfoque reduce ambigüedades y permite aceptar, corregir o aplazar un cambio con mejores fundamentos.