¿Es posible ofrecer una valoración objetiva de la Calidad del software?

Las conversaciones que hablan de calidad del software son una fuente inagotable de términos ambiguos: el desarrollo debe ser correcto, el rendimiento adecuado, la seguridad alta, debe ser usable, mantenible y, en general, la calidad debe ser buena. Es complicado evaluar en base a estos términos si un software tiene o no una calidad adecuada…

Esta ambigüedad ha generado históricamente discusiones sobre la calidad del software que frecuentemente han acabado generando acuerdos a posteriori pero nos estamos moviendo hacia situaciones en las que queremos que la decisión de puesta en producción sea tomada por una máquina. Eso pasa, entre otras cosas, por aportar criterios objetivos que puedan ser programados de forma precisa.

Necesitamos establecer, pues:

• Un conjunto de criterios a medir
• Un indicador o conjunto de indicadores que permita medir cada criterio con un algoritmo que permita calcular su valor
• Y un dato de referencia que permita decidir si el valor obtenido para el indicador es admisible

Vamos a ver cada punto:

Criterios

Lo que queremos medir suele tener que ver con la búsqueda del cumplimiento de objetivos: queremos ver si estamos siguiendo adecuadamente los procedimientos de trabajo, si un proyecto va bien, si hay riesgo en el cumplimiento de fechas o en que el software esté plagado de errores, si el software que nos han entregado es de buena calidad…

No tiene sentido medir si no sabemos para qué queremos medir, así que lo primero que tenemos que tener claro es el “para qué” queremos medir y a partir de ahí nos vamos al qué.

Si hablamos de calidad del software (calidad de producto), una buena fuente para identificar criterios es la ISO 25000 (la evolución de la ISO 9126). En esta norma se presenta un modelo de calidad del software para el que se identifica un conjunto de “características” de calidad: funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad, portabilidad, seguridad y compatibilidad. Para cada característica se definen subcaracterísticas (disponibilidad, interoperabilidad, reusabilidad, corrección funcional…). Esta puede ser una buena fuente de “qués”. En cualquier caso, es necesario considerar, como indicábamos previamente, los objetivos del Negocio y, en ese sentido, la participación de las áreas de Negocio es particularmente importante.

Indicadores

¿Cómo medimos el criterio? Tenemos dos posibilidades: hacerlo de forma subjetiva o de forma objetiva. La opción subjetiva suele estar asociada a la opinión del usuario, del responsable técnico… suele basarse en encuestas y, siendo importante, es difícil integrarla en un escenario proactivo en tiempo real: necesitamos frecuentemente información antes de la puesta en producción y, si nos limitamos a la opción subjetiva, tendremos la limitación del momento. Así, por ejemplo, el usuario va a poder dar su calificación una vez haya usado la aplicación en producción real. Lo mismo pasa con los departamentos responsables de la explotación.

Así pues, ya sea en exclusiva o compartida con la opción subjetiva, es necesario utilizar mediciones objetivas. La fuente más frecuente de información para la medición de la calidad del producto son los resultados de las pruebas (estáticas o dinámicas) y, concretamente, los defectos localizados durante dichas pruebas.

No basta, sin embargo, con contabilizar los errores detectados. Debemos considerar factores de ponderación: ¿cuántas pruebas hemos hecho? ¿qué tan grande es el código? ¿qué tan complejo?… La combinación de defectos y factor de ponderación junto con un filtro que nos permita centrarnos en la característica o subcaracterística cuya calidad queremos controlar es lo que nos va a dar la fórmula que nos permitirá calcular el indicador.

Otra posible fuente a la hora de medir la calidad del software es ver hasta qué punto el trabajo realizado es suficiente: ¿Cuántos comentarios hemos generado en nuestro código?

Parece sencillo, pero no lo es…. A medida que vamos haciendo “zoom” van apareciendo más y más indicadores ¿Cuántos defectos ha generado una entrega? ¿Cuántos de esos eran funcionales? ¿Cuáles se esos estaban asociados a operativa crítica? ¿Cuántos de esos asociados a cada módulo… Una herramienta de análisis de código puede llegar a generar varios cientos de indicadores asociados a la mantenibilidad. ¿Los obtenemos y consideramos todos? Debemos evitar que los árboles nos impidan ver el bosque. Necesitamos un conjunto de información manejable que nos permita tomar decisiones a la hora de medir la calidad del software.

En el caso de que la decisión la tome una máquina, el número de indicadores puede no ser tan problemático pero agrava un segundo factor de riesgo: la disponibilidad de los datos asociados a los parámetros (primitivas) que componen la fórmula del indicador:

• En primer lugar, los datos pueden o no estar registrados. Hay organizaciones en las que los errores detectados se informan por correo o de palabra (no siendo, por ello, directamente procesables). Sin llegar a tanto, es frecuente que no llegue a registrarse la causa raíz de un error… La ausencia de detalle en la información registrada puede impedirnos obtener indicadores que nos digan el módulo que más errores genera, el tipo de errores que genera, si estos están asociados a determinadas interfaces, si la seguridad suele tener agujeros… Conseguir que los datos se registren en tiempo y forma es, frecuentemente, lo más difícil de conseguir, al necesitarse cambios en los procedimientos de trabajo (o en su grado de aplicación).
• En segundo lugar, la fuente de los datos puede ser muy variada y estar distribuida. Las fuentes de datos (bases de datos, tablas…) pueden ser tecnológicamente distintas y requerir métodos de acceso desarrollados específicamente para cada fuente (ETLs).

Umbrales de calidad del software

¿Hasta qué punto una entrega es suficientemente buena? Es el “suficientemente” el factor que más frecuentemente genera ambigüedad: podemos, sin demasiado esfuerzo, identificar factores críticos en una organización (funcionalidad de la interfaz de usuario, de un módulo de backend, la seguridad, el rendimiento, la usabilidad…), pero es más complicado establecer donde está el límite de lo admisible.

¿Quién decide dónde debería estar el límite? Frecuentemente será el usuario, en ocasiones el responsable de definir y asegurar el cumplimiento de buenas prácticas (ej: Arquitectura)… Este responsable debe definir el criterio a seguir a la hora de establecer los umbrales de calidad (los “quality gates”). El objetivo “cero errores” es una petición (y, a veces, una oferta) relativamente frecuente pero es ligeramente menos realista que plantear un tiempo de respuesta cero o infinitos usuarios concurrentes… Hay que identificar objetivos viables y suele haber dos fuentes en las que basarse:

• Las referencias de mercado: estudios que proporcionan promedios de errores por punto función asociados a conceptos como la tecnología, el lenguaje de programación usado, la fase de pruebas o el nivel de madurez del equipo de desarrollo.
• El histórico en la organización: no hay ninguna referencia tan precisa como la que utiliza información derivada de tus sistemas, tu entorno, tus equipos de trabajo… el histórico de tu organización es la fuente ideal pero requiere una sistematización del registro de la información y un tiempo para ir acumulando datos y tendencias.

Y ahora, la valoración

Hemos empezado hablando de decisiones que toma una máquina (un programa, más bien). Los pasos que hemos dado nos van a permitir proporcionar instrucciones para que la decisión se ajuste a nuestras necesidades; sin embargo, todos los pasos descritos también son aplicables a una toma de decisiones “tradicional” llevada a cabo por una persona o conjunto de personas.

Aun en aquellos casos en los que la opción IA está disponible para la toma de decisiones, suele haber situaciones en las que la última palabra la toma una persona. En esos casos nos encontramos con que tenemos que aplicar distintos criterios o, al menos, matizarlos:

• No pueden definirse demasiados indicadores. Lo de los árboles y el bosque es particularmente aplicable a las decisiones tomadas por las personas.
• La forma de presentar la información debe ser lo más gráfica posible. Mejor un diagrama que una tabla.

La idea es tener clara la situación “de un vistazo” y para ello es particularmente importante el uso de cuadros de mando específicamente diseñados para la toma de decisiones.

En MTP disponemos de una amplia experiencia en la definición de indicadores y en la elaboración de cuadros de mando actualizados en tiempo real o de forma periódica (dependiendo de la frecuencia de refresco del dato de origen). En particular, disponemos de ETLs diseñados para recoger información de las principales herramientas QA del mercado y de los SGBD más habituales y de un “framework” que nos permite la elaboración de Cuadros de Mando online de forma rápida y eficaz.

Santiago Jaraba

Consultor Senior QA

Te puede interesar…

Conoce nuestros cursos quality assurance y accede a formación especializada de MTP.

Ver más historias