Blog

A continuación, te dejo algunas referencias como para que puedas profundizar en el tema:

El testing automatizado en proyectos ágiles sigue ganando más presencia debido a los beneficios que ofrece y debido a ello, muchos testers ágiles aplican determinadas técnicas como las pruebas exploratorias para facilitar el entendimiento del alcance de las historias de usuario y lograr extraer escenarios más explicativos a partir de los criterios de aceptación. (Referencia: ISTQB CTFL-AT 2014 | 2.1.1 Actividades de Prueba y Desarrollo)

El cuadrante Q3 correspondiente al nivel de aceptación del sistema o usuario enfocado al negocio, y se aplican pruebas que persiguen el objetivo de criticar el producto, utilizando escenarios y datos reales. En este cuadrante se aplican pruebas exploratorias entre otras y suelen ser manuales y orientadas al usuario. (Referencia: ISTQB CTFL-AT 2014 | 3.1.3 Cuadrantes de Prueba, Niveles de Prueba y Tipos de Prueba)

En marcos de trabajo ágiles, los testers ágiles durante el sprint crean casos de prueba (manuales y/o candidatos a automatizar) en paralelo al código que van construyendo los desarrolladores. De la misma manera que los desarrolladores, los testers ágiles crean pruebas basándose en los criterios de aceptación de las historias de usuario. En ciertas ocasiones, las pruebas exploratorias se crean más tarde, durante la ejecución de pruebas. (Referencia: ISTQB CTFL-AT 2014 | 3.3.3 Diseño de Pruebas de Caja Negra Funcionales y No Funcionales)

El testing exploratoria es una muy buena alternativa en proyectos ágiles donde el tiempo disponible es escaso para analizar y los detalles de las historias de usuario son limitados. En este contexto, se pueden lograr muy buenos resultados aplicando testing exploratorio debiendo combinarlo con técnicas por ejemplo como las siguientes:

• prueba basada en el riesgo, 
• prueba basada en los requisitos, 
• prueba basada en modelos y;
• prueba adversa a la regresión)(*)

(Referencia: ISTQB CTFL-AT 2014 | 3.3.4 Prueba Exploratoria y Prueba Ágil)

(*)

Las pruebas adversas a la regresión, también conocidas como pruebas adversas o pruebas de negación, son una técnica de prueba utilizada en el contexto del testing de software y el testing ágil. Estas pruebas se centran en identificar y probar los aspectos menos obvios o menos intuitivos del software con el objetivo de descubrir defectos ocultos o comportamientos inesperados.

La idea principal detrás de las pruebas adversas a la regresión es adoptar una mentalidad de «atacar» el software desde diferentes perspectivas, explorando escenarios que podrían no haber sido considerados inicialmente. Esto implica ponerse en el papel del usuario malintencionado o del peor escenario posible y buscar activamente formas de romper el software o hacerlo fallar.

Al combinar las pruebas adversas a la regresión con el testing exploratorio, los equipos de prueba pueden obtener una cobertura más amplia y profunda. Mientras que el testing exploratorio se basa en la experiencia y el conocimiento del tester para descubrir defectos mediante la exploración y experimentación del software, las pruebas adversas a la regresión añaden una capa adicional de intencionalidad para encontrar situaciones límite o inesperadas.

Aquí hay algunos ejemplos para ilustrar las pruebas adversas a la regresión:

Entrada de datos incorrectos: Probar el software con datos de entrada inapropiados o incorrectos, como valores fuera de rango, caracteres especiales o cadenas demasiado largas o cortas.

Comportamiento anómalo: Identificar y probar situaciones en las que el software puede comportarse de manera inesperada o producir resultados incoherentes.

Estrés y carga: Someter el software a cargas de trabajo excesivas o escenarios de estrés extremo para evaluar su rendimiento y estabilidad bajo presión.

Uso indebido o abuso: Intentar utilizar el software de formas no previstas, realizar acciones fuera de secuencia o manipular los datos para encontrar posibles vulnerabilidades o debilidades en la seguridad.

Es importante tener en cuenta que las pruebas adversas a la regresión no reemplazan otras técnicas de prueba, como las pruebas de regresión tradicionales, las pruebas unitarias o las pruebas de integración. En su lugar, complementan y enriquecen el conjunto de pruebas existente al abordar aspectos específicos de la calidad del software que podrían pasar desapercibidos de otra manera.

Al aplicar las pruebas adversas a la regresión en combinación con el testing exploratorio, los equipos de prueba pueden descubrir y abordar problemas ocultos o desconocidos, mejorar la robustez del software y aumentar la satisfacción del usuario final al ofrecer un producto más confiable y resistente.

En el testing exploratorio, el diseño y la ejecución del caso de prueba ocurre al mismo tiempo, siguiendo un guión establecido que en muchos casos se lo suele denominar ‘contrato de prueba’. En el guión se encuentran definidas las condiciones de prueba a cubrir durante una sesión(**) de prueba que tiene bien marcado el tiempo límite. A medida que se va realizando la prueba mediante la exploración, los resultados que se van obteniendo sirven de guía para la siguiente prueba. Para la confección de los casos de prueba se pueden aplicar las técnicas de caja blanca y/o de caja negra. (Referencia: ISTQB CTAT | 3.3.4 Prueba Exploratoria y Prueba Ágil)

(**)

Una sesión es un periodo ininterrumpido de pruebas que puede durar entre 60 y 120 minutos, incluyendo:

• Sesión de estudio (objetivo: saber cómo funciona).
• Sesión de análisis (objetivo: evaluar la funcionalidad o las características).
• Cobertura profunda de escenarios e interacciones (objetivo: enfocarse en casos extremos).

Estructura del guión para pruebas exploratorias

• Actor: perfil de usuario previsto del sistema.
• Propósito: objetivo concreto que el actor quiere alcanzar.
• Preparación: todo lo que hay que tener y hacer para iniciar la exploración (ejecución de prueba).
• Prioridad: importancia relativa de este contrato, basada en la prioridad de la historia de usuario asociada o en el nivel de riesgo.
• Referencia: historia de usuario, riesgos u otras fuentes de información.
• Datos: los datos necesarios para llevar a cabo la exploración.
• Actividades: lista de ideas de lo que el actor puede querer hacer con el sistema (por ejemplo, «Entrar en el sistema como superusuario»).
• Notas del oráculo: cómo evaluar el producto para determinar los resultados correctos.
• Variaciones: acciones y evaluaciones alternativas para complementar las Actividades.

(Referencia: ISTQB CTFL-AT 2014 | 3.3.4 Prueba Exploratoria y Prueba Ágil)

No debemos olvidarnos de las herramientas que nos permiten conducir pruebas exploratorias, con las cuales podemos capturar y registrar las actividades realizadas en una aplicación durante una sesión de prueba exploratoria. Utilizar una herramienta es de mucha utilidad cuando encontramos un defecto, ya que tenemos todo registrado a medida que fuimos explorando y por lo tanto podremos informar del defecto a los desarrolladores de manera más eficaz y eficiente. Por otra parte, si además formamos parte del equipo de testers automatizadores, el registro de los pasos realizados durante la sesión puede incluirse en el conjunto de pruebas de regresión automatizadas. (Referencia: ISTQB CTFL-AT 2014 | 3.4.5 Herramientas de Diseño de Pruebas, Implementación y Ejecución)

A modo de ejemplo y para que puedas profundizar al respecto, te comparto dos herramientas que las he utilizado y que te las recomiendo para que puedas «explorar» el «testing exploratorio» 🙂