Reyes Sánchez García/ septiembre 14, 2022/ Gestión de la calidad/ 0 comentarios

Tiempo de lectura: 7 minutos

Hoy te presento una opción muy interesante: el plan de pruebas de regresión con opciones. ¿Cómo enfocas el plan de pruebas de regresión de tus productos? ¿Cómo lo enfoca tu organización o empresa? Mi planteamiento es el siguiente: ejecutar un mínimo principal que garantice la calidad del núcleo de nuestro software. A continuación, ejecutar un variante planificado en un periodo de tiempo en función de las necesidades de tu producto. ¿Te suena bien? Sigue leyendo y te cuento un poco más.

Índice de contenidos

Plan de Pruebas de regresión con opciones

¿Qué es un plan de pruebas de regresión con opciones?

En primer lugar, debes saber que es. Un plan de pruebas de regresión con opciones es un plan de pruebas donde diseñamos y ejecutamos el CORE de las pruebas de regresión junto con un conjunto de casos complementarios. Estos últimos, se selecciona en función de diferentes estrategias. Del mismo modo, lo que es interesante de este plan de pruebas es que aseguramos que en un periodo de tiempo planificado, hemos ejecutado nuestro plan de pruebas al completo. De esta forma, se está más cerca de asegurar la calidad del software.

¿Cómo diseñar esta estrategia de pruebas?

En segundo lugar, es recomendable diseñar una estrategia de pruebas. ¿Cómo? Debes listar en un documento, por ejemplo, una hoja de cálculo, cuáles serán los casos de prueba que se deben incluir en la regresión. En esta primera versión, se debe incluir todo aquello que sea susceptible a probar. Después de eso, una vez que lo tenemos todo listado, se debe marcar cuáles son los casos principales o core. A continuación, se deben categorizar el total de los casos, de acuerdo a la funcionalidad en la que se engloban, la prioridad de ejecución y cualquier otro filtro que le venga bien a nuestro producto.

Además, se debe tener en cuenta que este listado se debe revisar de forma periódica. Por consiguiente, es susceptible a actualización en función de las correcciones o evoluciones que puedan acontecer en el software.

¿Cómo elegir las variaciones a ejecutar en el plan de pruebas de regresión con opciones?

En tercer lugar, te cuento uno de los puntos claves de esta estrategia de pruebas de regresión. ¿En función de qué se eligen las variaciones? Estas pueden variar en función del proyecto, de algunos parámetros o del periodo del tiempo o etapa en el que está el proyecto. Del igual modo, también puede depender de los cambios que han sido impactados en esta subida prevista a producción, etc. En cualquier caso, debes tener lista las distintas opciones para utilizarlas cuando sea necesario. En otras palabras, diseños implementados, datos de pruebas preparados, etc.

Variaciones por subgrupos similares (variaciones por parámetros)

En esta primera opción, nos encontramos con casos de prueba similares que prueban la misma funcionalidad, con la selección de diferentes opciones. En otras palabras, podemos probar variaciones de compras, variaciones del flujo para acceder a un mismo punto, variaciones de idiomas o incluso de navegadores o dispositivo.

Por ejemplo: Tenemos una tienda online en la que ofertamos un servicio con tres opciones: básico, intermedio y completo. De esta forma, en todas las ejecuciones del plan de pruebas de ejecución tenemos que ejecutar un caso, pero no siempre debe ser el mismo. Por tanto, se obtienen los siguientes casos de pruebas:

Caso de prueba Variación recurrente Funcionalidad impactada Prioridad
Contratación servicio Básico
V1
Paquete básico
3
Contratación servicio Intermedio
V2
Paquete Intermedio
2
Contratación servicio Completo
V3
Paquete Completo
4
Almacenamiento en BBDD del servicio contratado
CORE
Almacenamiento en BBDD
5

En otras palabras, en cada ejecución del plan de pruebas de regresión realizaremos una contratación de distinto paquete, sin embargo, en todas las ejecuciones comprobaremos que la información se almacena de forma correcta en base de datos.

En este sentido, si tenemos pases a producción 2 veces al mes y tenemos un conjunto de pruebas core y 3 variaciones, podemos asegurar que nuestro plan de pruebas de regresión tiene una cobertura del 100% cada 45 días. Del mismo modo, se debe tener en cuenta que en esos 30 días intermedios se pueden colar errores. Sin embargo, todo el que trabaja en software sabe que con presupuestos limitados, y fechas límite, la garantía de cero errores no existe.

Las Variaciones por funcionalidad impactada

En segundo lugar, otra estrategia en planes de pruebas de regresión con opciones, es la de tener en cuenta la funcionalidad impactada. Lo más importante, es partir de una buena categorización, así podrás tener identificados cuáles son los casos impactados por modificaciones en ciertas funcionalidades. Del mismo modo, se debe tener en cuenta que este enfoque no garantiza la regresión «completa» en un tiempo determinado. A menos que, se combine con otras alternativas. Por ejemplo, puede estar impactado la misma funcionalidad durante varios meses y no se hace regresión otros casos durante todo ese periodo.

Siguiendo nuestro ejemplo: se nos da la situación de que se hacen modificaciones en el paquete intermedio, modificando los productos o servicios que tiene incluido, modificando su visualización (incluido el logotipo) y con ello como se almacenan el paquete en BBDD. En este caso, tendríamos la selección de los siguientes casos de prueba:

Caso de prueba Variación recurrente Funcionalidad impactada Prioridad
Contratación servicio Intermedio
V2
Paquete intermedio
2
Visualización del logotipo Intermedio
V1
Paquete Intermedio
20
Visualización del paquete intermedio
V3
Paquete Intermedio
27
Almacenamiento en BBDD del servicio contratado
CORE
Almacenamiento en BBDD
5

En este ejemplo, hemos seleccionado los casos que impactan al paquete intermedio, incluyendo también los casos principales del software. En un principio, no sería necesario incluir casos de prueba de regresión de otros paquetes.

Variaciones por defectos en producción

En tercer lugar, tenemos las variaciones agrupadas por categorías de defectos de producción. En esta opción, es necesario tener una lista de los defectos registrados en producción, categorizados en función del grupo o funcionalidad a la que pertenecen. De esta forma, de forma similar al caso anterior, cuando está impactada un área concreta de nuestro software, se debe ejecutar este conjunto de casos.

Siguiendo con nuestro ejemplo, nos encontramos que tenemos los siguientes defectos registrados en nuestro sistema:

Defecto Grupo del defecto Funcionalidad impactada Prioridad
Logotipo de Paquete intermedio erroneo
Visualización
Paquete intermedio
15
Error en el cálculo decimal (Sin IVA) del Precio del Paquete Completo
Reglas de impuestos
Paquete completo
7
No se almacenan todos los servicios en BBDD en el Paquete Básico
Volcado en BBDD
Paquete Basico
2
En móvil IOs Safari: No se visualizan bien los servicios incluidos en los paquetes
Visualización
Paquete Básico
Paquete Intermedio
Paquete Completo
2

Siguiendo nuestro ejemplo, tengamos en cuenta que hemos realizado un cambio en la maqueta de visualización web. Además, se van a añadir a los casos core los relacionados con los defectos. En resumen, se tendría la siguiente selección: 

Caso de prueba Funcionalidad impactada Prioridad Grupo del defecto
IOs Safari: Visualización del paquete Básico
Paquete Básico
51
Visualización
IOs Safari: Visualización del paquete intermedio
Paquete Intermedio
20
Visualización
IOs Safari: Visualización del paquete completo
Paquete Completo
37
Visualización
Visualización del logotipo Intermedio
Paquete intermedio
25
Visualización

Con este enfoque, al haber acontecido cambios de maqueta en el entorno, optamos por seleccionar casos de prueba relacionados con los defectos de la categoría Visualización.

De igual forma, que en el apartado anterior, con esta selección no podemos garantizar que en un periodo de tiempo se haya ejecutado toda la regresión. Sin embargo, por otra parte, nos enfocamos en la parte más susceptible a estar impactada. Sobre todo, es una de las mejores opciones en situaciones en las que no tenemos mucho tiempo, ni recursos.

¿Cómo planificar la estrategia de pruebas de regresión con opciones?

En último lugar, debes hacer una situación en profundo del producto con el que trabajas y elegir la opción que más se adapte a cada hito o situación. Además, debes tener siempre preparadas las opciones B, C y D por si son necesarias. 

Del mismo modo, te recomiendo que realices enfoques híbridos que permitan aumentar la efectividad de tu plan de QAEn otras palabras, planifica unas regresiones con variantes genéricas cada X tiempo. Por ejemplo, 2 veces en el semestre. Además, en los hitos críticos aplica un enfoque por funcionalidad y por defectos, enfocándote en lo más impactado.

Conclusión: Elige pruebas de regresión con opciones para enfocarte en lo importante

En definitiva, es necesario optimizar lo máximo posible los tiempos y recurso de la empresa. En otras palabras, por mucho que se quiera asegurar la calidad del software no siempre se puede garantizar al 100%: el tiempo es limitado y los recursos también. Diseña, implementa, planifica y ejecuta un plan de pruebas de regresión con opciones para cada hito.

Espero que este post te sea de ayuda. Déjame un comentario y hablamos al respecto o suscríbete al blog.

Quizás te puede interesar

 
Compartir esta entrada

Dejar un Comentar

Tu dirección de correo electrónico no será publicada.

*
*