Calidad del software — Más allá del testing
Usualmente, en el contexto mundial, cuando hablamos de calidad de software lo asociamos directamente con las pruebas; sin embargo, esto es parcialmente cierto, pues esperamos hasta llegar a esa etapa del proceso para garantizar los atributos de software funcionales y no funcionales, omitiendo algunos otros que también son importantes para lograr su calidad. En este artículo vamos a hablar acerca de eso y esperamos mostrarte una forma diferente de verlo.
En Bancolombia, hace unos años, iniciamos con journey to DevOps, el cual tiene un pilar clave en su filosofía: Continuous Testing y su objetivo es automatizar todas las pruebas del ciclo de software integradas a los pipelines. Iniciamos con un foco muy marcado: pruebas funcionales End2End, pero nos preguntábamos: ¿es el único atributo de calidad por el cual deberíamos preocuparnos? y la respuesta rotunda es NO.
Por eso, empezamos a desarrollar un tablero de calidad que nos permitirá mostrar, a todos los miembros de los equipos (tecnología, negocio y otros grupos de interés), cómo se encuentra este atributo en su aplicación. Aquí, tenemos una mirada integrada de todos los atributos, correlacionando algunas variables entre sí. Veamos cuáles:
- Variables ordenadas cronológicamente, asociadas a la estrategia shift left testing — Busca la ejecución de pruebas en etapas tempranas, tan pronto se desarrollen o instalen desde las etapas de desarrollo:
1. Pruebas unitarias.
2. Pruebas performance modular (foco a componentes específicos, ejemplo APIs).
3. Pruebas de aceptación (Front, Middle y Backend).
4. Pruebas funcionales End2End (foco transacciones del negocio de inicio a fin).
5. Pruebas performance End2End (foco transacciones del negocio de inicio a fin)
Las 5 pruebas mencionadas anteriormente son automáticas; por ejemplo:
Unitarias: junit (depende del lenguaje de la aplicación, para este ejemplo Java).
Performance modular: jmeter.
Aceptación:
- Playwright(front).
- Karate (middle /back).Funcionales End2End: Java y frameworks de pruebas (SerenityBDD, Cucumber, Gherkin, entre otros).
Performance End2End: Jmeter.
- Otras variables complementarias:
- Líneas de código de la aplicación (Lines of code — LoC).
- Deuda técnica de la aplicación.
- Número de defectos (bugs/issues) encontrados en ambientes pre-productivos.
- Número de incidentes en producción.
En este punto podemos hacer una serie de ejercicios de correlación de variables. A continuación, y para generar un mayor entendimiento y conciencia del tema, mencionaré algunos ejemplos:
- ¿Es lo mismo decir que tenemos 100 bugs en una aplicación con 650.000 LoC, que 100 bugs en una aplicación con 1.000 LoC?
La respuesta es NO, esto indica que la calidad de la segunda aplicación se encuentra mucho más deteriorada que la primera; en este caso, la conversación evoluciona pues no solo vemos la variable “100 bugs” como mucho o poco, si no que la analizamos entorno a la aplicación como un todo.
- Tenemos automatizadas la gran mayoría de las pruebas, con coberturas y niveles de uso con muy buenos porcentajes de adherencia y ejecución (>80%), donde el número de bugs en QA es cero y el número de incidentes en producción es alto, ¿sabemos por qué sucede esto?. Es importante aclarar que no es necesaria la implementación de todas las prácticas de pruebas pues esto dependerá de la naturaleza de la aplicación, el nivel de riesgo organizacional, la madurez del equipo, entre otros.
Una posible conclusión es que el enfoque de las pruebas no es el adecuado, debido a que no está encontrando los defectos de la aplicación en su etapa de desarrollo y se encuentran en producción.
Otra posibilidad, es que estemos más preocupados por “cumplir” cada etapa de pruebas, sin entender el propósito adecuado: asegurar la calidad del software.
Así como los dos anteriores ejemplos, se pueden desprender muchos más ejercicios. El mensaje final es que debemos ver la calidad de una aplicación, no solo como la ejecución de sus pruebas en etapas donde la aplicación parece “estar lista” para salir a producción; si no que también debemos garantizar las variables de calidad de manera temprana y esto hará que sea menos costoso en el tiempo (presupuesto, esfuerzo, leadtime, entre otras).
Se estarán preguntando y ¿la variable de seguridad? Esa también es fundamental y en otro artículo les estaremos hablando acerca de cómo hemos estado implementando el DevSecOps en Bancolombia.
Por último, quiero preguntarles ¿saben hasta dónde queremos llegar?. La respuesta es que queremos entregar un único atributo porcentual de calidad de aplicación, basados en todo lo expuesto anteriormente; tenemos un camino largo por sortear pero esto nos ayudará, en un futuro, a hacer uso del bigdata y los modelos analíticos predictivos para identificar posibles situaciones de cara a la producción. Sin duda, ¡debemos soñar!
Esperamos que esta información haya sido de utilidad para entender la estrategia de calidad como un todo y generar reflexiones que nos permitan mejorar 😃.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
