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.

¿Calidad = Cantidad + Aprendizaje?

Me encontré con esta maravillosa historia de lo beneficioso que es fracasar temprano, aprender y no darse por vencido. Es sobre un experimento para calificar a los alumnos. Esto fue lo que sucedió:

El maestro de cerámica anunció que dividiría a su clase en dos grupos. Todos los que estaban del lado izquierdo del estudio serían calificados según la cantidad de trabajo que produjeran y los del lado derecho serían calificados solo por la calidad de su trabajo.
Su procedimiento era simple: el último día de clases computaría el peso del trabajo del grupo de la "cantidad": 50 libras de vasijas se calificarían como A, 40 libras como B y así sucesivamente. Aquellos que serían calificados por la "calidad" solo necesitaban producir una vasija para tener una A, pero debía ser una vasija perfecta.
Cuando llegó el momento de la calificación ocurrió un hecho curioso: ¡Los trabajos de mejor calidad fueron todos producidos por el grupo que había sido calificado por la cantidad!
Parece que mientras el grupo de la "cantidad" producía vasijas a lo loco y aprendía de sus errores, el grupo de la "calidad" había dedicado su tiempo a teorizar sobre la perfección y, finalmente, para dar cuenta de sus esfuerzos, no tenían más que grandiosas teorías y un montón de barro muerto.

La única forma de avanzar es adquiriendo experiencia. Para ello se debe tener tesón aun en el fracaso. Esa es la importancia de la experimentación: aprender sistemáticamente.

¿Se puede aplicar esta experiencia a las pruebas de software?. Aun acostumbro probar todo el software al que tengo acceso, experimentar constantemente con nuevas herramientas, ¿Es esto una buena práctica?. Creo que solo el tiempo va a responder esta pregunta.

Software Libre

Según GNU (http://www.gnu.org/philosophy/free-sw.es.html) "software libre" no es lo mismo que "software gratis" y se refiere a:

• La libertad de ejecutar el programa, para cualquier propósito (libertad 0). Significa la libertad para cualquier tipo de persona u organización de usarlo en cualquier tipo de sistema de computación, para cualquier tipo de trabajo y propósito, sin estar obligado a comunicarlo a su programador, o alguna otra entidad específica. En esta libertad, el propósito de los usuarios es lo que importa, no el propósito de los programadores. Como el usuario es libre de ejecutar un programa para sus propósitos; y si lo distribuye a otra persona, también es libre para ejecutarlo para sus propósitos, pero usted no tiene derecho a imponerle sus propios propósitos.
• La libertad de estudiar cómo trabaja el programa, y cambiarlo para que haga lo que usted quiera (libertad 1). El acceso al código fuente es una condición necesaria para ello. Incluye la libertad de usar su versión modificada en lugar de la original. Si el programa se entrega con un producto diseñado para ejecutar versiones modificadas de terceros, pero rechaza ejecutar las suyas, una práctica conocida como «tivoization» o «arranque seguro» (mediante listas negras); esta libertad se convierte más en una ficción teórica que en una libertad práctica. Esto no es suficiente. En otras palabras, estos binarios no son software libre, incluso si se compilaron desde un código fuente que es libre.
• La libertad de redistribuir copias para que pueda ayudar al prójimo (libertad 2). Debe incluir las formas binarias o ejecutables del programa, así como el código fuente; tanto para las versiones modificadas como para las no lo están. (Distribuir programas en forma de ejecutables es necesario para que los sistemas operativos libres se puedan instalar fácilmente). Resulta aceptable si no existe un modo de producir una formato binario o ejecutable para un programa específico, dado que algunos lenguajes no incorporan esa característica, pero debe tener la libertad de redistribuir dichos formatos si encontrara o programara una forma de hacerlo.
• La libertad de distribuir copias de sus versiones modificadas a terceros (la 3ª libertad). Si lo hace, puede dar a toda la comunidad una oportunidad de beneficiarse de sus cambios. El acceso al código fuente es una condición necesaria para ello. Incluye la libertad para distribuir sus propias versiones modificadas como software libre. Una licencia de software libre debe permitir otras maneras de distribuirlas, en otras palabras, cualquiera que redistribuye el software, con o sin cambios, debe dar la libertad de copiarlo y modificarlo.

Un programa es software libre si los usuarios tienen todas esas libertades. Entonces, debería ser libre de redistribuir copias, tanto con o sin modificaciones, ya sea gratis o cobrando una tarifa por distribución, a cualquiera en cualquier parte. El ser libre de hacer estas cosas significa, entre otras cosas, que no tiene que pedir o pagar el permiso. También debería tener la libertad de hacer modificaciones y usarlas en privado, en su propio trabajo u obra, sin siquiera mencionar que existen. Si publica sus cambios, no debería estar obligado a notificarlo a alguien en particular, o de alguna forma en particular.

Para que la 1ª y 3ª libertad, para realizar cambios y publicar versiones mejoradas, tengan sentido; debe tener acceso al código fuente del programa. Por consiguiente, el acceso al código fuente es una condición necesaria para el software libre. El «código fuente» complicado o dificil de entender no es código fuente real, y no cuenta como código fuente.