Las pruebas de UX y UI plantean dos preguntas distintas
| Pruebas de UI | ¿El botón guarda el registro? ¿La lista se actualiza? Verificable de forma objetiva. Automatizable. Debería ejecutarse con cada cambio. |
| Investigación de UX | ¿Pudo el usuario encontrar el botón? ¿Entendió el resultado? Requiere personas. No se puede automatizar y no se debería fingir. |
Un producto puede pasar todas las pruebas de UI y ser un suplicio de usar. También puede encantar en una sesión de usabilidad y perder datos en producción. Ninguna de las dos actividades sustituye a la otra.
Qué puede asumir la automatización con honestidad
La corrección funcional de cada flujo. Toda la primera columna.
Comprobaciones mecánicas de accesibilidad. Etiquetas ausentes, contraste, orden de foco. Valor real, y no toda la accesibilidad.
Comprobaciones de consistencia. Si la misma acción se comporta igual en tres lugares distintos, que es un problema de UX con una forma comprobable.
Qué no puede
Si el flujo tenía sentido. Si el mensaje de error ayudó. Si alguien se rindió. Esto necesita personas, y la forma útil de verlo es que la automatización recupera el tiempo para hacerlo al eliminar la ronda manual de regresión.
El solapamiento que sí vale la pena automatizar
Hay una franja estrecha donde ambas se encuentran de verdad, y es la automatización más desaprovechada al alcance de la mayoría de los equipos.
La consistencia es una propiedad de UX con una forma comprobable. ¿La misma acción produce la misma confirmación en los tres lugares donde aparece? ¿Un error se ve como un error en todas partes, o hay una pantalla que falla en silencio? ¿La acción principal está en la misma posición en cada modal? Nada de esto exige juzgar si el diseño es bueno, y todo ello es algo que los usuarios perciben como descuido.
Además son invisibles para quienes construyeron cada pantalla, porque cada una es consistente consigo misma. Comprobarlas de una pantalla a otra es barato y detecta un tipo de queja que ni las pruebas funcionales ni la investigación de usabilidad están buscando.
La trampa
Los equipos recortan la investigación de UX porque la cobertura de pruebas de UI es alta. El razonamiento parece sólido y es un error de categoría: la cobertura dice que el producto hace aquello para lo que se construyó, y no dice nada sobre si era lo correcto para construir.
El arreglo más sano es que la automatización se encargue de la comprobación repetitiva y que las horas que libera vayan a la investigación que solo pueden hacer las personas.
Nada de esto necesita una terminal. Crea un proyecto en el panel de TestSprite, describe la comprobación en lenguaje natural y apúntalo a tu aplicación. Los desarrolladores de tu equipo pueden hacer lo mismo desde la línea de comandos si lo prefieren; eso está en el repositorio del CLI.
El disparador importa más que el mecanismo. Apuntarlo a tu evento de despliegue significa que cada cambio se comprueba sin que nadie tenga que decidirlo; la GitHub App lo hace desde el panel, y un paso de GitHub Actions lo hace desde dentro de tu flujo de trabajo.
Qué automatiza TestSprite y qué te deja a ti
Automatiza toda la columna funcional: si el flujo funciona, si el estado se traslada correctamente entre pasos, si lo que se le dice al usuario coincide con lo que realmente pasó. Los casos se generan a partir de tu producto y se refinan en lenguaje natural, y se ejecutan con cada cambio.
También cubre las comprobaciones de consistencia que caen en ese solapamiento, como si la misma acción se comporta igual en todos los lugares donde aparece, que es una queja de UX con una forma comprobable.
Lo que deliberadamente te deja a ti es la investigación. El valor de eliminar la ronda manual de regresión son las horas que devuelve, y el argumento de esta página es que esas horas deberían ir a hablar con los usuarios en lugar de volver al backlog.
¿Puede la IA hacer pruebas de usabilidad?
Puede simular recorridos por una interfaz, lo que sirve para la cobertura. No puede decirte si una persona real se confundiría, porque eso es un hecho sobre las personas.
¿La accesibilidad es UX o UI?
Ambas. Las partes mecánicas se automatizan bien; las partes de experiencia necesitan personas, idealmente personas que usen tecnología de asistencia.
¿Con qué frecuencia deberíamos hacer investigación de UX?
Cuando algo cambia de forma sustancial o cuando las métricas dicen que la gente está abandonando. No con una cadencia fija por sí misma.
¿Quién se encarga de cada una?
Las pruebas de UI suelen recaer en ingeniería. La investigación de UX recae en diseño o producto. Los problemas aparecen cuando se da por hecho que un solo equipo cubre ambas.
¿Una buena UX reduce la necesidad de pruebas de UI?
No. Un flujo bien diseñado se puede romper igualmente con un cambio de código, y eso es precisamente lo que detectan las pruebas de UI.
Una pregunta si funciona; la otra, si vale la pena usarlo.
Las pruebas de UX y UI responden preguntas distintas. Automatiza la mitad funcional, incluida la accesibilidad mecánica, y dedica el tiempo que eso libera a la investigación que requiere personas. Una cobertura alta no es razón para dejar de hablar con los usuarios.