Pruebas de aceptación de software: ejemplos para aprobar una entrega
Cómo preparar pruebas de aceptación de software con escenarios reales, responsables y evidencia para aprobar una entrega sin confundir defectos con cambios.
Las pruebas de aceptación de software sirven para responder una pregunta incómoda antes de aprobar una entrega: ¿el producto permite hacer el trabajo que acordamos? Una pantalla puede verse terminada y aun así obligar a operación a corregir todo en una hoja de cálculo.
Cuando alguien dice "ya quedó", conviene tener algo mejor que una impresión. Hace falta un escenario concreto, un resultado esperado y una persona capaz de decir si eso resuelve su trabajo. La demo ayuda. La evidencia decide.
Qué estás aceptando y quién debe probarlo
Las pruebas técnicas comprueban aspectos como cálculos, integraciones, permisos y estabilidad. La aceptación revisa si el comportamiento satisface las necesidades acordadas. Se complementan: que el cliente pueda completar un pedido no demuestra que el sistema sea seguro.
Las UAT son las pruebas de aceptación del usuario, una modalidad de aceptación. No toda aceptación es UAT; también puede responder a condiciones contractuales o regulatorias. El programa de aceptación de ISTQB distingue estas modalidades y pone atención en la colaboración entre negocio y pruebas.
Para una app interna, invita a quien realiza la tarea cotidiana. El patrocinador puede autorizar el proyecto, pero quizá nunca ha tenido que corregir un pedido duplicado. También acuerda quién tiene autoridad para aceptar la entrega. Son responsabilidades distintas y conviene nombrarlas desde el inicio.
Escribe criterios antes de construir
"El usuario puede crear pedidos" deja demasiado a la imaginación. Un criterio útil describe condiciones observables. Por ejemplo, un vendedor autorizado puede confirmar un pedido con existencias disponibles, y el sistema descuenta exactamente la cantidad vendida.
Todavía faltan decisiones. ¿Se permite vender sin existencias? ¿Qué ocurre cuando dos personas intentan comprar la última unidad? ¿Quién puede cancelar? No hay una respuesta universal. Hay reglas de tu negocio que alguien debe definir.
Escribirlas temprano ayuda a delimitar el alcance antes de cotizar. Si aparecen cuando todo está construido, cualquier conversación suena a cambio de último minuto, aunque el problema haya sido un supuesto sin resolver.
Un ejemplo que puedes llevar a la siguiente revisión
Imagina una tienda con una sola unidad disponible. Dos vendedores tienen abierto el mismo producto. La regla acordada impide confirmar ventas sin existencias.
El escenario empieza con ambos usuarios autenticados en sus cuentas de prueba. El primero confirma un pedido por una unidad. Después, el segundo intenta confirmar otro pedido por esa misma unidad. El resultado esperado es que solo exista una venta confirmada, el inventario quede en cero y el segundo vendedor reciba un mensaje claro sin generar un cobro indebido.
Anota qué versión se probó, qué datos se usaron, quién ejecutó el escenario y qué ocurrió. Si falla, guarda pasos reproducibles y evidencia del resultado. "No funciona el inventario" obliga a investigar desde cero; un recorrido preciso permite corregir y repetir la prueba.
Este ejemplo no cubre todas las variantes. Sirve para mostrar qué tan concreta debe ser una prueba. Tu flujo puede ser una cita, una aprobación de gastos o una devolución parcial.
Prepara un ambiente donde equivocarse no cueste dinero
Usa un entorno separado de producción y datos ficticios o anonimizados. Si interviene un proveedor de pagos, configura su modo de pruebas. No necesitas cobrarle a una tarjeta real para demostrar que el flujo funciona.
Confirma los permisos de cada participante. Probar todo con una cuenta administradora puede ocultar que un vendedor no puede completar su trabajo o que ve información que no debería. Las pruebas de aceptación de software deben parecerse a la operación sin poner en riesgo datos o movimientos reales.
Distingue un defecto de una idea nueva
Si el resultado incumple una condición acordada, registra el defecto. Si durante la revisión alguien propone una función que no estaba incluida, registra una solicitud de cambio y evalúa su costo aparte. Mezclar ambas cosas vuelve imposible cerrar cualquier proyecto.
También habrá dudas sobre reglas que nadie definió. Resuélvelas con evidencia y documenta el acuerdo, sin fingir que siempre estuvo claro. Para cada hallazgo deja un responsable y una decisión. Si un problema impide el flujo principal, no lo disfraces de detalle para cumplir la fecha.
Después de corregir, repite el escenario y revisa lo que pudo afectarse. Una captura de la pantalla arreglada no demuestra que el pedido completo ya funciona.
Aceptar la función no termina la entrega
Deja por escrito qué se aceptó, qué versión se revisó y cuáles pendientes se admitieron con sus condiciones. Eso no sustituye los acuerdos contractuales ni la entrega de código, accesos y documentación.
En DevAces preferimos aclarar qué significa "listo" antes de construir. Si estás por contratar una app o recibir una entrega y todavía no sabes cómo evaluarla, cuéntanos qué tarea necesitas resolver. Podemos empezar por ese flujo, sin convertir la revisión en otro proyecto interminable.