La fatiga del tester

Esta semana hemos subido a producción una nueva versión de una de las herramientas propietarias de Netquest que básicamente ha consistido en el rediseño casi total de una de las áreas tratadas por la aplicación. El proceso de testing ha sido largo, duro y difícil, y he sido presa de la fatiga por varios errores de apreciación realizados durante el proceso y que me juro que no voy a cometer nunca más:

  • Incorporación tardía al proyecto: esto es más grave como más tardía es la incorporación (obvio, no? ;-)) y como más grande es el proyecto. Testers y QAs del mundo, hay que encontrar tiempo para asistir a las reuniones de análisis de nuevos requerimientos o funcionalidades (o convocarlas nosotros mismos) para no “perder comba” de lo que sucede. El proceso de testing se pone en marcha más rápido y mejor si no nos coge “en frío” en lo que al contenido se refiere.
  • Desorganización en las pruebas manuales: no tengo los deberes hechos en lo que a organización y documentación de pruebas manuales se refiere. Aunque el rediseño de la herramienta implica casos de uso nuevos y eliminación de viejos (con el consiguiente efecto idéntico en los casos de test), aquellos casos que no han cambiado o que lo han hecho muy poco tienen que estar listos para ser ejecutados y la redacción de casos nuevos tiene que quedar almacenada para futuras situaciones similares. Es importante invertir el ciclo del trabajo y empezar a documentar el testing pensando en el reaprovechamiento futuro de los casos. Una buena herramienta de Test Case Management puede ser de vital importancia en este punto.
  • Falta de automatización en las funcionalidades básicas: de las dos herramientas desarrolladas por la empresa, en esta no tengo nada automatizado. Esto añade gran incertidumbre a aquellas situaciones donde el volumen de trabajo es difícil de asumir, ya que si falta tiempo para validar las nuevas funcionalidades, mejor ni pensar en las existentes. Como más funcionalidades básicas estén aseguradas por pruebas automáticas, más nos podremos concentrar en las funcionalidades nuevas y mejor dormiremos la noche antes de la subida a producción.
La fatiga del tester

Otros factores que contribuyen a que la fatiga haga mella en los testers pueden ser…

  • Procesos largos de pruebas: hacer pruebas es divertido, pero hacerlas bajo presión temporal y durante muchos días seguidos no lo es tanto. Me vuelvo a referir a los puntos anteriores: cuanto antes nos incorporemos al proceso, mejor organizados estemos y tengamos aseguradas las funcionalidades básicas mediante pruebas automáticas, más corta será la fase de (puramente) testing de un proyecto o una funcionalidad nueva.
  • Encontrar muchos errores o muy graves: encontrar errores es buena señal, porque serán corregidos antes de llegar a manos del usuario final; esto siempre es bueno. Lamentablemente, encontrar muchos errores alarga el final del proceso de testing (trasladar los errores a la herramienta de bugtracking correspondiente requiere tiempo e implica que además de validar las funcionalidades, habrá que validar que los errores se han arreglado). Además, encontrar errores graves puede ser algo frustrante, ya que estos errores acostumbran a ser bloqueantes, impidiendo proseguir con la validación de funcionalidades concretas, lo que añade mayor presión temporal a la situación.

Al final, la subida a producción fue bien y se hizo con seguridad, pero el proceso de testing ha requerido de demasiada “fuerza bruta” y las aplicaciones se han hecho demasiado grandes y complejas como para seguir con este planteamiento. Es hora de cambiar de planteamiento y subir el listón para entregar mejores versiones en menos tiempo y con el esfuerzo racionado y concentrado en aquellas áreas que lo requieran, sin perder fuelle en procesos intermedios.

RTH

RTH LogoSigo en busca y captura de una buena herramienta de management de test cases que implantar en mi departamento, para organizar todo el testing manual de las herramientas propietarias de Netquest. La siguiente en ser evaluada ha sido RTH (requirements and testing hub). Me decido a evaluarla por varias razones:

  1. En el número de Testing Experience de diciembre, había un artículo de Bruce Butler que hablaba maravillas de la misma.
  2. En el mismo número pero en otro artículo (este de Vinodh Velusamy) aparece como una de las 5 primeras herramientas de TC Management, según un debate-encuesta realizado en Linkedin al grupo de Software Testing & Quality Assurance.
  3. En el apartado de test management de opensourcetesting.org es la segunda herramienta de gestión de casos de test con mayor número de descargas (la primera es Testlink).

Según veo, hay dos proyectos en realidad, RTH y RTH Turbo, este segundo parece más potente según como lo describen pero al acceder al home del proyecto queda claro que es un proyecto inactivo, con una única versión de hace más de 3 años, nacido de la versión 1.2 de la aplicación original. No es muy alentadora esta situación (una herramienta de código abierto sin comunidad aparente y me figuro que sin soporte), por lo que sigo con la versión original del proyecto, a ver qué me ofrece.

RTH “a secas” tampoco presenta un mejor panorama, la última versión estable es de Abril del 2009, en el blog oficial de la herramienta hay un post de diciembre de ese mismo año avisando de la cercana inactividad del proyecto debido a que no hay desarrolladores en el equipo de gestión del mismo, por lo que no puede haber un roadmap definido al no tener certeza sobre cómo y cuándo se podrán hacer desarrollos; por otro lado, parece un proyecto bastante rocambolesco y descabezado, según su historia. Tampoco anima mucho a su adopción, pero vayamos a lo práctico…

El proyecto no goza de mucha documentación disponible, apenas un listado de funcionalidades y unas FAQ’s, no tiene un manual de usuario o de instalación como Testlink, pero se indica que requiere de PHP y MySQL. De lo que sí dispone es de una demo activa en http://rth.liedl.at/login.php, que también carece de menús de ayuda o similares. Jugando un poco con la demo, me encuentro con una herramienta parecida a Testlink aunque algo más rica en definición de casos de test. La creación/edición de un caso permite indicar pasos a ejecutar estableciendo la acción a llevar a cabo, los test inputs y el resultado esperado. Además se ofrecen muchos campos informativos para clasificar el caso de test donde proceda (no hay clasificación en árbol como en Testlink), aunque algunos de estos campos son de contenido aparentemente fijo (por ejemplo, el campo “Test type” muestra los valores “functional / regression / performance / smoke”); estos campos serían realmente útiles si fueran personalizables, pero no es el caso (o no parece serlo, pero no hay nada que indique lo contrario ni área de configuración adecuada). Sí se permite subir ficheros de soporte a los casos (aunque en la demo no pueda hacerlo funcionar) y marcar un test como “automático”, aunque sea mera clasificación.

Una funcionalidad curiosa es que RTH permite gestionar la elaboración y mantenimiento de los casos de test, marcándolos con un “estado” a escoger (nuevamente campo no configurable) entre estados como Work in progress, ready to review y similares. Además permite asignar los casos a alguien, estableciendo un calendario de fechas esperadas sobre acciones a realizar sobre los casos (completar, validar, revisar…). Parece una funcionalidad bastante útil en caso de que las aplicaciones experimenten cambios frecuentes o nuevos requerimientos que exigan modificar los casos de test que los cubran, sabiendo siempre si los casos ejecutados están actualizados, validados, pendientes de revisar, etc.

El área de requerimientos es bastante parecida a la de casos de test, con varios campos informativos de contenido fijo. La asociación de requerimientos a casos de test es bastante buena, permitiendo vincular N casos a M requerimientos sobre la cobertura del 100% del requerimiento funcional. A su vez, la aplicación ofrece una matriz de trazabilidad automática sobre esta información.

La gestión de los test sets (agrupación de casos de test a ejecutar ante una release) es buena, creando la mencionada release, luego un build y luego el test set propiamente. Lo que no es tan bueno es la selección de casos a incluir en un set; esto es debido a que la creación de casos de test no es jerárquica, luego se depende de la información proporcionada en los casos para poder filtrarlos y seleccionarlos manualmente como parte del set. En su defensa, un test set se puede copiar entre releases y entre builds, evitando tener que repetir la selección manual a cada ejecución del set.

La ejecución de casos dentro de un set es aceptable, en caso de tests manuales muestra los distintos pasos permitiendo indicar el resultado obtenido en cada paso y el status del mismo, además de indicar el status de la ejecución global del caso. Para tests automáticos se puede indicar el status de la ejecución global. Las ejecuciones permiten especificar los motivos de fallo o bloqueo en los distintos pasos, hacer comentarios, indicar el entorno en el que se han hecho las pruebas, notificar a usuarios de la ejecución, etc. Sin embargo, el área de reporting es un área general que queda desligada de las releases o builds, cosa que implica seleccionar los datos a tratar en cada ocasión. Tampoco queda muy claro si se pueden añadir reports personalizados a los pocos disponibles.

Por último, la gestión de usuarios y permisos es correcta, siendo configurable en todo lo necesario. Por otro lado, RTH dispone de un área propia para registrar bugs y defectos, lo que deja en un desarrollo a medida la integración de la herramienta con cualquier bugtracker.

En resumen, y para poder puntuar:

  • Principalmente…
    • Creación, gestión y ejecución de test cases – OK (mejor que Testlink en lo que a ejecución se refiere)
    • Creación, gestión y ejecución de test plans – KO (mala inclusión de casos en sets)
    • Gestión de resultados de ejecuciones – OK (justito, pero aceptable)
    • Vinculo entre test cases y use cases / user stories / requerimientos – OK
  • Más en segundo término…
    • Integración con la herramienta de bugtracking implantada en la empresa: TracKO (al tener un área de defects propia, quedaría como un desarrollo a medida)
    • Gestión de recursos asociados a un test case – OK
    • Facilidad de instalación y mantenimiento como herramienta – KO (muy poca información al respecto, proyecto casi inactivo)
    • Gestión de N proyectos por M usuarios, idealmente con permisos distintos (creación, ejecución, consulta…) – OK
    • Ejecuciones iterativas sobre un mismo test plan – OK (mediante builds dentro de una release)
  • Y en último lugar…
    • Integración con tests automáticos – OK
    • Test cases, test plans y resultados imprimibles / exportables – KO (solamente son exportables los casos de test, aunque el resultado no es demasiado bueno)

Siguiendo los criterios establecidos, esta evaluación se queda en un aceptable 8 sobre un máximo de 24.

Comparativa de evaluación entre herramientas de gestión de test cases

Comparativa de evaluación entre herramientas de gestión de test cases

En resumen, RTH me ha gustado más que Testlink, sin embargo la inactividad del proyecto me hace desconfiar de la herramienta como una apuesta de futuro. Necesitamos una solución lo más estable y mantenida posible, ya que ni el area de QA (que ahora mismo soy yo solamente) ni el area de desarrollo tienen recursos para gestionar/mantener herramientas que no sean las propietarias.

Seguimos buscando…

Status update

Por varias razones, el área de QA de Netquest (la empresa donde trabajo), vuelve ha quedar como una área unipersonal conmigo al frente. De la experiencia de trabajar en equipo extraigo una gran conclusión, que es la siguiente:

Incorporar y formar a un nuevo compañero es una tarea muy difícil sin tener el área organizada y con un roadmap claro y bien definido.

Entonces, antes de que volvamos a incorporar (inlcuso entrevistar) a una nueva persona en el área, quiero tener los deberes hechos: dibujar un buen plan, establecer unos objetivos concretos, trabajar para conseguirlos y tener unas líneas de acción desarrolladas e iniciadas para que la nueva incorporación tenga un “camino a seguir”. A su vez, tener el área bien organizada permite ahorrar tiempo en algunos aspectos, tiempo a dedicar en mejorar en otros aspectos de organización, alcanzar hitos del roadmap y formar a esa nueva persona en su nuevo puesto. Todo parecen virtudes, a conseguir con trabajo duro!

Mi principal meta con todo esto es conseguir la calidad total en las aplicaciones de Netquest y en sus procesos, idealmente sin dejarme la vida en ello. Según lo aprendido y siguiendo esta meta, los objetivos concretos son:

  1. Revisar, actualizar y completar las especificaciones de las herramientas que desarrollamos, esto es un prerrequisito para…
  2. Crear, actualizar y gestionar la batería de casos de test manuales que cubran las funcionalidades especificadas, para lo que necesito una buena herramienta de TC Management.
  3. Avanzar en la automatización, haciendo una primera inmersión en JUnit (framework que ya se usa en uno de los proyectos) y clarificando qué es conveniente automatizar y con qué herramientas.

Seguiremos informando al respecto…