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
¿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 QA. En 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
