Cómo revisar y aprobar las entregas de tu app: la guía de pruebas de aceptación para no técnicos

Qué es una prueba de aceptación y por qué la firmas tú, no el programador

Imagina que encargas una reforma en tu local. El día que el arquitecto dice «ya está», no te fías solo de su palabra: enciendes las luces, abres los grifos, compruebas que las puertas cierran. Con una app a medida pasa lo mismo. Las pruebas de aceptación (en inglés, UAT) son ese momento en el que tú, como cliente, revisas lo que el equipo ha construido y decides si cumple lo acordado antes de darlo por bueno y pagar la factura.

La clave está en quién aprueba. El equipo técnico prueba que el código funciona a su nivel: que no se rompe, que carga rápido, que guarda bien los datos. Eso son las pruebas internas, y no son cosa tuya. Pero hay una pregunta que solo tú puedes responder: «¿esta app hace lo que mi negocio necesita?». Un desarrollador puede construir una pantalla de reservas impecable y, aun así, haberse olvidado de que en tu peluquería trabajáis con turnos de media hora y no de una. El código está perfecto; el negocio, mal reflejado. Por eso la aprobación final es tuya: tú conoces a tus clientes, tus procesos y las manías de tu sector. El programador, no.

Aceptar una entrega no es un trámite: es la barrera que separa «esto ya está listo para mis clientes» de «esto todavía tiene fallos». Firmar a la ligera sale caro, porque un error que se cuela en producción y afecta a un cobro o a un registro puede costarte clientes reales y horas de soporte.

Los criterios de aceptación: pactarlos antes de escribir la primera línea

El error más común que vemos en pymes es dejar para el final la pregunta «¿cómo sabremos que esto está bien?». Cuando esa conversación llega tarde, se convierte en discusión: tú crees que faltan cosas, el equipo cree que ha entregado lo pactado, y nadie tiene un papel donde mirar. La solución se acuerda al principio del proyecto: los criterios de aceptación.

Un criterio de aceptación es una frase concreta, en lenguaje de persona normal, que describe qué debe pasar para dar una función por válida. No hace falta saber de programación para redactarlos junto a tu agencia. Fíjate en la diferencia entre una petición vaga y un criterio claro:

Vago: «que se pueda pagar dentro de la app».
Criterio de aceptación: «un cliente puede pagar un pedido con tarjeta; si el pago se aprueba, recibe un correo de confirmación en menos de un minuto y el pedido aparece como Pagado en el panel de administración; si el pago se rechaza, ve un mensaje claro y el pedido no se crea».

La segunda versión no deja hueco a la interpretación: el día de la prueba coges esa frase, la ejecutas paso a paso y compruebas si se cumple o no, sin dramas ni opiniones. Una buena agencia te ayuda a escribir estos criterios para cada hito antes de empezar, porque ahí se ahorran la mitad de los malentendidos. Guárdalos en un documento compartido y tenlos a mano en cada entrega: son tu lista de la compra.

El entorno de pruebas: dónde ves la app antes de que exista para el público

Cuando el equipo te dice «ya tienes la beta lista para probar», te da acceso a una versión de la app que todavía no está publicada en las tiendas: una copia funcional para que la revises en tu propio móvil, con datos de mentira y sin miedo a romper nada. Suele llegarte por una de estas dos vías, según el sistema:

En iPhone, lo normal es que te inviten a través de TestFlight, una app gratuita de Apple. Recibes un enlace, instalas TestFlight y desde ahí descargas la beta. Estas versiones caducan a los pocos meses, así que es normal que te pidan reinstalar de vez en cuando.
En Android (Samsung, Xiaomi, Google y demás), suele hacerse con las pruebas de Google Play: te añaden a una lista de testers con tu correo de Google y accedes a la app por un enlace especial de la tienda.

Un detalle importante: prueba siempre en tu teléfono de verdad, no solo en el ordenador del desarrollador durante una videollamada. Muchos fallos solo aparecen en condiciones reales: en el metro con mala cobertura, al girar el teléfono, al recibir una llamada a mitad de un pago. Si puedes, prueba en dos móviles distintos, uno algo antiguo incluido: lo que va fino en un iPhone recién comprado puede arrastrarse en un Android de hace cuatro años, que es justo el que tienen muchos de tus clientes.

Cómo probar sin ser técnico: piensa como tu cliente más despistado

No tienes que auditar código ni entender qué es una API. Tu superpoder es otro: eres quien mejor conoce cómo se usará la app en la vida real. La forma más eficaz de probar es recorrer flujos completos, de principio a fin, tal y como los haría un cliente. Un flujo no es tocar botones sueltos; es una historia con principio y final.

Piensa en los recorridos que de verdad importan para tu negocio y pruébalos enteros. Estos son los sospechosos habituales:

Registro y acceso: crea una cuenta con un correo real, cierra sesión, vuelve a entrar. Prueba también el «he olvidado mi contraseña». Es el primer flujo de todos y donde más gente se pierde.
El proceso central de tu negocio: reservar una mesa, pedir una cita, comprar un producto. Hazlo completo, hasta el final, y comprueba que el resultado aparece donde debe.
El pago: si hay cobros, es lo más delicado. Comprueba un pago que sale bien y también uno que se rechaza. Revisa que el importe es correcto, que los euros aparecen con sus decimales bien puestos y que el IVA cuadra. Un céntimo mal en un cobro real es una reclamación segura.
Las notificaciones: ¿te llega el aviso al móvil cuando toca? ¿El correo de confirmación entra en la bandeja o cae en spam?
Los casos raros: ¿qué pasa si dejas un campo vacío? ¿Si escribes letras donde va un teléfono? ¿Si le das dos veces seguidas al botón de comprar? Tus clientes harán todas esas cosas, créeme.

Una técnica que funciona muy bien: prueba con datos reales de tu día a día, no con «prueba prueba 123». Usa el nombre de un cliente habitual, una dirección real, un importe que cobrarías de verdad; los datos reales sacan a la luz fallos que los de mentira esconden. Y ve apuntando todo sobre la marcha: en media hora de pruebas aparecen más cosas de las que luego recuerdas.

Reportar un error para que se pueda arreglar de verdad

Aquí está el punto donde muchos clientes, sin querer, hacen perder tiempo a todos. Escribir «el pago no va» en un WhatsApp no ayuda: el desarrollador no sabe qué hiciste, con qué móvil, ni qué viste en pantalla, y no puede arreglar lo que no consigue reproducir. Un buen reporte convierte una queja en una tarea que se resuelve rápido.

Qué anotar en cada fallo

Cada vez que encuentres un problema, apunta estas cosas; cuanto más completo, antes se soluciona:

Qué esperabas que pasara: «esperaba ver la confirmación del pedido».
Qué pasó en realidad: «la pantalla se quedó en blanco y la app se cerró sola».
Los pasos exactos para reproducirlo: «1) entré con mi cuenta, 2) añadí dos productos al carrito, 3) le di a Pagar, 4) metí la tarjeta y confirmé». Estos pasos son oro puro: si el equipo repite tu recorrido, ve el fallo con sus propios ojos.
Una captura de pantalla o un vídeo corto: en el móvil se hace en un segundo y vale más que tres párrafos.
Con qué lo probaste: qué móvil (por ejemplo, «iPhone 13» o «Samsung Galaxy A54») y con qué conexión. Un fallo que solo pasa en Android es una pista enorme para quien lo va a arreglar.

Reúne todos los fallos en un único sitio, no repartidos entre correos, mensajes y notas de voz. Una hoja compartida o la herramienta que use tu agencia sirve de sobra: así el equipo trabaja de una lista ordenada y tú ves de un vistazo qué se ha corregido y qué queda pendiente.

Un bug no es lo mismo que un cambio de alcance (y tu factura lo nota)

Esta distinción es la que más discusiones evita. Un bug es cuando algo que se pactó no funciona como debía: el botón de pagar da error, el correo de confirmación no llega, la lista de citas muestra fechas equivocadas. Corregir un bug entra en el precio que ya acordaste; es responsabilidad del equipo dejarlo bien.

Un cambio de alcance es otra cosa: pedir algo nuevo que no estaba en lo acordado. «Ahora que lo veo, quiero que además se pueda pagar con Bizum», «añade un chat entre usuarios», «que las reservas se sincronicen con mi Google Calendar». Pueden ser ideas estupendas, pero son trabajo adicional, con su propio presupuesto y su plazo. No es que la agencia te quiera cobrar de más; es que estás encargando algo que antes no existía.

Por eso los criterios de aceptación del principio valen su peso en oro: son el árbitro. Cuando surge la duda de «¿esto es un fallo o es algo nuevo?», vais al documento. Si lo que probaste incumple un criterio que firmasteis, es un bug y se arregla sin coste; si es una función que nunca estuvo en la lista, es una mejora que se valora aparte. Y ojo, no hay nada malo en pedir cambios de alcance: casi todos los proyectos crecen al ver la app funcionando. Lo importante es llamarlos por su nombre y decidir juntos si entran en esta fase o en la siguiente.

Cómo llevar una sesión de aceptación ordenada

Cuando llega una entrega, no la revises con prisas cinco minutos antes de una reunión. Reserva un rato tranquilo, coge tu lista de criterios y ve marcando uno a uno: cumple, no cumple, o duda. Prueba cada flujo importante hasta el final, apunta los fallos con el detalle de arriba, y solo cuando la lista está en verde das el hito por aceptado.

Es normal que la primera entrega de cada hito venga con cosas por pulir. No significa que el equipo lo haya hecho mal; significa que el proceso funciona. Se reportan los fallos, se corrigen, y vuelves a probar solo lo que estaba mal (y de paso, que arreglar una cosa no haya roto otra). Dos o tres rondas hasta dejarlo fino es lo habitual. Lo que no debes hacer es aprobar «para no molestar» o por prisa: una vez que firmas y el hito se cierra, arreglar lo que pasaste por alto sale más caro para todos. Guarda además un registro sencillo de qué aprobaste y cuándo; dentro de seis meses, cuando dudes de si algo entraba en el acuerdo, ese historial te dará la respuesta en treinta segundos.

No tienes que hacerlo solo

Revisar entregas da algo de vértigo la primera vez, pero no es tu trabajo saber de tecnología: es tu trabajo saber de tu negocio, y en eso no te gana nadie. Lo demás, una agencia que trabaje bien te lo pone fácil: te prepara los criterios de aceptación en cristiano, te guía en cada prueba, te enseña a instalar la beta y a mandar un buen reporte, y te acompaña en cada ronda hasta que la app está de verdad lista para tus clientes. Esa mano en el hombro es la diferencia entre pagar por un archivo que no sabes si funciona y aprobar con la tranquilidad de haberlo comprobado tú mismo.

En Tangram Consulting llevamos años acompañando a pymes y emprendedores en este proceso, traduciendo lo técnico a decisiones de negocio que puedes tomar sin sudores fríos. Si estás pensando en desarrollar tu app, o ya tienes un proyecto en marcha y quieres hacerlo con alguien que te guíe en cada validación, hablemos de tu app y de cómo la validamos juntos.