De Oppenheimer a Barbie: sal del caos al mundo perfecto priorizando el alcance de pruebas con RBT

Una de las principales puertas de entrada al área técnica de QA son las pruebas exploratorias. En este procedimiento, a un profesional de QA se le presenta un producto o proyecto con el que nunca ha interactuado y se le asigna la tarea de explorarlo para identificar defectos y reportarlos a los desarrolladores.

Este método le da al QA la libertad de explorar el sistema sin seguir rígidamente un conjunto predefinido de casos de prueba. Utiliza su experiencia, intuición y conocimiento para interactuar con el producto o proyecto, con el objetivo de descubrir posibles defectos, comportamientos inesperados y puntos de mejora.

En la práctica, suele haber confusión en esta etapa respecto a la terminología. Lo que describí arriba no son, en realidad, pruebas exploratorias, sino pruebas ad-hoc. La principal diferencia es que las pruebas ad-hoc no requieren experiencia previa ni planificación estratégica. En cambio, las pruebas exploratorias requieren experiencia previa y conocimiento de estrategias de prueba, como heurísticas, mapas mentales, checklists y técnicas similares, para explorar el producto de forma eficaz.

Según James Bach:

“Las pruebas exploratorias de software son un enfoque poderoso, pero ampliamente malinterpretado. En determinadas situaciones, pueden ser mucho más productivas que las pruebas guionizadas. Todos los testers practican alguna forma de prueba exploratoria, a menos que simplemente no creen pruebas. Aun así, pocos de nosotros hemos estudiado este enfoque a fondo, y no es muy respetado en nuestro campo. Esta actitud está empezando a cambiar a medida que las empresas buscan métodos de desarrollo de software cada vez más ágiles y económicos.”

No voy a profundizar en las pruebas exploratorias en este artículo (quizás en uno próximo), pero, si quieres una comprensión completa, te recomiendo dos referencias importantes:

• El artículo "Exploratory Testing Explained", de James Bach (citado arriba);
• El libro "Explore it! Reduce Risk and Increase Confidence with Exploratory Testing", de Elisabeth Hendrickson.

El libro, en especial, ofrece explicaciones detalladas sobre cómo explorar de forma eficaz, sesiones prácticas, factores de calidad, elementos esenciales y cuándo dejar de probar.

Priorización del alcance

Aunque estas lecturas abordan las pruebas exploratorias en profundidad, todavía queda un tema que no se menciona explícitamente: la priorización del alcance.

Después de estas lecturas, quizás ya entiendas cómo realizar pruebas exploratorias de forma más eficiente. Pero ¿cómo priorizar el alcance identificado durante las pruebas exploratorias? Sin esa priorización, toda la información recopilada puede convertirse fácilmente en un caos.

Con ese caos en mente, recordé otro recurso que conocí al inicio de mi carrera, conocido como Pruebas Basadas en Riesgo (RBT).

Las Pruebas Basadas en Riesgo (RBT) son un enfoque de pruebas de software centrado en asignar los recursos de prueba a las áreas del sistema que presentan mayor riesgo. Su objetivo principal es identificar, priorizar y tratar los riesgos del software, garantizando que las pruebas se concentren en los componentes críticos y más propensos a errores.

En lugar de aplicar las pruebas de manera uniforme en todo el sistema, el RBT optimiza el proceso de pruebas para maximizar el descubrimiento de defectos relevantes y, al mismo tiempo, minimizar los riesgos asociados al uso del software. Esto se vuelve especialmente crítico cuando los recursos de prueba, como el tiempo y el presupuesto, son limitados.

Puedes crear tus casos de prueba con base en estos esfuerzos, estructurados de la siguiente forma:

Los esfuerzos de prueba identificados mediante las pruebas exploratorias se priorizan de acuerdo con su impacto multiplicado por la frecuencia de ocurrencia (representados visualmente del rojo al verde, del número mayor al menor).

Una vez que todos los esfuerzos de prueba estén mapeados en esta matriz de trazabilidad, tu papel como QA es garantizar que la cobertura comience por los comportamientos con la mayor relación entre impacto y ocurrencia, avanzando hasta los riesgos menores y menos frecuentes.

Por lo tanto, el enfoque de tus pruebas siempre debe seguir este orden de prioridad: 25, 20, 20, 16, 15, 15, 12, 12, 10, 10, 9, 8, 8, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 2, 1.

Pero ¿cómo identificar qué parte del sistema corresponde a 25, 20, 16, 15 y así sucesivamente? Ahí es donde entra tu experiencia de campo. Si tienes dudas o no tienes experiencia, puedes apoyarte en benchmarks del mercado, en criterios de criticidad definidos por el cliente o validar estas prioridades con tu equipo.

En otras palabras, el amplio flujo del proyecto observado durante las pruebas exploratorias, que inicialmente parece caótico y sin priorización del alcance, empieza a transformarse en un proceso organizado y estructurado.

Mejor aún: no estás limitado a usar el RBT solo en la ejecución de pruebas. El RBT también puede aplicarse con eficacia en la priorización de reglas de negocio, criterios de aceptación, prototipos, documentación de requisitos y mucho más.

Curiosamente, a medida que practicas las pruebas exploratorias con más frecuencia, priorizar el alcance se vuelve algo natural, formando un framework eficaz de pruebas exploratorias basado en experiencia combinada con priorización del alcance.

Juntas, las pruebas exploratorias y las pruebas basadas en riesgo fortalecen la calidad del software, optimizan el proceso de pruebas y aumentan significativamente la probabilidad de descubrir y corregir defectos críticos antes de que lleguen a los usuarios finales. Estos enfoques no solo mejoran la detección de defectos, sino que también promueven una mentalidad proactiva de calidad, lo que permite una colaboración más estrecha entre los equipos de desarrollo y de pruebas para mitigar riesgos desde las fases iniciales del ciclo de vida del software.

La combinación de pruebas exploratorias y pruebas basadas en riesgo desempeña un papel crucial para garantizar la calidad de productos y proyectos. Las pruebas exploratorias permiten que los testers interactúen con el software de forma más intuitiva y flexible, con base en técnicas de prueba. Por su parte, las pruebas basadas en riesgo dirigen los esfuerzos de prueba hacia las áreas de mayor impacto y riesgo.

Al final, esta combinación estratégica contribuye a la entrega de un producto o proyecto más confiable, funcional y seguro.