≡En resumen
- El journey testing prueba el recorrido entero, no una pantalla aislada: incluye los cambios de canal y los tiempos de espera.
- Con usuarios se valida si el recorrido se entiende; con pruebas automáticas, si sigue funcionando tras cada cambio de código.
- Los diary studies capturan recorridos que duran días o semanas y que un test de una hora no puede reproducir.
- Las tareas deben ser realistas y de principio a fin: «consigue una cita para este jueves», no «pulsa el botón Reservar».
- Conviene probar primero los recorridos críticos, los que más ingresos o contactos generan.
01 ¿Qué es el user journey testing?
El término tiene dos usos. En investigación UX, se prueba con personas reales si el recorrido se entiende y se puede completar. En desarrollo de software, un user journey test es una prueba end-to-end automatizada que simula a un usuario recorriendo el flujo completo, para detectar si un cambio de código lo ha roto. Esta entrada cubre ambos, porque se complementan.
02 Journey testing vs test de usabilidad, test A/B y pruebas unitarias
| Prueba | Qué responde | Alcance | Con quién |
|---|---|---|---|
| Test de usabilidad de una pantalla | ¿Se entiende esta pantalla? | Una vista o componente | 5-8 usuarios |
| User journey testing (UX) | ¿Se puede completar el objetivo de principio a fin? | Recorrido completo, varios canales | Usuarios reales |
| Diary study | ¿Cómo se vive un recorrido largo en su contexto? | Días o semanas | Usuarios reales, a distancia |
| Test A/B | ¿Qué versión convierte más? | Una variación | Tráfico real, sin observación |
| Prueba end-to-end automatizada | ¿Sigue funcionando el flujo tras el último cambio? | Recorrido técnico completo | Un robot en un navegador |
| Prueba unitaria | ¿Funciona esta función de código? | Una pieza de código | Automatizada |
03 Cómo hacer un test de usabilidad de un recorrido completo
-
1
Elige el recorrido y el perfil
Parte del journey map: un tipo de usuario, un objetivo, un escenario. Empieza por un recorrido crítico.
-
2
Prepara un entorno realista
Cuentas de prueba, emails que llegan de verdad, datos de ejemplo creíbles. Si el recorrido incluye una llamada, alguien del equipo la hace.
-
3
Redacta tareas de principio a fin
«Tienes una boda el sábado y necesitas cambiar la talla del vestido que compraste; hazlo». Sin nombres de botones ni pistas.
-
4
Observa las transiciones
Presta especial atención a los cambios de pantalla, de dispositivo y de canal, y a los momentos de espera.
-
5
Mide y pregunta al final
Éxito o fracaso, tiempo, errores y una pregunta abierta: «¿Qué ha sido lo más difícil?».
-
6
Sitúa cada problema en el mapa
Anota en qué fase del journey ocurre y su gravedad, para priorizar después.
04 Diary studies: probar recorridos que duran días o semanas
Muchos recorridos no caben en una sesión de una hora: el alta en un banco, la primera semana en un gimnasio, la adopción de un software en una empresa. Para ellos, Nielsen Norman Group recomienda el diary study, un método cualitativo en el que los participantes registran durante un tiempo lo que hacen, piensan y sienten en su propio contexto.
Por eventos
El participante anota cada vez que ocurre algo relevante (abre la app, llama al soporte). Útil para actividades concretas y poco frecuentes.
Por intervalos
Registros a horas fijas, por ejemplo cada noche. Adecuado para interacciones frecuentes.
Por señal
El equipo envía un aviso y el participante responde en ese momento. Capta actividades variadas en distintos momentos.
Según NN/g, suelen durar de una a tres semanas y reunir de 5 a 12 participantes en proyectos pequeños. Encajan en el conjunto de métodos que explicamos en la guía de UX research, y su resultado alimenta directamente el mapa del recorrido.
05 Pruebas end-to-end automatizadas de journeys críticos
En desarrollo, el journey testing protege los recorridos que no pueden fallar. Google, en su manual de fiabilidad, habla de critical user journeys: secuencias de tareas esenciales para el usuario, como buscar, añadir al carrito y pagar. Una prueba end-to-end automatizada abre un navegador, recorre ese flujo como lo haría una persona y avisa si algo se rompe antes de publicar un cambio.
| Tipo | Cuándo se ejecuta | Qué detecta |
|---|---|---|
| Prueba end-to-end en integración continua | En cada cambio de código, antes de publicar | Regresiones: un botón que ya no envía, un paso que da error |
| Monitor sintético | Cada pocos minutos en producción | Caídas de la pasarela de pago, del login o de un servicio externo |
| Prueba de carga del recorrido | Antes de picos de tráfico | Pasos que se vuelven lentos con muchos usuarios |
| Prueba de accesibilidad automatizada | En cada cambio | Problemas de contraste, etiquetas o navegación con teclado |
06 Métricas para evaluar un recorrido
| Métrica | Qué indica | Cómo se obtiene |
|---|---|---|
| Éxito en la tarea | Porcentaje que completa el recorrido | Observación en el test |
| Tiempo total y por fase | Dónde se pierde más tiempo | Cronómetro o grabación |
| Errores y bloqueos | Pasos donde se equivoca o necesita ayuda | Observación |
| Satisfacción (SUS o una pregunta) | Percepción del recorrido completo | Cuestionario al final |
| Tasa de fallos de la prueba automática | Estabilidad técnica del recorrido | Informe de integración continua o monitor |
Para medir la experiencia a escala, más allá de un test puntual, el marco HEART de Google incluye precisamente el éxito en la tarea como una de sus cinco categorías.
07 Ejemplo de plan de journey testing
Recorrido: encontrar el restaurante, reservar para seis personas un sábado y recibir el recordatorio. Con usuarios: cinco participantes, tarea «Organiza la cena de cumpleaños de tu madre en este restaurante el próximo sábado». Hallazgo: tres no ven que las mesas de más de cuatro personas se reservan por WhatsApp y abandonan. Automatizado: una prueba end-to-end diaria que reserva y cancela una mesa de prueba y avisa si falla el envío de la confirmación.
Los problemas detectados se priorizan y se corrigen en el rediseño, trabajo propio del diseño UX/UI. Si el recorrido ya tiene tráfico suficiente, la versión corregida puede validarse después con datos reales dentro de un plan de optimización de la conversión, y las pruebas automatizadas se integran en el desarrollo web a medida para que no se vuelva a romper.
- ✓Un recorrido crítico, un perfil y un escenario por ronda.
- ✓Entorno con emails, SMS y datos de prueba que funcionen de verdad.
- ✓Tareas de principio a fin, sin nombres de botones.
- ✓Problemas situados en su fase del journey y con gravedad.
- ✓Pruebas automáticas para los recorridos que no pueden fallar.
Preguntas frecuentes sobre User journey testing
Es la comprobación de que un usuario puede completar un recorrido entero de principio a fin, entre pantallas y canales. Se hace con test de usuarios en UX y con pruebas end-to-end automatizadas en desarrollo.
Es un tipo de test de usabilidad cuyas tareas abarcan el recorrido completo, incluidos emails, esperas y cambios de canal, en lugar de una pantalla concreta.
Es un método de investigación en el que los participantes registran durante días o semanas lo que hacen, piensan y sienten en su contexto. Sirve para recorridos largos que no caben en una sesión.
Es una prueba automatizada que abre un navegador y recorre un flujo completo como un usuario, por ejemplo buscar, añadir al carrito y pagar, para detectar si un cambio de código lo ha roto.
Para detectar problemas, unos cinco por perfil y ronda. Para un diary study, entre 5 y 12 en proyectos pequeños, según Nielsen Norman Group.
Los críticos: los que generan más ingresos, más contactos al soporte o más abandono, como el pago, el alta o la reserva.
Las más extendidas son Playwright, Cypress y Selenium, que controlan un navegador real. En producción se complementan con monitores sintéticos que repiten el recorrido cada pocos minutos.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗