(Des)información 1

En un curso al que asistí una vez me indicaron que se debía asignar un 50% del tiempo de programación a la etapa de pruebas, en su momento me pareció bastante razonable, incluso hasta llegué a pensar que ese estimado de tiempo era el resultado de la amplia experiencia que en el área tenía el instructor. Nada más lejos de la realidad.

Quiero aclarar que cuando menciono “50% del tiempo de programación” no me refiero a la mitad del tiempo, lo que quiero decir es que si a la etapa de programación se le asignan 100 horas, a pruebas se le asignan 50, y estas se ven recortadas, o eliminadas, en función a la proximidad de la fecha de liberación del producto.

Pero la mala información no quedó allí, también se nos dijo que si el tiempo asignado era excesivo, es decir, se terminaban las pruebas y aun teníamos tiempo disponible (cosa que no llegó a suceder) se deberían reproducir las pruebas desde el principio. Como si la repetición de las mismas pruebas, con los mismos datos, en el mismo ambiente y sobre el mismo producto pudiera hacer que aparecieran nuevas incidencias de la nada.

Toda esa operación estaba en función de darle una mayor importancia a la parte de desarrollo, considerando que los recursos asignados al área de pruebas eran un mal necesario y que las pruebas constituían una parte complementaria del desarrollo. Me gustaría decir que esa mentalidad ha cambiado; pero no es así.

En muchas empresas que se dedican al desarrollo de aplicaciones a la medida aun se sigue considerando lo referente a pruebas de software como algo que se debe hacer porque está de moda, no porque realmente vean un beneficio en ello; llegando incluso a hacer estimaciones de los recursos que se necesitarán para corregir las incidencias que el cliente reportará. Son incapaces de poder ver que independiente del tiempo que se puede ahorrar al detectar en etapas tempranas del desarrollo los problemas, la imagen de un producto sin defectos (o con pocos) es extremadamente beneficiosa para la empresa.

La de hoy

Yo siempre he sido un ferviente creyente de que la mejor de las memorias no sustituye a la más pálida de las tintas, pero el ser un creyente no evita que mi autosuficiencia en ocasiones me haga creer que es algo tan trivial que no merece dedicarle tiempo adicional y cometa el mismo error nuevamente. ¿A que se debe el comentario anterior?, acabo de bajar la última versión de JMeter y por una extraña razón no se ejecutaba, después de dedicarle mucho más tiempo del que sería deseable me dí cuenta que no había arreglado el archivo por lotes que carga la herramienta (jmeter.bat).

Dado que esa herramienta normalmente se encuentra en mi USB para poder ejecutarla en diferentes equipos, y que la configuración de cada equipo no necesariamente es la misma, en el archivo que la carga verifico que la variable java_home exista, y en caso de no existir la creo con la instrucción:

if ".%JAVA_HOME%"=="." set JAVA_HOME=.\Java\jdk

(Java\jdk es donde instalo siempre la última versión de JVM)

Evidentemente, si la variable java_home no existe, lo más probable es que tampoco se encuentre en la ruta del sistema, pero eso se soluciona fácilmente:

set PATH=%JAVA_HOME%\bin;%PATH%

Quizá para la mayoría esto sea de principiantes, pero yo soy un principiante y espero que este blog sirva como auxiliar a otro principiante en el futuro.

(Si, mi ego es de ese tamaño.)

Defectos y clientes 1

Cita: Un defecto solo puede ser encontrado en un elemento que contiene ese defecto.

Parece extremadamente obvio, y por lo mismo solemos pasarlo por alto. Como probadores solemos elaborar baterías amplias de pruebas y las ejecutamos antes de liberar el producto. Estas pruebas normalmente las ejecutamos en una configuración previamente establecida para hacerlo. Muchas organizaciones gastan cada año sumas importantes para crear la infraestructura necesaria para llevar a cabo esas pruebas. Incluso se establecen unos criterios que se deben cumplir que sobrepasan los estándares esperados por el cliente. Sin embargo, generalmente sucede que cuando el producto se libera el cliente con bastante rapidez empieza a reportar incidencias. ¿Qué fue lo que pasó? ¿Qué ocurrió con todo el esfuerzo invertido, todas las horas-hombres gastadas y el dinero empleado en establecer el ambiente de pruebas? ¿Porque las pruebas hechas “en casa” fueron incapaces de detectar algo que nuestros clientes encuentran con tanta facilidad? ¿Qué es lo que se está haciendo mal?

Esto se explica con la cita, es decir, un defecto sólo puede ser descubierto en un sistema o entorno que contiene el defecto. Una incidencia que se muestra en el entorno del cliente no puede mostrarse en el entorno “esterilizado” de pruebas del que disponemos. Nuestro ambiente de pruebas está creado con el control y configuración de la visión (nuestra visión) de cómo debe utilizarse el producto, o por lo menos de cómo es probable que se utilice.

Dentro de las limitaciones y restricciones que hemos definido ejecutamos nuestra más completa batería de pruebas y nos sentimos confiados cuando se ejecutan esas pruebas y no surge ninguna incidencia, el área de atención al cliente se encuentra satisfecha por esa carencia de inconvenientes. Sin embargo, el medio ambiente de un cliente no sufre de las mismas condiciones, restricciones y limitantes y por lo mismo no resulta difícil encontrar un defecto. Los defectos pueden no ser necesariamente del propio producto. Podría surgir de la interacción del producto con su entorno operativo, las dependencias, uso, etc.

Eso quiere decir que si no somos capaces de reproducir con suficiente detalle el entorno del cliente y los escenarios probables de uso en el mundo real una vez que el producto es liberado, probablemente seguiremos viendo una tendencia cada vez mayor de clientes informando problemas.

Definición de calidad

Una definición bastante aceptable sobre calidad, que no recuerdo en este momento donde leí, dice:

La calidad es el valor de importancia asignado a un elemento por ciertas personas.

No es tan compleja como muchas otras definiciones, es fácil de explicar y por lo mismo sencillo de comprender.  Sin embargo también es ampliamente discutida en otros blogs (como este), por lo que creo que expondré mi punto de vista aquí en lugar de tratar de comprimir la idea en los 140 caracteres de Twitter.

Yo creo que faltan algunos conceptos que deberían estar implícitos, uno de ellos es el contexto y otro es quien lo valora.

El valor asignado a un elemento está en función directa con el contexto en que se lleva a cabo esa valoración.  Se necesita un contexto para poder asignar realmente el valor. Y mientras se va modelando el contexto hacemos muchos supuestos en torno al mismo que quizá no se lleguen a cumplir.  Cuando algo altera ese contexto el valor asignado a ese elemento también se puede ver alterado.

El segundo criterio a ser tomado en cuenta es el quien.  Actualmente es necesario poder asignar también un valor a la opinión de las personas.  Estamos inmersos en un mundo donde los conocimientos fluyen a tal velocidad que es imposible poder verificar/valorar toda esa información, y el contar con comunicaciones casi instantáneas nos obliga a crear algunos criterios de aceptación.

Algunos incluyen el factor tiempo como una condición para medir la calidad del elemento, yo creo que el tiempo es un factor (un importante factor en realidad) a tener en cuenta. Pero el tiempo, al fin y al cabo, es parte del contexto.

Es necesario poder asignar ese valor a algo, actualmente incluso podemos asignar ese valor a algo intangible, ya sea una pieza de software o una opinión, el que en realidad no debe formar parte de la definición.

Mi propuesta de definición de calidad es:

La calidad es el valor contextual de importancia asignado a un elemento por determinadas personas.

Esta definición va a cambiar, es seguro, pero por el momento considero que funciona.  Aguardo ideas adicionales...

En el camino

En ciencia la flexibilidad es importante, aferrarse a una idea es solo una trampa del pensamiento egoísta que nos lleva al error. En ciencia se emplean muchas herramientas para resolver muchos problemas.

En matemáticas. Se emplean varios puntos de vista para demostrar un teorema (idea/afirmación). Pues es una forma de dar validez al teorema y a la teoría. Por ejemplo, El teorema de Pitagóricas (sobre la relación de los tres lados de un triángulo recto) se puede demostrar con pura álgebra de secundaria, o con recortes de papel de escuela primaria, entre otras caminos.

Tener un herramienta significa explorarla, usarla lo más posible, lo mejor. Pero tal vez esa herramienta no sea la adecuada para el experimento o la aplicación que deseamos. Personalmente, en los próximos meses exploraré algunas herramientas, iré poniendo algunas observaciones aquí. Solo sabré si es la ruta correcta cuando recorra €un buen tramo del camino, mientras tanto, estaré haciendo camino.

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.