User acceptance testing: la guía del founder no técnico
Cómo decidir si el software que tu proveedor entregó está realmente terminado, qué probar cuando no lees código, y cómo definir “terminado” antes de que se escriba la primera línea.
Un founder con el que trabajamos nos reenvió una vez un correo de una línea de su desarrollador: “Todas las features listas, se puede lanzar.” Había pagado por un portal de clientes durante cuatro meses. Antes de transferir la última cuota, nos hizo una pregunta simple: ¿cómo sé que eso es cierto?
No leía código. No sabía distinguir una suite de pruebas en verde de una captura de pantalla de una. Lo que tenía era la sensación de que “se puede lanzar” era la opinión del desarrollador, no un hecho que él pudiera comprobar. Esa distancia, entre que alguien te diga que el trabajo está terminado y que tú sepas que lo está, es exactamente la distancia que cierra el user acceptance testing.
User acceptance testing (UAT) es la comprobación final antes de que el software entre en producción, donde usuarios reales confirman que el producto hace lo que el negocio realmente necesita, en condiciones reales. No se trata de encontrar bugs en el código. Se trata de responder una pregunta: ¿esta cosa hace el trabajo por el que pagamos? Para un founder no técnico, el UAT es la hora más importante que vas a invertir en un proyecto, porque es la única parte del proceso que estás capacitado para dirigir sin saber programar.
Qué es user acceptance testing de verdad
La mayoría de las definiciones que encuentras en internet están escritas para ingenieros de QA, así que entierran la parte que te importa. Quitando lo accesorio, el UAT es esto: una persona que representa al negocio usa el software como lo haría un cliente o empleado real, contra una lista escrita de lo que debería hacer, y da el visto bueno solo cuando cada punto funciona.
El “user” en user acceptance testing es lo esencial. El organismo de estándares de la propia industria del software, el ISTQB, define la prueba de aceptación como la que establece si un sistema debe aceptarse, que es una forma educada de decir que existe para responder una pregunta de negocio de sí o no. Las pruebas anteriores comprueban si el código se comporta como pretendían los ingenieros. El UAT comprueba si lo que pretendían los ingenieros es lo que el negocio necesitaba. Son preguntas distintas, y la segunda es tuya. Un desarrollador puede construir un flujo de checkout impecable que cobra la tasa de impuesto equivocada para tu mercado. El código es correcto. El producto está mal. Solo quien entiende del negocio detecta eso, y esa persona sueles ser tú.
Por eso el UAT es trabajo del founder, no del proveedor. Cuando externalizas el build a una software house o a un freelancer, puedes externalizar la ingeniería, la arquitectura, incluso la gestión del proyecto. Lo que no puedes externalizar es el juicio sobre si el resultado sirve a tu negocio. Eso se queda con quien es dueño del resultado de negocio.
UAT frente a QA: quién prueba qué
Los founders confunden los dos todo el tiempo, y la confusión cuesta dinero. Aquí va la división limpia.
Quality assurance (QA) es responsabilidad del desarrollador. Es la prueba interna, hecha por gente del equipo de build, comprobando que el software funciona como se especificó: los botones responden, los datos se guardan, la API devuelve lo que debe, nada se cae bajo carga. Los buenos proveedores hacen esto antes de mostrarte el producto. Si una pantalla lanza un error en el momento en que la abres, el QA falló, y eso es cosa de ellos.
User acceptance testing es responsabilidad tuya. Ocurre después de que el QA pasa, y comprueba algo que el QA no puede: si “funciona como se especificó” coincide con “funciona para el negocio”. El QA del proveedor confirma que el generador de facturas produce un PDF. Solo tú confirmas que el PDF lleva la razón social de tu empresa, las condiciones de pago correctas y el desglose de impuestos que tu contador necesita.
La regla práctica que damos a los founders: si el fallo es “el software está roto”, eso es QA, devuélvelo sin ceremonia. Si el fallo es “el software funciona pero no es lo que necesitamos”, eso es UAT, y es una conversación sobre alcance, no un reporte de bug. Saber en qué cubo cae un problema te dice si tienes derecho a un arreglo gratis o si estás pidiendo trabajo nuevo. Escribimos más sobre cómo el alcance se expande sin que nadie lo note en nuestro texto sobre feature creep, y el UAT es donde esa tensión sale a la superficie.
El error que convierte el UAT en una pelea
Aquí está la trampa. La mayoría de los founders no técnicos oye las palabras “user acceptance testing” por primera vez al final del proyecto, cuando el proveedor dice “estamos listos para tu visto bueno”. A esas alturas ya es tarde para hacerlo bien, porque el UAT no tiene sentido sin criterios de aceptación, y los criterios de aceptación tienen que existir antes de que empiece el build.
Los criterios de aceptación son las condiciones escritas, específicas y comprobables que definen “terminado” para cada feature. No “construir un sistema de login”. En cambio: “un usuario puede registrarse con correo y contraseña, recibe un correo de confirmación en menos de dos minutos, puede restablecer una contraseña olvidada y queda bloqueado tras cinco intentos fallidos”. Eso es algo que puedes probar. “Un sistema de login” es algo sobre lo que se puede discutir.
La razón por la que esto importa tanto a los founders que no escribieron la especificación ellos mismos: si “terminado” nunca se definió por escrito, entonces al final del proyecto “terminado” se vuelve lo que el proveedor diga que es, y no tienes base para discrepar. Hemos visto a founders perder esta discusión en tiempo real. El desarrollador dice que la feature está completa. El founder siente que no lo está. Ninguno de los dos puede señalar un documento. El founder paga, porque la alternativa es una pelea con quien tiene su código en la mano.
Define los criterios al principio y la dinámica se invierte. Ahora “terminado” es una checklist que ambas partes acordaron, y el UAT no es más que recorrer la checklist. Por eso los criterios de aceptación pertenecen a dos documentos antes de que alguien escriba código: tu documento de requisitos de software, donde cada feature recibe sus condiciones comprobables, y tu contrato de desarrollo de software, donde la aceptación se ata al pago final. Si tu contrato libera la última cuota con la “entrega” en lugar de con la “aceptación”, corrígelo antes de firmar. La palabra carga mucho peso.
Un playbook de UAT que corres sin escribir código
No necesitas saber cómo se construye el software para correr una prueba de aceptación rigurosa. Necesitas ser organizado y un poco terco. Aquí está la secuencia que entregamos a los founders.
1. Prueba contra los criterios, no contra tu estado de ánimo. Abre los criterios de aceptación que escribiste antes. Ve feature por feature, condición por condición. Para cada una, la respuesta es binaria: hace esto, o no lo hace. Resiste la tentación de probar “cómo se siente”. Las sensaciones son reales, pero son una conversación aparte; ahora estás comprobando hechos contra una lista.
2. Usa datos reales y escenarios reales. Aquí es donde los founders encuentran los problemas que importan. No pruebes la herramienta de facturas con “Empresa de Prueba” y un cargo de un dólar. Corre los números reales de tu mayor cliente de verdad. Corre el caso límite que sabes que es enredado: el reembolso, el pago parcial, el cliente en otra región. Un ejemplo concreto de un build que revisamos: el software manejaba las suscripciones nuevas a la perfección y se rompía por completo en las cancelaciones, porque nadie probó una cancelación. El criterio decía “gestionar suscripciones”. Cancelar es gestionar una suscripción. Salió a producción roto porque el UAT solo probó el camino feliz.
3. Prueba en los dispositivos que tus usuarios usan de verdad. Si la mitad de tus clientes está en el móvil, prueba en el móvil, no solo en el portátil donde el desarrollador hizo la demo. “Funciona en escritorio” no es “funciona”.
4. Anota cada fallo con precisión. “La cosa está con bugs” no ayuda a nadie. “Cuando hago clic en Enviar en el formulario de contacto con un correo de Gmail, no pasa nada, y la página no muestra error” es un reporte sobre el que un desarrollador actúa el mismo día. La especificidad es la diferencia entre un arreglo esta semana y un ida y vuelta que tarda tres.
5. Separa “roto” de “no es lo que quería”. Clasifica cada fallo en los dos cubos anteriores. Roto vuelve como defecto, arreglado sin costo. “No es lo que quería pero coincide con el criterio” es una solicitud de cambio, lo que significa alcance nuevo y posiblemente dinero nuevo. Ser honesto sobre qué es cada cosa evita que la relación con tu proveedor se vuelva adversarial.
6. Da el visto bueno por escrito, criterio por criterio. Cuando una feature pasa, regístralo. Cuando la lista entera pasa, esa es tu aceptación, y ese es el disparador del pago final que tu contrato debería atar. No des el visto bueno al paquete entero en un solo correo para quitártelo de encima. La checklist es tu margen de maniobra y tu registro.
Corre esos seis pasos y habrás hecho algo que la mayoría de los founders nunca hace: cambiaste “creo que está bien” por “esto es lo que verifiqué”. Eso vale más que cualquier conocimiento técnico que no tengas.
Cuando el UAT te dice que algo está mal
A veces la prueba falla y el proveedor empuja de vuelta. Dirá que el punto que falló no estaba en el alcance, o que es un caso límite, o que arreglarlo es extra. De vez en cuando tiene razón. Muchas veces el desacuerdo es exactamente por lo que escribiste criterios con antelación, así que vuelve al documento y mira qué dice. Si los criterios lo cubrían, es un defecto. Si no lo cubrían, aprendiste algo sobre tu propia especificación, y ahora estás negociando un cambio, no litigando una opinión.
Si el UAT saca a la luz problemas lo bastante profundos como para que empieces a dudar del build entero, esa es una señal distinta y más seria. Una sola feature rota es un arreglo. Un patrón de features que técnicamente corren pero fallan de forma consistente en la necesidad del negocio suele significar que la especificación y el builder nunca estuvieron de verdad alineados, y ninguna dosis de prueba de aceptación remienda eso. Ese es el momento de traer una lectura independiente del código antes de echar más dinero. Cubrimos cómo hacerlo en nuestra guía de technical due diligence.
La versión sana de esta relación no es un proveedor que pasa cada prueba a la primera. Es un proveedor que hizo su QA en serio lo suficiente como para que tu UAT encuentre brechas de encaje con el negocio, no caídas, y que trata tu checklist como el contrato que es. Los buenos quieren los criterios al principio tanto como deberías quererlos tú. Los protege a ellos también.
Preguntas frecuentes
¿Qué es user acceptance testing en términos simples?
Es la comprobación final, hecha por alguien que representa al negocio, que confirma que el software terminado hace lo que la empresa realmente necesita antes de entrar en producción. Prueba la adecuación al propósito, no la calidad del código.
¿Cuál es la diferencia entre QA y UAT?
QA es el equipo de build confirmando que el software funciona como se especificó. UAT eres tú confirmando que la especificación era correcta para el negocio. QA detecta “está roto”. UAT detecta “funciona pero está mal”.
¿Cuál es un ejemplo de user acceptance testing?
Correr los números reales de tu mayor cliente en una herramienta nueva de facturas, incluyendo un reembolso y un pago parcial, y confirmar que cada factura muestra la razón social, las condiciones de pago y los impuestos correctos. Si cada condición de tu lista escrita pasa, la feature se acepta.
¿Quién debería dirigir el UAT en una startup?
Quien es dueño del resultado de negocio, normalmente el founder o quien escribió los requisitos, posiblemente con uno o dos usuarios reales. No debería dirigirlo el proveedor que construyó el producto; eso anula el propósito.
¿Cuánto gana un tester de UAT?
Esa pregunta viene de quien investiga carreras de QA, no de founders comprando software. Para tu caso, el UAT no es un puesto asalariado en un build pequeño; es una responsabilidad que cargas como comprador. En productos más grandes existen testers dedicados, pero la aceptación de negocio sigue siendo del negocio.
¿Cuándo deben escribirse los criterios de aceptación?
Antes de que empiece el build, dentro de tu documento de requisitos, y referenciados en tu contrato. Los criterios escritos después de la entrega son casi inútiles, porque a esas alturas “terminado” es lo que el proveedor diga que es.