El testeo para la mejora de la experiencia de usuario

Durante el último año y medio he estado utilizando herramientas desarrolladas en el proyecto Selenium. Estas herramientas de software abierto para el testeo de interficies de aplicaciones web se ha vuelto casi imprescindible para mí en el momento de revisar la interacción con el usuario.

Aunque existen muchos tipos de pruebas de aplicaciones, considero que las pruebas de UI son especialmente críticas: en último término determinan la calidad percibida, con independencia de la calidad interna del producto.

Mi utilización de Selenium (en especial Selenium RC) se ha limitado a su objetivo original, pero durante las horas de vuelo que transcurren durante las pruebas surgen ideas sobre el papel del testeo en el desarrollo de aplicaciones web.  Sólo con ver la ejecución automática del testeo y adoptar el sombrero del usuario final, se pueden llegar a contar las mejoras por docenas.

La realidad del equipo de desarrollo

Aunque la tecnología web precisa una mirada interdisciplinar, cada equipo enfoca las soluciones según sus conocimientos.   Mi experiencia se basa en proyectos más centrados en la parte técnica, por lo que el desarrollo (mucha programación y menos diseño) absorben mucho tiempo.  Si el tiempo estimado se agota, la inercia lleva a sacarlo de las fases finales.

He comprobado también por la experiencia que el tiempo de testeo y documentación se acaban recuperando, quizá fuera de plazo, y a lo peor con la decepción del cliente.  Porque al cliente le importa poco la implantación del modelo de datos, e incluso las luces y colores.  Si no funciona como la entiende, la aplicación está rota.

Sé que testear la interacción y documentar para el usuario final son tareas percibidas como tediosas, ya que suponen un cambio de sombrero para cualquier desarrollador.  Es el equivalente informático a corregir nuestro propio dictado.

¿Argumentos habituales? Sobre el testeo de UI se dice que ya es suficiente con las pruebas que se realizan mientras se desarrolla (falso); de la documentación de usuario... quizá ni hablemos, porque con el axioma Mac segun el cual un programa se explica por sí solo (error grave), la excusa está servida.  Claro, porque todas las empresas de desarrollo han de ser como Apple, ¿no?

Ponerse unas horas en la situación del usuario después de semanas de verlo todo desde dentro es mucho más complejo de lo que pueda parecer: un programador conoce los datos y la estructura de la aplicación. Ve todas las opciones aunque sean invisibles (porque las ha puesto él), y sabe que ante un error puede resolverlo rápidamente (no como el usuario final).  Su percepción de las consecuencias no está alineada con la del usuario final, y esto le resta capacidad crítica.

Pero si además se le plantea que redacte el manual de usuario, utilizará terminología técnica (porque se han familiarizado con ella).  Y yo, que conste, lo entiendo.  No sólo porque desarrolle, sino porque cuando lo veo desde el otro lado sé que es complicado. Por no decir lo poco que motiva explicar la aplicación por segunda vez (la primera vez lo ha explicado a una máquina) y en términos distintos.

Tendiendo puentes

Es por eso que cada vez veo con más interés el testeo como el puente que vincula la visión del cliente y el desarrollo.  El testeo puede establecer guías concretas sobre el que un intermediario puede hablar con el cliente.  Esa concreción por sí misma evita los malentendidos habituales. Y aporta mejoras en concreción.

Con la información recopilada en esas reuniones puede desarrollar casos de uso (o escenarios de usuario),  describir la prueba, estructurar las fases y establecer los requerimientos.

Con esto, puede pactar con el equipo de desarrollo las tareas a realizar, desarrollar la prueba, y redactar la documentación de usuario bajo un guión unificado.  Y lo que verificará que la tarea está hecha es la superación de las pruebas.

Espero tener tiempo para comentar en otros artículos el detalle de estas relaciones, lo que permiten y lo que pueden complementarse con otros métodos.