Cómo utilizar Confluence y JIRA para rastrear pruebas de proyectos grandes

En caso de que hayas llegado aquí esperando encontrar una publicación sobre ADT o ATC, pido disculpas por utilizar una etiqueta engañosa. Aunque lo que me gustaría compartir en esta publicación de blog es sobre pruebas, no se trata de ninguna herramienta o tecnología proporcionada por SAP. En cambio, es un ejemplo de cómo utilizar Confluence y JIRA para construir una herramienta para rastrear las pruebas de proyectos grandes, como por ejemplo la gran actualización a NW 7.50 con EHP8 y HANA-DB que hicimos recientemente.

Preparando el escenario

Hace varios años hicimos un gran proyecto de conversión a Unicode en un entorno de sistema MDMP con todo tipo de aspectos "divertidos": docenas de idiomas, incluidos los de doble byte para chino y japonés, conversiones de páginas de códigos, muchos textos en tablas donde el idioma del contenido no necesariamente coincidía con la clave de idioma (si es que existía). Con la ayuda de algunas herramientas y mucho esfuerzo manual, construimos nuestro propio vocabulario para tenerlo lo más listo posible para la conversión a gran escala de 5 (!) sistemas de producción durante un fin de semana largo.

Fuente: XKCD - https://imgs.xkcd.com/comics/unicode.png

Por supuesto, muchas tablas y, por lo tanto, procesos se vieron afectados y necesitaban ser probados, y no solo en un lugar, sino en más de 50 países de todo el mundo. No teníamos ninguna herramienta para ayudar con eso, solo un gran número de documentos de Word individuales que describían un caso de prueba cada uno. Esto podía ser algo tan simple como "imprimir cualquier tipo de documento SD y asegurarse de que el resultado sea legible en tu idioma" hasta casos de prueba más complejos, que requerían una serie de actividades, como "tomar un proceso SD desde la entrada del pedido pasando por la impresión del documento de entrega, hasta la facturación y finalmente a la contabilización en FI". Cada documento contenía información sobre el resultado de la prueba esperado, así como casillas para marcar "prueba exitosa" o "se encontraron problemas".

Estos documentos se colocaron en un gran archivo zip y se enviaron por correo electrónico a las filiales con instrucciones para ejecutar los escenarios descritos en un sistema de prueba y reportar los resultados. ¡Estoy seguro de que puedes imaginar qué tan bien funcionó eso y cómo se veía el feedback que recibimos! En algunos casos, simplemente recibimos de vuelta un archivo zip con documentos de Word actualizados pero sin un resumen que indicara qué había funcionado y qué no. Si teníamos suerte, alguien había completado un archivo de Excel adjunto, pero en su mayoría no. Básicamente, no había ninguna posibilidad de realmente evaluar cómo funcionaban las pruebas y teníamos que confiar en el lema de TI verdadero y confiable "no hay noticias son buenas noticias" - ¡si algo hubiera salido realmente mal, seguro que nos habríamos enterado!

Buscando alternativas

Poco después de que el proyecto de Unicode se puso en marcha con éxito, tuvimos que comenzar a planificar una gran actualización del sistema que implicaba un cambio a otra base de datos y una mudanza a otro centro de datos. Se decidió desde el principio que necesitábamos una forma mucho mejor de organizar las pruebas, ya que no queríamos enviar nuevamente documentos de Word comprimidos con casi ninguna posibilidad de mantener un seguimiento adecuado de los resultados. No teníamos herramientas disponibles como SolMan que - si mal no recuerdo - tiene algo para apoyar las pruebas. Eventualmente, esta búsqueda terminó en mi escritorio.

Justo en ese momento, acababa de configurar algunas pruebas para una de mis actividades de tiempo libre relacionadas con el cambio climático, donde había utilizado formularios de Google para recopilar comentarios sobre la funcionalidad del sitio web nueva/mejorada. Lo interesante de los formularios de Google es que los resultados terminan automáticamente en una hoja de cálculo que permite un filtrado adecuado para buscar problemas reportados, y también genera algunos paneles de control con gráficos circulares y otros gráficos. Usar formularios de Google internamente no era una opción, pero me dio una idea de lo que podía construir utilizando Confluence y JIRA.

Creación de documentos de prueba y listas de archivos

Basándome en los documentos de Word que ya teníamos con las descripciones de los casos de prueba, creé una plantilla simplificada que solo contenía campos para un ID de caso de prueba, un título, el módulo, la descripción de lo que se debe probar y el resultado de la prueba esperado. Las descripciones deberían ser, en la mayoría de los casos, bastante genéricas, a un nivel alto y con la expectativa de que los usuarios clave que conocen sus tareas y transacciones habituales realizarían la mayor parte de las pruebas. La recomendación, por ejemplo, era simplemente indicar: "generar una factura para un pedido estándar", pero sin mencionar números de cliente o material específicos, ya que estos serían diferentes dependiendo de dónde se realizara la prueba, tanto en el sistema en el que ocurrió la prueba como en el país / organización de ventas para la que se realizó. Además de "qué se debe probar", también se necesitaba descri