If you think good design is expensive, you should look at the cost of bad design.
Dr. Ralf Speth, CEO, Jaguar Land Rover
En la última década, la experiencia de usuario se ha convertido en el verdadero factor diferenciador entre aplicaciones buenas y extraordinarias.
El aspecto técnico de construir software es, en cierta medida, un problema resuelto. Las verdaderas posibilidades de éxito abrumador con productos de software residen en la experiencia de usuario. La próxima aplicación revolucionaria tendrá una interfaz instantáneamente utilizable. Esto ha conducido a un enfoque de desarrollo de producto basado en la investigación y centrado en UX.
Los resultados de este enfoque hablan por sí solos.
Por ejemplo, cada dólar invertido en UX genera un retorno de $100, según un informe de Forrester Research. Además, durante un periodo de 10 años, un estudio muestra que el desempeño financiero de las empresas impulsadas por el diseño supera al S&P en un 219%.
Existe también la legendaria historia de cómo simplemente cambiar el texto de un botón añadió $300 millones en ventas a una empresa de e-commerce en tan solo un año.
Sin embargo, a pesar de toda esta expectación y revuelo, por cada aplicación con una gran experiencia de usuario, existen varias que carecen o carecen gravemente de ella. Las terribles son fáciles de detectar, hacen que quieras golpear la pantalla de tu portátil o lanzar tu móvil por la ventana. Darwin se encarga de esas aplicaciones.
El verdadero reto son las aplicaciones con una UX "pasable". Son de esas que resultan ser la proverbial “astilla en la mente”: experiencias que, por más que lo intentes, no logras entender por qué no te agradan.

Puedo oírte decir, “Ya sabemos todo esto; ¡estoy leyendo The QA Lead, por el amor de Dios! Entonces, ¿qué tiene que ver esto conmigo?” Ahora voy a eso.
La importancia de la UX
En mis primeros días gestionando equipos de ingeniería, trabajábamos en un gran proyecto de solución de software para uno de nuestros clientes. Esto formaba parte de una estrategia general de transformación digital que se estaba implementando para ese cliente. Era un equipo típico de ingeniería compuesto principalmente por desarrolladores de software y profesionales de QA que utilizaban Scrum con sprints de 2 semanas.
Había un pequeño equipo de UX pero, en su mayoría, se compartía entre varios proyectos. Normalmente, los especialistas en UX asistían a las reuniones diarias durante las primeras fases del proyecto, pero una vez que el cliente aprobaba el diseño visual, entregaban todas las plantillas del diseño y los flujos, y luego se marchaban a trabajar en otros proyectos.
Durante la primera demo del sprint, el cliente parecía estar principalmente preocupado porque el diseño visual y la interfaz de usuario no coincidían exactamente con las plantillas de diseño. También había una brecha entre la funcionalidad propuesta y lo que se implementó realmente.
Ojo, la brecha no era grande pero, no importaba cuánto intentáramos tranquilizar al cliente asegurándole que el aspecto de UX se perfeccionaría en uno de los siguientes sprints, su lenguaje corporal indicaba claramente que no estaba satisfecho.
Por suerte, la responsable de QA de nuestro equipo intervino, diciendo que esto era una anomalía y que no volvería a ocurrir. Y después hizo algo increíble. Permíteme resumirlo aquí:
- Ella misma decidió repasar sus conocimientos de UX mediante lecturas intensivas.
- Luego realizó una revisión heurística básica de UX para la funcionalidad entregada, habló con el equipo de UX y pidió su ayuda cuando fue necesario.
- Creó nuevas tareas en JIRA para corregir la diferencia entre lo prometido y lo entregado—desde la perspectiva de UX.
- Agendó una llamada con nuestro jefe de UX y consiguió su aprobación para garantizar que se instituyera un nuevo proceso en el que los aspectos visuales de la aplicación se resolvieran en cada sprint y no solo al final.
- Finalmente, también consiguió que nuestro equipo de QA aprendiera fundamentos de UX para que pudieran detectar problemas evidentes y ayudar al equipo a solucionarlos desde el principio.
¿La guinda del pastel? Durante la demostración del siguiente sprint, el product owner/cliente estaba feliz y, después de unos meses, ¡nuestra responsable de QA fue ascendida a QA Manager! 😉
Perspectivas románticas vs. clásicas de la realidad
Todo este episodio me hizo reflexionar sobre la enorme diferencia entre cómo vemos una aplicación en ingeniería y cómo la perciben los clientes y usuarios. Robert Pirsig, en su libro fundamental Zen y el arte del mantenimiento de la motocicleta, habla sobre dos perspectivas de la realidad: la clásica y la romántica.
Según Pirsig, quienes tienen una perspectiva dominante romántica ven las cosas y las juzgan según cómo aparecen. Están principalmente interesados en cómo son las cosas y no les importa cómo funcionan, es decir, el orden subyacente. Esta es la mitad artística de la división arte/ciencia.
Por otro lado, nosotros, los ingenieros y científicos, adoptamos la visión clásica donde la belleza reside en los mecanismos que subyacen a la forma exterior. Los ingenieros pueden ver belleza en el código python o bajo el capó de un coche, que a quienes tienen una perspectiva romántica les parece feo.


Como todo, obviamente esto no es una clasificación binaria, sino un continuo, y la mayoría de nosotros preferimos una perspectiva de manera dominante.
Existen algunas implicaciones interesantes de esta manera de clasificar el mundo:
1. La perspectiva dominante de la mayoría de las personas por defecto es clásica o romántica, pero no ambas.
2. Las personas —piensa en clientes, internos o externos— con la perspectiva romántica superan ampliamente en número a aquellos con la perspectiva clásica. ¡Si alguna vez tuviste que hacer de soporte técnico para la familia o amigos, sabes de lo que hablo!

3. Muy pocos pueden cambiar de modo y, aún para quienes lo logran, es una actividad que implica esfuerzo.
4. Realidad = clásico + romántico. No son mutuamente excluyentes. Ambos son aspectos esenciales de la totalidad. La belleza es funcional. La función puede ser bella.
Tomemos como ejemplo las flores. Tienen patrones tan hermosos que parecen no tener ninguna función. Sin embargo, la belleza que vemos en las flores tiene una estructura subyacente basada en las matemáticas: la secuencia de Fibonacci gobierna la estructura y los patrones que observamos en las flores. En la naturaleza, la estructura y la belleza etérea van de la mano.
Y no se trata solo de belleza. La disposición de las semillas en un girasol sigue la secuencia de Fibonacci y la proporción áurea para encajar el mayor número posible de semillas en la flor. Los mismos principios se aplican a la ingeniería y la experiencia de usuario.

Esto, finalmente, nos lleva al meollo de este artículo: los profesionales de ingeniería de calidad están en una posición ideal para aprovechar ambas perspectivas, que aparentemente compiten entre sí.
El papel del aseguramiento de la calidad del software en la experiencia de usuario / usabilidad
Como profesional de pruebas, tienes mucha más experiencia con interfaces que el desarrollador o usuario promedio.
¡Has probado de manera rigurosa y repetida (hasta el hartazgo!) tantas aplicaciones que probablemente has alcanzado el nivel de pensamiento de orden superior o 4D en lo que respecta a UX, como el proverbial gran maestro de ajedrez que piensa en posiciones en lugar de, quien te escribe, que lucha solo para decidir qué pieza mover a continuación! ;-)
Por eso, a pesar del gran avance hacia la automatización—una tendencia excelente, sin duda—hay algo que decir sobre cierto nivel de pruebas manuales. Al fin y al cabo, si las personas van a usar una aplicación, tiene sentido tener una perspectiva humana en las pruebas.
Cómo realizar una revisión de UX / usabilidad como ingeniero de pruebas
Si el aseguramiento de la calidad necesita tener en cuenta la experiencia de usuario, debe comenzar junto con la etapa de diseño, es decir, al inicio del ciclo de vida. Estos son los pasos que puedes seguir para incluir la revisión de UX en tus pruebas y ¡ser un profesional QA polímata!
Heurísticas de usabilidad para el diseño de interfaces de usuario
Familiarízate con las 10 principios generales para el diseño de interacción de Jakob Nielsen. Este conjunto de pautas es un punto de referencia confiable para cualquier revisión de usabilidad. Ten en cuenta estos principios en tus conversaciones con el equipo de UX y en tu plan de pruebas. También puedes consultar alguno de los muchos cursos básicos sobre usabilidad y diseño UX.
Aprende los principios de accesibilidad
Puede que hayas realizado pruebas de accesibilidad como parte de tu plan de pruebas en el pasado, pero comprender los principios detrás de la accesibilidad—perceptible, operable, comprensible, robusto—te dará la capacidad de ver lo que otros podrían pasar por alto.
El equipo de UX es tu nuevo lugar de reunión
No te mantengas al margen: conoce al equipo de UX del proyecto. Colabora con ellos. Comparte tu plan de pruebas con ellos y recibe retroalimentación sobre lo que puedes incluir desde el punto de vista de la experiencia de usuario.
Los beneficios de esta interacción son mutuos, ya que tu plan de pruebas brindará al equipo de diseño una visión sobre la viabilidad de las funcionalidades de diseño que desean proponer. Como líder de QA, tu interacción con el equipo de UX debe ser tan cercana como la que tienes con los desarrolladores.
Incluye analítica en tu plan de pruebas
La analítica de usuarios del producto que estás probando es una mina de oro de información para los testers. Los datos analíticos pueden ayudarte a identificar áreas de riesgo y conductas de los usuarios. Esto, a su vez, puede ayudarte a identificar y priorizar correcciones lo antes posible en el ciclo de vida del producto.
Anticípate todo lo que puedas
El producto que estás probando es como un bebé. Debes asegurarte de que reciba la ayuda necesaria desde el mismo momento de la concepción del producto. Ve hasta el principio.
Antes del desarrollo
Realiza pruebas en la etapa de diseño tan pronto como haya un prototipo listo. Utiliza tu experiencia con aplicaciones y tu conocimiento de los principios de usabilidad y directrices de accesibilidad para comprobar si es necesario realizar algún cambio ANTES de que el producto pase a la etapa de desarrollo.
Si el equipo de QA aún no es parte de la fase de diseño, haz que suceda si es posible.
Pruebas manuales enfocadas
Recorre toda la experiencia de uso del producto de principio a fin como parte de las pruebas manuales. Concéntrate en hacer las preguntas correctas, pensar como usuario y como ingeniero de QA.
Comienza tomando distancia y observando el producto desde una perspectiva más amplia. ¿Disfrutas la experiencia?
Luego observa más de cerca. ¿Es fácil de usar? ¿Los flujos son obvios e intuitivos? ¿Son tediosos y lentos? ¿Hay solapamientos o duplicidad de acciones que puedan resultar molestas para el usuario? ¿El diseño es usable en diferentes tamaños de pantalla?
Por último
El futuro del trabajo pertenece a quienes tienen varios conjuntos de habilidades complementarias que son casi imposibles de reemplazar por máquinas (pero revisa mi artículo sobre IA en automatización de pruebas para ver de lo que ya son capaces).
Convertirte en un polímata de QA con habilidades en UX podría ser una excelente manera de aprovechar tus capacidades y experiencia naturales, aportar mucho más valor sin demasiados esfuerzos o sin alejarte demasiado del área principal.
¿Te entusiasma esta idea? ¿O piensas que la experiencia de usuario solo es tangencial a este campo? Déjame tu opinión en los comentarios abajo.
Si estás listo para aprender más, aquí tienes un pódcast que puedes leer/escuchar: CÓMO EL SOFTWARE DE CÓDIGO ABIERTO SIMPLIFICA LA INTEGRACIÓN EN LA INGENIERÍA DE AUTOMATIZACIÓN (CON JAMES WALKER Y SANJAY KUMAR)
