Emociones y sentimientos en las pruebas de software.

Los que realizamos las pruebas de software generalmente leemos los requerimientos para darnos una idea de como debe comportarse el producto. Estos requisitos cubren a menudo los funcionales y algunos no funcionales, incluyendo desempeño, seguridad, algunos elementos de usabilidad, etc. Las pruebas se planean para obtener los resultados esperados y que se ajustan a los requerimientos del producto. Hay una línea clara de los requisitos a probar. Hasta ahora todo va bien.

Como testers, mientras realizamos las pruebas, existen varias instancias en que nos sentimos irritados o frustrados con aspectos del software que estamos probando. Podemos experimentar una gama de emociones mientras realizamos las pruebas. En ese momento ¿Que haces? Escuchas tus sentimientos o sigues con el plan de pruebas centrándote simplemente en el comportamiento previsto como se especifica en los casos de prueba que se están probando. Si la prueba muestra los resultados esperados, pero continuamos experimentando un conflicto de emociones ¿Que harías?

Como tester ¿Se debe de dar importancia a los sentimientos y emociones que experimentamos durante la prueba o dejar esas "pequeños" aspectos del otro lado de la puerta antes de iniciar un plan de pruebas? ¿Las pruebas se basan solo en la lógica y en los requerimientos anotados? ¿Tiene algún valor el prestar oídos a esa "voz interior" y tus sentimientos están tratando de decirte mientras realizas a prueba?

En mi opinión, los testers deben de hacer caso de esas sensaciones durante la prueba. Algunas pruebas requieren que apenas se haga caso de lo escrito y no limitarnos solo al comportamiento esperado. Las buenas noticias son que en la mayoría de las pruebas esas sensaciones son una ayuda agregada al esfuerzo de la prueba. En esta coyuntura a mí me ha ayudado recordar tres conceptos básicos:

1. Definición de incidencia: Una "incidencia" es algo que "incidentalmente" a alguien le importa. Ese alguien pueden ser usuarios finales o alguien bastante significativo para tener un impacto significativo en la organización.
2. No todos los requerimientos del software están escritos o indicados. Hay un número significativo de requerimientos que quedan por especificar, detallar, o son asumidos o implícitos.
3. En muchos casos el cliente puede no saber realmente lo que necesitan en un principio, esto es especialmente verdad con lo referente a los requerimientos de usabilidad.

Si las emociones están diciéndote algo, escúchalas. Si sientes frustración mientras usas el software, o sientes confusión con interfaces no-intuitivas, o sientes cansancio de esperar una respuesta del software o le proceso de determinada información, o estás a disgusto con el flujo de trabajo o cualquier otro aspecto del software y si no están explícitamente indicados en los requerimientos, no los ignores solo porque no tu sistema escrito no haga referencia de estas experiencias. Si algo en el software no te convence, es probable que a los usuarios del software tampoco los convenza y eso puede traer implicaciones más serias.

Algo en el software que te frustra o irrita bien puede irritar o frustrar al usuario final. En interés de hacer el producto de uso más sencillo e intuitivo, permite que tus sentimientos afloren a lo largo de a prueba. Reporta cualquier incidencia y/o mejora que te gustaría.

La otra cosa a recordar es que las incidencias levantadas en lo que sientes respecto al software no siempre serán bien acogidas por tus contrapartes en el desarrollo (generalmente desarrolladores y analistas). Algunas incidencias serán aceptadas e incorporadas en la liberación actual si se juzga que podrían evitar significativamente inconvenientes, perdida de funcionalidad o de información para el usuario. Otras incidencias serán diferidas para una liberación posterior y otras solamente serán cerradas, como si nunca hubieran sido levantadas.

Si crees en verdad que una incidencia es válida y bastante severa (en función a la frecuencia en que ocurre o impacto del mismo) para merecer atención, se debe de tener una reunión con los desarrolladores o alguien capaz de tomar una decisión sobre el estado de la incidencia. Puede ser de gran ayuda si se tiene la posibilidad de realizar un comparativo de funcionalidad, comportamiento o interfase con uno similar. Si existe la oportunidad de realizar la comparación y puedes demostrar las carencias de tu producto, puedes hacer que tus recomendaciones sean incorporadas en la liberación actual. (Tener de tu lado a un representante del cliente puede agregar peso a tus sugerencias).

En última instancia, asume que algunas incidencias se irán sin atender. Sin embargo, la búsqueda para asegurarnos que los usuarios tengan la mejor experiencia posible cuando usan el producto de nuestra organización debe de continuar hacia ese extremo, mantener un ojo abierto sobre lo que los sentimientos y emociones nos indican mientras interactuamos a lo largo de la prueba de software.

Una gran pieza de software no es el que cumple con todos los requerimientos funcionales, lo es uno que va más allá anticipando las necesidades del usuario e intentando evitar puntos conflictivos.