(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.