Respuesta.

Los casos de prueba son escenarios preparados de antemano con pasos claramente establecidos, resultados de entrada y resultados esperados. El testing exploratorio se lleva a cabo en el momento: el tester genera pruebas a medida que se familiariza con el producto, utilizando su experiencia e intuición. Históricamente, primero dominaron los casos de prueba, pero con la complejidad de los sistemas y el aumento del volumen de pruebas manuales, el testing exploratorio ha empezado a complementar los enfoques formales.

Problema

Seguir ciegamente solo un tipo de testing limita la creatividad del tester y puede dejar el producto con errores no detectados, no descritos en los casos.

Solución

Utilizar ambos enfoques de manera equilibrada: casos de prueba — para funcionalidad de regresión y crítica, exploratorio — para secciones nuevas, aún no formalizadas completamente y en tiempos cortos.

Características clave:

Los casos de prueba — garantizan repetibilidad y resultados comparables
El testing exploratorio — aumenta la posibilidad de encontrar errores no estándar y engañosos
Ambos enfoques deben ir juntos

Preguntas capciosas.

¿Se pueden utilizar solo casos de prueba para un 100% de cobertura?

No. Ni el conjunto de casos más detallado cubre el comportamiento inesperado del usuario o errores no estándar.

¿El testing exploratorio requiere preparación previa?

Sí. Es necesario entender la funcionalidad, estudiar los requisitos, comprender la lógica del negocio antes de poder explorar libremente el producto.

¿Es obligatorio un informe de errores después del testing exploratorio?

Sí. Cualquier defecto encontrado debe documentarse con tanto detalle como un error de un escenario formal, de lo contrario es difícil reproducirlo y corregirlo.

Errores comunes y anti-patrones

Desestimación de uno de los enfoques
Falta de documentación de errores encontrados durante el testing exploratorio
Desconocimiento de la funcionalidad del producto antes de comenzar la sesión exploratoria

Ejemplo de la vida real

Caso negativo

El equipo cubrió el lanzamiento solo con casos de prueba formales. Un tester ejecutó estos casos estrictamente según las instrucciones, sin comprobar los casos "adyacentes", lo que resultó en pasar por alto un error que aparece con una secuencia de acciones específica no prevista de antemano.

Ventajas:

Automatización rápida y sencilla de informes

Desventajas:

Insuficiente profundidad en la revisión
Falta de flexibilidad

Caso positivo

El tester, después de completar los casos de prueba clave, dedicó una hora al testing exploratorio y encontró un error que solo se reproduce al cambiar la hora en el dispositivo mientras la aplicación está en funcionamiento.