Una de las actividades más difíciles como Lead o Manager de un equipo de pruebas es medir los resultados, su dificultad radica en seleccionar los aspectos adecuados.

Es muy común asociar que los resultados de QA son de alguna forma equivalentes a la calidad que alcanza el software… y no es así. La calidad de software puede definirse como:

el grado en que el software alcanza estándares de excelencia basados en un criterio de calidad. Las características o atributos que determinan esta capacidad de satisfacer las expectativas del cliente son, funcionalidad, confiabilidad, performance, mantenibilidad, usabilidad y seguridad.

Entonces, esos atributos que determinan la calidad del software dependen de muchos factores y son el resultado de la colaboración de muchos equipos, incluso no solamente del área de desarrollo de una empresa.

Entendiendo que la calidad en general depende de muchos factores, por lo tanto lo que en realidad sirve para medir la efectividad de un equipo de QA son las actividades de prueba que permiten mejorar la calidad del software, como por ejemplo:

Análisis de defectos

Esta actividad es quizá la más importante y de la que se desprende la mejora continua. Para analizar bien, debes establecer cosas como el origen (defectos encontrados durante el desarrollo, en UAT o en producción), la severidad (usualmente muy alta, alta, media, etc), la causa (funcionalidad, error de configuración, etc) buscando siempre tener catálogos ya creados con el consenso de todos los equipos, con los cuales puedas catalogar todos los defectos de una forma estandarizada. El éxito de esto dependerá mucho de que todo el equipo de desarrollo conozca, acepte y aplique correctamente.

Una vez que hayas establecido todos esos valores para los defectos es hora de crear dashboards que te permitan analizar esta información, todo depende de que herramientas utilices, si usas Jira puedes ayudarte de jql y algunos addons que te permitan visualizar los datos más fácilmente como Custom Charts for Jira.

Cuando te sea posible visualizar estos datos podrás identificar tendencias, luego basándote en éstas podrás impulsar cambios en los procesos para mejorar estos resultados.

Algunas preguntas que podrás contestar luego de establecer un correcto análisis de defectos serán:

• En que parte del proceso (durante el desarrollo, en UAT, en producción ) se identifican más defectos?
• Que relación existe entre el número de historias de usuario terminadas con el número de defectos identificados?
• Cuales son las causas más comunes que provocan esos defectos?

Cobertura de pruebas automatizadas

Normalmente los equipos de QA se encargan de crear pruebas de integración y pruebas end2end automatizadas para llevar a cabo regresiones. La cobertura será entonces la relación que haya entre el número de pruebas manuales contra el numero de pruebas automatizadas que tengas; es decir, que tanto ya has logrado automatizar y que por tanto refleja una reducción del tiempo manual necesario, en otras palabras que tan eficiente eres para llevar a cabo pruebas de regresión. La importancia de esta métrica reside en que a mayor cobertura de pruebas automatizadas, se empleará menor tiempo en validaciones lo que ayudará a reducir los tiempos de desarrollo aumentando también la confianza en los releases.

Mejora continua

Esto se refiere al número de cambios y mejoras en los procesos de desarrollo que el área de QA ha realizado. Para impulsar estas mejoras usarás toda la información que obtuviste del análisis de defectos. Por ejemplo: si el mayor número de defectos es encontrado en UAT, es posible que la Definition of Done no se esté cumpliendo del todo y sea necesario evaluarla para volverla más efectiva.

Por otro lado, el análisis de los defectos no solamente puede ayudarte a proponer cambios en el proceso de desarrollo, si no también incluso en como el área de producto lleva a cabo el análisis y creación de requerimientos hacia los equipos de desarrollo. Otra valor de la categoría Causa puede estar relacionada con requerimientos incompletos, cambios de alcance, etc. Tanto más sean completas las categorías con las que catalogas los defectos, mayor oportunidad tendrás de identificar áreas de mejora.

Conclusión

No existe una receta que aplique a todos, la definición de métricas del equipo de calidad depende en gran medida de la madurez de los procesos de desarrollo y del apoyo de todas las áreas para implementarlas. Siempre es bueno empezar con algo básico que pueda mejorar con el tiempo y con la entrega de valor continua, cada mejora implementada allanará parte del camino y cada vez será más fácil. Como recomendación final te aconsejo dar un vistazo a las métricas DORA para conocer cómo otras empresas emplean cuatro métricas generales para medir el performance de los equipos de desarrollo.