Proceso de pruebas optimizado y predictivo

Ya ha llovido mucho desde que las empresas especializadas en calidad del software utilizaban un proceso de testing software tradicional a través del cual, por medio del análisis de un conjunto de requisitos, diseñaban unos casos de prueba que eran ejecutados. Esta ejecución permitía decidir si el software era apto o no para ser promocionado al entorno de producción.

Se trataba de un proceso impredecible y no optimizado, que no garantizaba un nivel de calidad determinado al final del mismo. Al no disponer de valores esperados no había posibilidad de identificar desviaciones durante las pruebas y, por tanto, resultaba complicado adoptar acciones correctivas. A modo de ejemplo, en un proyecto en el que tras haber ejecutado el 50% de los casos de prueba se hubieran detectado 35 defectos, no existía una forma objetiva de determinar si eran muchos o pocos y actuar en consecuencia.

Desde hace varios años, y con la evolución y mejora de los procesos de pruebas derivadas del uso de modelos de referencia tipo TMMi, los procesos de pruebas se han ido perfeccionando hasta llegar al punto de resultar predecibles, además de estar estadísticamente optimizados y controlados. Esto significa que ya es posible vaticinar el rendimiento del proceso de pruebas y tomar acciones correctivas en caso de existir desvíos. De esta forma, las pruebas de los proyectos se basan en métodos estadísticos que permiten pronosticar la calidad del producto, determinar aquellas partes del software más críticas y decidir dónde aplicar un mayor esfuerzo en pruebas. Todo ello redunda en una mayor madurez de los procesos de pruebas, logrando que resulten mucho más eficaces al facilitarse la detección de defectos con un menor esfuerzo.

En la práctica esto se traduce en disponer de perfiles de proyecto basados en datos históricos, que permitan prever qué es lo que va a suceder con futuros proyectos que cumplan el perfil. Un perfil consiste en la tipificación de un conjunto de proyectos de pruebas que comparten una serie de factores o características similares,  de tal forma que el perfil de proyecto sirva de referencia para futuros proyectos similares. Los perfiles se definen en función de las necesidades de la organización y características de los proyectos en base a factores como:

• Porcentaje de uso de funcionalidades del sistema por parte del usuario final
• Criticidad de las funcionalidades por parte de Negocio
• Número de defectos en pruebas por funcionalidad
• Número de defectos en producción por funcionalidad
• Esfuerzo en pruebas funcionales

Una vez definidos los perfiles y sus valores, el siguiente paso sería delimitar la tolerancia o límite de desviación aceptables; esto es, el valor a partir del cual consideremos que el desvío es lo suficientemente importante como para tomar acciones correctivas. Definidos los perfiles y las tolerancias obtendremos el rendimiento del proceso estabilizado y la línea base establecida para controlar el rendimiento del proceso de forma estadística.

Ante un nuevo proyecto de pruebas de software quality assurance, su perfil asociado nos indicará qué es lo que se prevé que ocurra en cuanto a número de incidencias por función / funcionalidad / sistema o componente tanto en fase pruebas como en producción; qué partes del software son más críticas en cuanto a importancia para Negocio y/o nivel de uso por parte del usuario, o también cuál debería ser el esfuerzo óptimo dedicado a testing software en los distintos módulos del mismo.

La información proporcionada por el perfil nos permite poner foco en aquellos aspectos realmente importantes, bien por su criticidad, bien por su nivel de defecto, e incrementar la cobertura de pruebas de calidad del software. Asimismo, durante la ejecución de pruebas nos aporta los datos necesarios para tomar acciones correctivas en caso de detectar desviaciones con respecto al perfil definido. Así, por ejemplo, se puede tomar la decisión de suspender las pruebas ante un exceso de defectos detectados o, por el contrario, poner el foco en otra parte del software en caso de descubrir menos defectos de los esperados.

En servicios de pruebas de calidad del software en un sector que tradicionalmente requiere de un proceso de pruebas muy efectivo, como es el sector Telco, es posible definir multitud de perfiles de proyectos. A modo de ejemplo, para el proceso de alta de cliente se puede definir un perfil que englobe los cuatro sistemas por los que pasa este proceso -CRM, Integración, Backend y Plataforma red-, algo que permite determinar:

• Número y porcentaje de defectos en cada sistema, tanto en pruebas como en producción
• Esfuerzo en pruebas de quality assurance dedicado a cada sistema
• Número y porcentaje de casos de prueba utilizados para cada sistema
• Tipología de defectos rechazados de cada sistema
• Porcentaje de uso de cada sistema por parte de Negocio
• Porcentaje de criticidad de cada sistema

Un proceso de pruebas de software quality assurance optimizado y predictivo permite aumentar el ratio de detección de defectos en un 15%, ya que pone foco en aquellos aspectos más conflictivos del software. Además, logra reducir el ratio de esfuerzos vs detección de defectos en un 10%, haciéndolo mucho más eficiente. Por otra parte, el ahorro de costes del servicio de pruebas se estima en el 12%. En definitiva, será un proceso mucho más eficaz, efectivo, predecible y controlado.

Por Javier de la Plaza
Responsable del Área de UX de MTP y TMMi Assessor

María Martín
Responsable de Soporte y Calidad Oficina QA

Ver más historias