¡Primero el proceso!

Todo son procesos

«Hacer software es como fabricar coches.»

Esta es una frase recurrente que a veces debato con conocidos. Somos ingenieros, así que debería ser lo mismo, pero la gente de IT mayoritariamente responde con un no. El software evoluciona, no es algo estático como un coche.

Pero vamos a pensar de nuevo en el proceso de crear un coche: cuando una marca diseña un nuevo modelo, desde los conceptos hasta el plano de despiece final atraviesa por diversas fases, donde se refina y diseña cada pieza. Si nos fijamos en la imagen del coche a medio fabricar, podemos ver que los coches tienen unos agujeros circulares en toda la estructura. Para qué sirven? En algunos casos aligeran el peso total del vehículo o facilitan el paso de cables, pero en otros estos agujeros sirven para facilitar el acceso a los robots de soldadura, o para que los operarios puedan atornillar o acceder a zonas durante el montaje.

En esencia, cuando una marca de coches diseña un coche, no solo lo hace en términos de seguridad, regulaciones, potencia o estética, sino que también lo diseña en función de cómo va a ser fabricado y ensamblado. Es decir, en el proceso de fabricación. Vamos ahora a la frase del principio. Si pensamos en que un modelo de coche es equivalente a nuestro software y los coches fabricados son las releases, entonces podemos hacernos una pregunta sobre esta analogía:

Fabricamos/Diseñamos software en función no solo del producto final, sino también del proceso de fabricación de ese software? Respuesta: No siempre, aunque es lo que deberíamos hacer.

Si trasladamos la analogía al mundo del software, vemos que las compañías que desarrollan software pueden tener múltiples equipos trabajando en un software, y que éste se desarrolla en fases o piezas que después se integran entre ellas. Sabemos que un módulo o librería perfectamente desarrollado con 100% de cobertura puede tener problemas al trabajar con otro software perfecto, por errores en la integración debido a una mala comunicación o interpretación de la documentación. Este es un caso bastante común en el mundo del software: muchos errores están relacionados con los procesos. Y esos errores afectan a la percepción de la calidad por parte del cliente, que solo ve el error y no tiene en cuenta qué esfuerzo se ha hecho en las pruebas. Sabemos también que un cambio en el proceso de desarrollo y release puede tener un impacto muy grande en la calidad del software, sin que para ello medien pruebas. Por ejemplo, sabemos que trabajar con versionado de código, como git, impacta en la calidad del producto si lo comparamos con enviar nuestro código por slack.

Un caso del mundo real

Vamos a pensar en un ejemplo que podemos ver en muchas compañías. Imaginemos un equipo Agile heterogéneo, con Backends, Frontends y uno o dos QAs, un scrum master o PO y quizás algún DevOps. Nada fuera de lo común. En las retros se quejan de la falta de foco durante los sprints. Que tienen varios errores que obligan a parar y cambiar de contexto para arreglar bugs incluso con algún sprint de diferencia, muchos debidos a la comunicación interna del equipo.

Esto, como se muestra en la imagen, es bastante común. El backend hace su tarea y al acabar el QA prueba y automatiza pruebas de esa tarea. Pone la tarea a ‘done’ y entonces entra en juego el frontend, que desarrolla consumiendo el API que ha creado el backend. Luego, el QA de frontend prueba y automatiza pruebas sobre la tarea del frontend dev. Este proceso puede durar más de un sprint y eso significa que el BE ya está con otras tareas. Entonces, qué pasa si el QA encuentra un error en el Frontend que destapa un error?

El error puede ser de diferentes naturalezas: puede ser que el contexto dado por el PO no fuera completo, puede ser un error no encontrado en backend o una divergencia entre lo que entiende FE respecto a lo que piensa BE. Como siempre en este caso, se habla de falta de documentación y de que todo el equipo debe revisar tareas que en teoría ya estaban cerradas.

El cambio de proceso que se propone es bastante simple: documentar las APIs con OpenAPI y proporcionar/actualizar mockups de estas APIs antes de hacer las tareas de backend. Crear una documentación por endpoint es fácil y no es necesario hacerlo para aquellas donde no vayamos a trabajar en ese momento. No es todo o nada. Crear mocks a partir de la documentación es fácil. Existen un buen número de ejemplos en DockerHub.

¿Qué ganamos con esto?

• Los BE tienen una documentación funcional con ejemplos donde probar, que además es una fuente única de verdad (unique source of truth).
• Los QAs de BE tienen mockups para programar tests desde antes de que haya código, y los ejemplos de la documentación sirven para generar tests automáticos. Además, el BDD cobra sentido aquí puesto que podemos formular tests antes de que la tarea esté finalizada por parte de los BE, y estos test pueden servir como tests de aceptación.
• Los FE tienen una documentación común que consultar y probar, pero como además tienen mockups ya pueden empezar sus tareas puesto que ya pueden llamar a urls funcionales aunque mockeadas.
• Los QAs de FE pueden escribir sus tests mucho antes.
• Incluso los DevOps pueden probar pipelines con los mockups, pensar en entornos efímeros para las pruebas, etc…

Pero el principal beneficio es que todo el equipo puede poner el foco en una tarea y no variar el foco en función del tiempo. Un cambio de proceso puede llevar a un cambio en la calidad del producto a través de ayudar al equipo a centrarse en lo que es importante y a través de reducir la incertidumbre teniendo una única fuente de verdad. Y esa podría ser la primera conclusión de este artículo: entender, mejorar y monitorizar procesos tiene un impacto crítico en la calidad del producto. Pero también nos deja una pregunta: ¿Cuál es entonces el papel de los ingenieros de QA?

Analizar procesos

Sabemos desde hace tiempo que los tests no son sinónimo de calidad. Se puede probar 100 veces un sistema y encontrar 100 errores diferentes, simplemente por que hay demasiadas carencias en los procesos de desarrollo (mal código, demasiadas dependencias, gestión incorrecta de la configuración, entorno de desarrollo en mal estado,….). Y tras probarlo 100 veces, el sistema no habrá mejorado su calidad. Los tests no aumentan la calidad!. Hay que pensar en ellos como una red de seguridad que atrapa (algunos) bugs.

Existen muchos tipos de errores, que se pueden clasificar en tipologías y que se encuentran y se solucionan con técnicas conocidas, aunque se pueden resumir en errores de código, errores de configuración y errores de datos.

También existe otra tipología de errores relacionados con errores en la comunicación entre equipos o en procesos mal definidos. Estos son los más peligrosos, por imprevisibles. Y son los que pueden llegar a producción. Si por ejemplo, alguien toca algo en una configuración de un entorno de test y no lo comunica a nadie, se puede dar el caso de que esa configuración falte en producción. Y es muy complicado modelar un escenario para fabricar un test que prevea esta situación. Solo la estandarización de procesos puede evitarlo. Y para analizar y mejorar esos procesos lo ideal es analizarlos cíclicamente

La idea principal es aprovechar nuestros test para detectar errores, y junto con la información que tengamos de otros errores establecer una clasificación de las tipologías de errores y basarnos en eso para mejorar los procesos. Una vez introducimos nuevos procesos, analizaremos su impacto midiendo la misma tipología y frecuencia de los nuevos bugs.

Sobre esta base es importante que el análisis de los errores sea objetivo y profundo. No quedarse en él «quien ha introducido el error» sino intentar entender la cadena de acontecimientos que ha conducido a ese error.

Algunos puntos a realizar:

• Analiza tus procesos usando los resultados de los tests y las tipologías de los bugs.
• Analiza primero los bugs de producción antes que los detectados con tus tests (sesgo del superviviente).
• Cambia tus procesos de uno en uno si piensas medirlos.
• Comprueba si un proceso se adapta a tu equipo, no existen balas de plata.
• Entiende tu contexto y usa mockups para controlarlo.
• No pruebes aquello que no puedes cambiar (ownership).
• Prioriza procesos que sean estándar.
• Prioriza procesos que pueden ser automatizados.
• Prioriza procesos que desacoplan tu equipo de otros.

Puntos a evitar:

• No ignores las necesidades de tu equipo cuando adoptes procesos.
• No intentes probar escenarios imposibles.
• Si algo no se puede testear, no lo pongas en la columna de «tested».
• Como QA no estás obligado a poner algo como probado. Comparte la responsabilidad con tu equipo.

Conclusión

En un momento u otro todas las compañías que producen software se adaptarán a metodologías DevOps para entregar con más frecuencia. En este sentido, los sistemas de pruebas, especialmente los centrales, deberán evolucionar con la industria y adaptarse, y junto con ellos, los ingenieros de QA deberán adoptar nuevos roles en las compañías que estarán más enfocados a ser proveedores de cultura de calidad y de herramientas y procesos para que los equipos donde estos actúan puedan entregar con mayor frecuencia y con más calidad.

En ese futuro, por otro lado, me cuesta ver cómo se compagina un QA que tarda días en escribir un largo test end-to-end para probar un software en constante cambio y cuyas features están en producción desde el momento en que se hizo push a la rama de producción. Y más difícil es ver como la velocidad de escritura de esos tests se compagina con la exhaustividad necesaria para dar garantías.

El mundo del software está cambiando. Intentemos que este nuevo mundo sea un lugar mejor.