En un banco o una fintech, la fase de pruebas UAT suele llegar con el calendario apretado. El equipo de desarrollo cerró los errores, QA dio el visto bueno y el área de negocio tiene una semana para firmar la aceptación. Se revisan los casos de prueba, se marcan las casillas y el producto sale. Semanas después, el centro de contacto empieza a recibir llamadas porque los clientes no logran pasar la validación facial o no entienden por qué su solicitud quedó "en estudio".
El problema no fue el UAT en sí. Fue quién lo hizo. Esta guía explica cómo planear un user acceptance testing en banca y fintech que incluya a clientes reales, qué cambia frente al UAT interno y cómo manejar la sensibilidad regulatoria de estos productos.
Qué son las pruebas UAT y por qué en banca pesan más
El user acceptance testing es la última validación antes de salir a producción. Su pregunta es: ¿este sistema sirve para lo que el negocio y el usuario necesitan? No se trata de encontrar errores de código (eso ya lo hizo QA), sino de confirmar que los flujos funcionan en condiciones reales.
En banca y fintech hay tres razones para tomarlo más en serio que en otras industrias:
- El costo de un error es alto. Un registro que falla puede significar un cliente que no vuelve a intentar, una queja ante el regulador o una mala reseña que frena a otros.
- Los flujos son largos y frágiles. Apertura de cuenta, validación de identidad, solicitud de crédito, vinculación de tarjetas. Cada paso depende de servicios externos (centrales de riesgo, registraduría, proveedores biométricos).
- La base de usuarios es enorme y diversa. El mismo flujo lo usa un estudiante con un celular nuevo y un pensionado con un equipo de hace seis años y la cédula amarilla desgastada.
Si quieres repasar los principios generales de un buen UAT, tenemos una guía sobre las claves de éxito del UAT. Aquí nos enfocamos en el contexto financiero.
UAT interno vs. UAT con clientes reales
La mayoría de los bancos hace UAT interno: analistas de negocio, product owners o empleados de otras áreas ejecutan casos de prueba en un ambiente de certificación. Es necesario, pero tiene límites claros.
El UAT interno valida:
- Que los casos de prueba definidos se cumplan.
- Que las reglas de negocio estén bien implementadas.
- Que las integraciones respondan.
El UAT con clientes reales valida además:
- Que una persona que no conoce el producto entienda qué le pides y por qué.
- Que la validación de identidad funcione con su documento, su cámara y su luz.
- Que los mensajes de error le digan qué hacer.
- Que confíe lo suficiente para entregar sus datos.
- Que el flujo funcione en sus dispositivos y redes, no en los equipos corporativos.
Un empleado del banco sabe que "clave dinámica" y "clave principal" son cosas distintas. Un cliente nuevo no. Un analista toma la foto de su cédula en una oficina bien iluminada. El cliente la toma de noche, en la cocina. Ese contexto no aparece en un ambiente de certificación.
La recomendación es hacer ambos: el UAT interno para cerrar reglas de negocio y el UAT fintech con usuarios reales para validar la experiencia antes del despliegue.
Validación de identidad y onboarding: el punto más sensible
Si hay un flujo que merece UAT con clientes reales en cualquier entidad financiera es el onboarding digital. Ahí se cruzan biometría facial, lectura de documento, consulta en listas, firma de términos y creación de credenciales.
Lo que suele aparecer cuando se prueba con usuarios reales:
- Reintentos frecuentes en la captura del documento o de la selfie.
- Variación por dispositivo: cámaras de gama baja que no enfocan, equipos que no permiten el acceso a la cámara desde el navegador.
- Variación por documento: cédulas desgastadas, formatos antiguos, documentos de menores.
- Instrucciones poco claras: el usuario no sabe si debe quitarse los lentes, si debe acercar más el documento o si el proceso falló.
- Falta de información de estado: el usuario no sabe si su cuenta quedó abierta, pendiente o rechazada.
Profundizamos este tema en el artículo sobre cómo validar el onboarding digital y la verificación de identidad con usuarios reales.
Sensibilidad regulatoria: cómo hacer UAT sin poner en riesgo datos
Las pruebas de aceptación de usuario en banca tocan datos personales y, a veces, datos financieros. Eso exige cuidado, no evitar la prueba. Buenas prácticas:
- Ambiente controlado. Trabaja sobre una versión beta, un piloto con usuarios invitados o un ambiente con datos de prueba cuando el flujo lo permita.
- Consentimiento informado. Cada participante sabe qué va a hacer, qué datos se recogen y para qué.
- Tratamiento de datos conforme a la ley. En Colombia, la Ley 1581 de 2012 (Habeas Data) define cómo se recogen, almacenan y usan los datos personales.
- Confidencialidad. Acuerdos de confidencialidad con participantes cuando el producto no se ha lanzado.
- Minimización. Si la prueba no necesita el número de cuenta o los ingresos del participante, no los pidas.
- Perfiles especiales con acompañamiento. Si el producto incluye menores de edad, la participación pasa por sus padres o tutores.
Cómo planear un UAT con clientes reales paso a paso
- Define los flujos críticos. No todo necesita UAT con clientes. Prioriza apertura, validación de identidad, primer ingreso, transacciones principales y recuperación de acceso.
- Define criterios de aceptación medibles. Por ejemplo: porcentaje de usuarios que completan la apertura, número promedio de intentos en la validación facial, comprensión de la propuesta de valor.
- Diseña la muestra. Edad, ciudad, tipo de dispositivo, sistema operativo, estado del documento, si son clientes o no. Para validaciones biométricas la muestra debe ser amplia y diversa.
- Prepara el ambiente y los escenarios. Beta, piloto o producción controlada. Define qué escenarios de error vas a provocar o a observar.
- Ejecuta y registra. Cada intento, cada error, cada mensaje que el usuario no entendió.
- Analiza por severidad y por perfil. Un fallo que solo ocurre en cierto rango de edad o con cierto dispositivo es igual de importante si ese segmento es grande en tu base.
- Corrige y vuelve a probar los puntos críticos antes del despliegue masivo.
Este es el tipo de trabajo que hacemos en el servicio para evaluar productos, apoyados en una comunidad de más de 2.500 participantes por país, más de 65 criterios de perfilación y más de 5.000 dispositivos digitales.
Casos reales: Davivienda, Daviplata y Bancolombia
- Validación de identidad en Davivienda Móvil. Davivienda quería medir la efectividad de la validación biométrica en la apertura de cuentas y en transacciones. Paruma seleccionó más de 150 participantes con perfiles diversos (dispositivo, edad, rasgos, estado del documento, entre otros) que pasaron por distintos escenarios. Se identificaron reintentos frecuentes y la necesidad de instrucciones más claras y familiares. La efectividad de la validación pasó del 70% al 90%, y las mejoras se hicieron sin afectar a los más de 7,5 millones de usuarios de la app. Ver el caso de validación de ID de Davivienda.
- Cuentas para menores en Daviplata. Para abrir cuentas a jóvenes de 14 a 17 años, Daviplata trabajó con Paruma convocando a padres o tutores interesados. La investigación se hizo en varias fases, desde la beta hasta producción, para evaluar la validación de identidad y entrenar la inteligencia artificial del proceso. Los menores entendieron bien el flujo, se identificó la necesidad de mejorar la efectividad de la validación y se implementaron mensajes de error más efectivos. Lee el caso de validación de ID de menores.
- Adelanto de sueldo en Daviplata y Día a Día en Bancolombia. En el adelanto de sueldo, la prueba con usuarios mostró interés claro y un proceso efectivo, pero también poca profundidad en la comprensión y la sugerencia de tiempos de aprobación más rápidos. En "Día a Día" de Bancolombia, el equipo del banco entrevistó a 10 participantes reclutados por Paruma y Paruma hizo una investigación UX con perfiles similares; la validación de la categorización de gastos alcanzó una percepción favorable de 86,79%.
Preguntas frecuentes
¿Qué diferencia hay entre UAT y QA?
QA verifica que el sistema cumpla las especificaciones técnicas y funcionales. Las pruebas UAT (user acceptance testing) verifican que el sistema sirva para lo que el negocio y el usuario necesitan. QA pregunta si funciona como se diseñó; UAT pregunta si lo que se diseñó funciona para quien lo va a usar.
¿Se puede hacer UAT con clientes reales en un banco sin exponer datos?
Sí. Se trabaja en ambientes beta o pilotos controlados, con consentimiento informado, acuerdos de confidencialidad con los participantes y tratamiento de datos bajo la Ley 1581 de 2012 de Habeas Data en Colombia. Los datos sensibles que no se necesitan para la prueba no se recogen.
¿Cuántos participantes necesita un UAT de validación de identidad?
Más que un test de usabilidad típico, porque los fallos dependen del dispositivo, la cámara, la luz, la edad del usuario y el estado del documento. En el caso de Davivienda se trabajó con más de 150 participantes de perfiles diversos para cubrir esa variación.
¿En qué momento del proyecto conviene hacer el UAT con usuarios reales?
Después de que QA cierre los errores críticos y antes del despliegue masivo. Lo más común es hacerlo sobre la versión beta o en un piloto con un grupo controlado, con tiempo suficiente para corregir antes de abrir a toda la base de clientes.
¿Cuánto dura un UAT con usuarios reales?
Depende del número de flujos y perfiles. Como referencia, una evaluación típica con Paruma toma entre una y cuatro semanas, incluyendo perfilación, reclutamiento, ejecución, análisis y entrega de hallazgos.
¿Tienes un UAT en el calendario?
Si estás por certificar un onboarding, una validación de identidad o un nuevo producto de crédito, cuéntanos qué flujo es, qué perfiles necesitas y cuándo debe salir. Diseñamos un UAT con clientes reales que encaje con tu proceso de certificación. Contáctanos aquí.
