Uso de Machine Learning para la selección de casos de prueba en regresion de testing software

Hoy quiero compartirles mi análisis de un artículo académico llamado "Test Case Selection through Novel Methodologies for Software Application Developments" que pueden acceder aquí.
Publicado por los autores:
             - Dr K R Sekar, Sastra university
             - G. Sathiamoorthy, Sastra deemed to be university
             - El-Sayed M. El-kenawy, Delta higher institute of engineering & technology 

Los autores analizan cómo el uso de machine learning puede optimizar la selección de casos de prueba en regresión, el desafío para los tester es seleccionar el subconjunto de casos de prueba que detecte la mayor cantidad de errores en el menor tiempo posible.

Los autores proponen un modelo que llaman SCARF-RT

                                                            Similarity coefficient
                                                            Creating Acronyms
                                                            Regression test
                                                    and   Fuzzy set
                                                    with  Dataset

y otras metodologías que utilizan una combinación de clustering basado en coeficientes de similitud y ranking.  

El estudio considera 11 características de los casos de prueba valoradas por expertos para el agrupamiento de los casos de prueba, y evalúa dos metodologías diferentes para saber cuál es mejor para seleccionar los CP en regresión.

a. Metodología 1 --> Clasificación con enfoque en ranking, agrupa los CP basándose en su ranking y la cobertura de características.  A cada fila-columna se le asigna un peso binario para determinar el peso total y luego ordenarlo.

b. Metodología 2 --> Clasificación por coeficiente de similitud difusa, calculando la similitud entre los CP usando las 11 características y formando clusters de CP similares.  Se usa la composición Maxmin para encontrar equivalencias difusas y hacer el agrupamiento.

-----------------------------------------------------------------------

ALERTA DE SPOILER... 
si no quieres saber qué metodología es mejor hasta el final, saltate esta sección

Les adelanto el resultado (Spoiler) este estudio encontró que ambas metodologías son eficientes para la detección de bugs y reducción de casos de prueba, con la segunda metodología logrando un porcentaje de reducción en la selección de casos de prueba mayor con una cobertura total de las características.

El estudio afirma que con esta metodología se puede entender la cantidad de casos de prueba necesarios para probar el verdadero objetivo de una aplicación de software en pruebas de regresión,

-----------------------------------------------------------------------

A continuación intentaré explicar en mis propias palabras y con mis observaciones el experimento que los investigadores llevaron a cabo (por eso la letra AZUL :) )

Recuerda que esta predicción es porque ya has realizado como mínimo 1 ciclo de pruebas y tienes información no sólo del diseño de tus casos de prueba, sino también de los bugs detectados durante las pruebas ejecutadas.

Los investigadores eligieron las siguientes características como influyentes para la predicción:

C1 - Bugs críticos descubiertos durante el testing

C2 - Cobertura de requerimientos, qué tanto el CP los cubre

C3 - El tiempo que requiere ejecutar el CP

C4 - LOC líneas de código cubiertas por el CP 

C5 - Total de bugs detectados

C6 - Longitud promedio de pasos de prueba, validaciones de campos de entrada o condiciones cubiertas en el CP

C7 - Requerimientos críticos cubiertos, es parecida a C2, pero esta característica se enfoca sólo en los críticos.

C8 - Prioridad del CP basada en las perspectiva del cliente

C9 - Propensión a fallas, basados en el primer ciclo de pruebas

C10 - Volatilidad de los requerimientos, es decir la frecuencia de cambios en los requerimientos para este CP durante el proceso de pruebas.

C11 - Complejidad del desarrollo 

Hablando a calzón quitado, estas características en la teoría cubren bien lo que puede afectar la predicción de ocurrencia de bugs; sin embargo creo que en empresas grandes como bancos que subcontratan con casas de software el desarrollo y con otros proveedores el software testing, puede llegar a ser más complejo de implementar porque interactúan más actores cada uno con sus propios sistemas y reunir y llegar al detalle de información por ejemplo de la C4 cantidad de líneas cubiertas por el CP podría ser muy muy difícil.... cada quien que tome del esquema propuesto y adecúe a su situación particular, sigamos que vamos bien!

-----------------------------------------------------------------------

METODOLOGIA 1

Los 11 rasgos o características de los casos de prueba (c1 .. C11) los evalúa el experto utilizando valores linguisticos como "Muy bajo", "Bajo", "Medio", "Alto", "Muy alto".

Paso 1. 

Convertir esos valores linguisticos a números, así:

1 - Muy bajo

2 - Bajo

3 - Medio

4 - Alto

5 - Muy alto

La conversión de valores linguisticos (términos difusos/fuzzy) a números es necesaria porque técnicamente hablando es mejor que texto para los modelos de machine learning aprender con números que con letras, al menos hasta hoy, yo no sé mañana.

El objetivo es llegar a tener una matriz como la siguiente para los casos de prueba:

Ya tenemos lista nuestra matriz para aplicar la metodología

Paso 2.

Convertir los valores numéricos a valores binarios, usando un umbral.

Se decide que cualquier usar un umbral de 3 donde cualquier valor encima de 3 se asignará 1 y cualquier otro valor se asignará 0, esto para facilitarle al algoritmo de ML clasificar cuando es "bueno" o "malo" un CP.

Paso 3

Calcular el peso y ordenar las filas en base a él, es decir sumar el total de "puntos" de la fila, esto nos permitirá totalizar por cada caso de prueba cuántos puntos tiene, agregando esta columna al final.  Y repitiendo el mismo proceso para cada columna:

Luego las filas se reordenan en orden descendente según el valor total Fila.  

Paso 4

Calcular el peso y ordenar las columnas: 

Paso 5

Formación de clústers (agrupaciones).  Al tener así ordenada la matriz, se formarán clusters con puntos de datos que tienen un valor de 1, marcándolos como visitados.  Se buscan vecinos con un número de unos (1) que supere el umbrak (más de 3).  Si un punto de datos cumple con esta condición y aún no es parte de un clúster, se añade el nuevo clúster.  Este proceso se repite hasta que todos los puntos de datos son examinados. Si, cambié la tabla, sigan la idea y no se enreden con los detalles

El clúster amarillo  se compone de los casos de prueba: TC9, TC11, TC4, TC5 y TC10.  Muestra una cobertura del 100% para las características C1, C2, C3, C4 y C9.

El clúster violeta (recuadro) se compone de los casos de prueba: TC9 y TC11, aquí las características C8, C11, C5, C7 y C10 tienen una cobertura del 100%.

El clúster rojo se compone de los casos de prueba TC1, TC3, TC6, TC7, TC12, TC13 y TC15, donde las características C1, C2, C3, C9 y C4 están cubiertas en un 88.57%.

En resúmen, los clústers son el resultado de un algoritmo que reordena la matriz de forma que se evidencian las densidades de valores 1, lo que permite a los evaluadores seleccionar los casos de prueba que cubren mejor las características deseadas.

:: CONCLUSIÓN METODOLOGÍA 1 ::

Esta metodología resulta en la formación de grupos densos que contienen un porcentaje de las características identificadas.  Los casos de prueba dentro de estos grupos densos pueden ser seleccionados para validar funciones específicas del software.

-----------------------------------------------------------------------

METODOLOGÍA 2

A diferencia de la anterior, esta se centra en agrupar casos de prueba basándose en su grado de similitud.

Paso 1

Convertir los valores linguisticos a valores binarios, usando un umbral, igual que se hizo en los pasos 1 y 2 de la anterior metodología.

Paso 2

Calcular el coeficiente de similitud entre cada par de casos de prueba usando una fórmula (ej. coseno).

Paso 3

Conversión a relación de equivalencia difusa, los valores de similitud calculados forman una relación de tolerancia difusa, para poder formar clústers esta relación debe convertirse en una relación pero de equivalencia difusa, que satisface estas condiciones:

• Reflexividad.  Todo caso de prueba es completamente similar a sí mismo. Ej la similitud de TC1 consigo mismo es 1 
  
  
• Simetría.  La similitud entre el caso de prueba TCi y TCj es la misma que la similitud entre TCj y TCi.

• Transitividad.  Si TCi es similar a TCj y TCj es similar a TCk, entonces TCi es similar a TCk.  La transitividad se logra aplicando repetidamente la composición max-min a la matriz de similitud hasta que se estabiliza.  

Paso 4

Aplicación del Lambda-Cut, para formar clústers discretos.  Este corte es un valor umbral (ej 0.9, 0.8) que se elige para agrupar los casos de prueba, los casos con un valor de similitud igual o superior al valor de corte lambda se agrupan en un clúster.

Paso 5

Selección de casos de prueba, la idea principal de esta metodología es que los casos de prueba dentro de un clúster son altamente similares entre sí.  Por lo tanto, suficiente seleccionar uno solo para representar al clúster, lo que permite reducir significativamente el tamaño del conjunto de pruebas sin comprometer la calidad, por ej, en un nivel de confianza de 0.9 los casos de prueba seleccionados fueron TC1, TC2, TC3, TC4 y TC8.

:: CONCLUSIÓN METODOLOGÍA 2 ::

Es un enfoque eficaz para seleccionar casos de pruebas de regresión, utiliza la agrupación basada en el coeficiente de similitud difusa, lo que permite una reducción significativa en el número de casos de prueba sin sacrificar la calidad de la prueba.

WORLD QUALITY REPORT
2019 - Tendencias en QA

Les comparto este enlace con el video que cree sobre las tendencias en calidad de software de acuerdo a los resultados del informe del World Quality Report (para quienes no sepan qué es, es el único reporte a nivel global que evalua las respuestas de 1.700 encuestados en 32 países para analizar qué está pasando en el mundo del testing y hacia donde vamos).

Espero sea de su agrado.

https://sqasa.co/world-quality-report/

Como saber el impacto del atraso en mi cronograma?

Qué? Cómo?  Si.  Imagina que de alguna forma los constantes atrasos que se te han presentado en el cronograma no los has podido recuperar y son varios los módulos atrasados; ahora tu cliente te cuestiona si vas a lograr mantener la fecha fin de los hitos importantes del proyecto entre ellos la fecha fin global del mismo.... Imagina un cronograma de más de 5.000 lineas y más de 15 módulos diferentes cada uno actuando como un subproyecto.. que hacer?

R// Microsoft Project :)

Veamos mi ejemplo de construcción de un edificio:

Aquí observamos la columna % Esperado (columna personalizada con fórmula para saber cuál es el % de avance esperado de la tarea según la fecha de estado que le coloque a MSProject); en mi ejemplo la tarea "Estudiar complejidad solar" debería ir en un 62%  y realmente esta en 0%; esto es porque su predecesora la tarea de "Estudiar requerimientos"  debía durar 2 días según lo planeado en línea base y la verdad es que me demoró 17,67 dias... eso generó retraso en todo mi cronograma.

Ahora, cómo hago para saber cuál es el impacto en mis fechas hito?  En mi ejemplo parece fácil porque es sólo una tarea pero recuerda siempre.. cronograma grande 15 módulos con actividades en paralelo y serie entre unas y otras....  ahí no es tan fácil, pero MSProject me puede ayudar, despliega el menú y selecciona la vista de Variación:

Te debe quedar algo como:

Ahora, que me está diciendo la vista de Variación?  la columna Var. fin me dice la variación final de mi proyecto según lo que he registrado a hoy y siguiendo la planeación de predecesoras de mi línea base... osea que en lugar de terminar todo el proyecto el 07/04/2011 ( columna fin de linea base), a como voy hoy estaré terminando el 02/05/2011 (columna fin).

Para esto debo hacer el seguimiento de mi proyecto registrando las fechas comienzo y fin reales, no sólo colocando el % al 100 cuando haya terminado una tarea, así MSProject puede darse cuenta de cómo se han movido las fechas.

Así sé que tanto se me están desplazando las fechas por mis retrasos y de igual manera puedo empezar a pensar como solucionarlo.

Espero te haya servido descubrir esta vista.

PM - Cómo quemar linea base sólo de algunas tareas modificadas

Imagina que tienes que realizar un cambio a 2 tareas de tu cronograma y debes quemar línea base sólo de eso,  Cómo hacerlo?

Primero aclaro qué deseo hacer,  tengo un cronograma de un proyecto de ingenieria civil pactado con mis proveedores donde le quemamos linea base con la primera planeación que hicimos.  (no soy ingeniera civil ni tengo idea de eso, así que si estoy escribiendo una burrada déjenme un comentario sobre como redactarlo mejor, o ignoren el error y siganme la idea :)  )

Uno de los proveedores (Bob el constructor) tiene a cargo lo concerniente a las obras provisionales (id 2) y otro proveedor (PepaPig) es la encargada de las obras preliminares (id 9).

Como muestra la imagen, Bob está retrasado 2 día respecto a lo planeado (columnas linea base); y MS Project realiza la proyección del proyecto con lo que tiene de duración restante y de linea base para aquellas tareas que no han empezado; es decir, MS Project me dice que si sigo como voy y con lo planeado, no voy a terminar las obras provisionales el 8 de Julio 2013 sino el 10 de Julio ( ver columnas proyectas:  Comienzo y fin ).  Con Bob tengo una cláusula contractual donde por cada día de retraso como cliente tengo derecho a un descuento en la factura del 10%, por lo que no me interesa mover las fechas que teníamos pactadas, además porque necesito terminar el proyecto en la fecha planeada y quiero que Bob encuentre planes de recuperación de su retraso.

Ahora, en reunión con PepaPig nos damos cuenta de un problema con la limpieza del terreno (id 12) que no tuvimos en cuenta la temporada de lluvias y nos toca mover la fecha del plan.  Como cliente no veo problema y acuerdo con PepaPig mover las fechas de esta actividad para iniciar en Agosto y del Trazo y Replanteo (id 14).

Bien, cómo hago para quemar la nueva linea base si cuando MS Project quema LB toma las nuevas fechas que hay en las columnas Comienzo y Fin?  No quiero mover todas las tareas, que hago?

Práctica Personal, me gusta mantener el histórico de lineas base así que uso los espacios disponibles que tiene MS Project (10 espacios).

R//  Como acostumbro guardar mis históricos de líneas base, voy a tener que guardar en 2 espacios diferentes y así mismo ellos tendrán un comportamiento diferente.

Primero, seleccionamos con el mouse las tareas a las que queremos cambiar fechas

Luego, guardemos en un espacio nuevo (aquellos que no tienen fecha al final) en mi caso la línea base 2, mira:

Ahhh  bueno, para llegar a esta parte le das Menú Proyecto -> Establecer línea base.

Mira que en la imagen en la parte de abajo dice Para y he seleccionado Tareas seleccionadas y solo De subtareas a tareas de resumen seleccionadas

y listo!  Aceptar... el resultado:

Y uno se pregunta:  Cómo así? qué pasó aquí?  las demás tareas de linea base 2 quedaron como NOD... jajaja   sí, MS Project hizo justo lo que le dijimos: quemar linea base sólo de las actividades seleccionadas....   jajajja......

Igual me gusta la idea, este control de cambios fue aprobado para sólo modificar este pedazo del cronograma y es lo que quedará guardado en linea base 2.  :)

Pero yo necesito poder hacer seguimiento completo con estas nuevas fechas... como todos mis campos personalizados están formulados con las columnas comienzo linea base y fin linea base (la que no tiene numeración) pues debo volver a grabar linea base con el proceso descrito anteriormente pero sobreescribiendo la linea base sin numeración.  Al hacerlo el resultado es:

En la imagen observamos:

Comienzo y Fin linea base ->  La planeación que a hoy rige el proyecto (incluido el cambio de fechas en las actividades de PepaPig)

Comienzo y Fin linea base1 -> La planeación original del proyecto sin ningún control de cambios

Comienzo y Fin linea base 2 -> Los cambios al cronograma aprobados mediante control de cambios #1.

De esta manera mantengo lo acordado con Bob y los nuevos cambios de PepaPig sin afectar el resto del cronograma.

Cosas a tener en mente:

• Como estoy eligiendo qué actividades quemar... si las actividades de PepaPig modifican otro paquete de trabajo por ser su predecesora, y ésa actividad no la elijo para quemar linea base, pues no será modificada y me encontraré en el proyecto con la encrucijada de una actividad de BOB que depende de PepaPig y que no cambié su fecha..... plop !  Bob me podría demandar !! jajaja