Spring GDS 25 Aniversario
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
El exploratory testing es una prueba práctica e investigativa en la que el tester diseña y ejecuta casos en el momento, aprende de cada resultado y decide qué probar a continuación. No hay un guion escrito de antemano. El tester se apoya en lo que sabe del producto, de los usuarios y de cómo suele romperse el software, y sigue el rastro. Es curiosidad estructurada aplicada a encontrar los errores que nadie anticipó.
Esto contrasta con el testing guionizado, donde cada paso y cada resultado esperado se definen por adelantado y el tester se limita a ejecutarlos. Las pruebas guionizadas y automatizadas son excelentes para confirmar que el comportamiento conocido sigue siendo correcto. Son malas para descubrir lo desconocido, porque solo comprueban lo que alguien ya pensó en escribir. El exploratory testing cubre ese hueco. Un tester que toca una nueva función de reservas podría intentar reservar en el pasado, luego hacer doble clic en enviar y después cambiar de idioma a mitad del flujo, y destapar problemas que ningún requisito mencionó. Para que sea responsable y no caótico, los equipos suelen ejecutarlo en sesiones con tiempo limitado, una misión definida y notas de lo cubierto.
Premia la experiencia. Un tester sénior aporta intuición sobre dónde se esconden los defectos, y eso convierte una sesión libre en una sesión afilada. El exploratory testing no sustituye a las suites de regresión automatizadas; trabaja junto a ellas. La automatización protege lo que conoces. La exploración encuentra lo que se te escapó.
Tratamos el exploratory testing como el contrapeso humano de la automatización. Las suites automatizadas detectan regresiones rápido y barato, y nos apoyamos mucho en ellas. Pero solo comprueban lo que alguien ya imaginó. Por eso ponemos ojos con experiencia sobre las funciones nuevas, les damos una misión y un tiempo limitado, y los dejamos ir a buscar los problemas que ningún guion puede predecir.
Los hallazgos suelen ser los interesantes: el input raro, la secuencia inesperada, la suposición que nadie cuestionó. Cuando aparece algo real, no solo se corrige. Se convierte en una nueva prueba automatizada, para que el error siga muerto. Ese bucle, explorar y luego automatizar, es como mantenemos afilado el aseguramiento de calidad de un producto a medida que crece, en lugar de frágil.
¿Te preocupan los errores que tus scripts de prueba nunca pensarán en buscar? Vamos a cazarlos.
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
Convertir una marca en un negocio que funciona.
Medio millón de personas. Una app. Cero caos.















