– Post escrito por María Morales (@MaMoralesMC) y Noemí Navarro (@nnsanchez92).
Hace más de un año ya se explicaba por el blog el Testing Exploratorio (os dejamos el enlace aquí) y luego se ha ido mencionando y haciendo referencia al mismo en diferentes posts.
Para empezar, decir que tanto el software como el Testing lo hacen personas, no máquinas, por lo que no todo se puede automatizar y hoy nos vamos centrar en ese Testing que no se automatiza, el Testing Exploratorio.
Si recordáis los posts sobre las escuelas de Testing explicaban que el Testing Exploratorio es una de las prácticas claves en la escuela Context Driven, donde se centran en la importancia de las personas en el Testing, y el contexto de la prueba.
Nos hemos decidido a profundizar más en el tema.
¿Qué es Testing Exploratorio?
El Testing Exploratorio es un enfoque para la realización de pruebas de software. Su principal característica es que el aprendizaje, el diseño y la ejecución de las pruebas se realizan de forma simultánea.
El término Testing Exploratorio apareció por primera vez en www.StickyMinds.com. Según un artículo de Satisfice Inc escrito por James Bach (creador del Rapid Software Testing entre muchas otras cosas), el Testing Exploratorio se considera un enfoque divertido y a la vez poderoso, ya que puede ser más productivo que otro tipo de Testing.
Aunque se utiliza realmente poco, tenemos que tener claro que es una gran ayuda, ya que empleamos pensamiento científico y lo más importante en tiempo real.
James Bach nos cuenta que el Testing Exploratorio no se define por ningún ejemplo específico, es decir, no hay ningún patrón a seguir para utilizar Testing Exploratorio. No pasa nada porque no hagamos bien Testing Exploratorio al principio, porque siempre nos será valioso ya que encontraremos algún error y aprenderemos evolutivamente sobre ello.
A lo largo del tiempo, el Testing Exploratorio se ha definido de muchas maneras, pero básicamente se reduce a: diseño y ejecución de pruebas y aprendizaje que no son mutuamente excluyentes, sino que sirven de apoyo mutuo.
A continuación vamos a explicar la evolución y las etapas por las que ha pasado el Testing Exploratorio (podéis leer más de las etapas en este artículo).
Testing Exploratorio 1.0 – La Rebelión
Las pruebas con y sin un guión (James Bach le llama Script en sus explicaciones pero nosotras nos vamos a referir como guión durante el post) son diferentes experiencias. Cuando se hacía Testing Exploratorio con un guión se descubrió que si se salían del guión la calidad de las ideas y de las pruebas era mejor, así como la cantidad de los errores encontrados aumentaba.
Por lo tanto en siguientes sesiones lo que se hizo fue centrarse más en el producto y no tanto en el guión y en la interacción con el producto para encontrar errores, se dieron cuenta que el Testing Exploratorio no es tanto una técnica y una actividad, es una buena idea como punto de partida, pero no como punto de vista para llevar a cabo Testing Exploratorio.
El Testing Exploratorio 1.0 empezó a desaparecer en 1995 según James Bach, donde solo unas cuantas personas intentaban llegar a cabo Testing Exploratorio, pero no fue suficiente. Veamos que ocurrió después…
Testing Exploratorio 1.5 – La Explicación
El grupo de testers formado por James Bach y más personas como veíamos antes comenzaron en América del Norte (con el tiempo formaron la comunidad de Contexto – Driven) proponiendo dos líneas de investigación:
- Una con un enfoque “humanista” de la mano de Weinberg (quizás le recuerdes de los siguientes post Entendiendo las diferentes escuelas de Testing, imprescindible para entender las diferentes (a veces enfrentadas) visiones del Testing hoy (2/2) o de Enfoques “sin ego” y que si en tu equipo existe la cultura de otro vea el trabajo que has hecho) es decir teniendo en cuenta la psicología de las personas en la ingeniería del software.
- La otra línea de investigación era defendida por Cem Kaner estaba vinculada con la ciencia cognitiva.
Estas líneas ayudan a cuestionar la forma de hacer Testing hasta el 2015, debido a que la comprensión de las pruebas iba evolucionando.
Fue en 1995 cuando James Bach participó por primera vez en el desarrollo de pruebas de software y empezó a colaborar con Cem Kaner. Además empezaron a comparar y contrastar las estructuras importantes del Testing Exploratorio con y sin guión y las relaciones entre ellos, en lugar de verlos como actividades.
En 1996, James Bach creó la primera clase de prueba llamada “Pruebas Exploratorias”. Había estado diseñando patrones de pensamiento y tratado de incorporar eso en la clase.
En 1999 James Bach definió un proceso formalizado de Testing Exploratorio para Microsoft. La idea de un proceso formal ad hoc les llevó a él y a Cem Kaner a diversos debates, lo que da lugar a Testing Exploratorio 2.0.
En el año 2000, inspirado en el trabajo de Microsoft, James Bach y Jon Bach desarrollaron la “Gestión de Pruebas basadas en una sesión” (hablaremos en post posteriores sobre ello) para Hewlett-Packard, con el objetivo de crear un mayor rendimiento en la exploración de las pruebas.
SBTM, con intención de defender el Testing Exploratorio, tuvo bastante éxito en ayudar a la gente a reconocer que el Testing Exploratorio era totalmente eficiente y adecuado.
Hacia el año 2000, la mayor parte de la gente del mundo ya había oído hablar del Testing Exploratorio, empezaban a hacer el mundo del software algo mejor con las pruebas.
Para terminar…
Para que este post no se hiciera muy largo, en la segunda parte del post, hablaremos del Testing Exploratorio 2.0 y 3.0. Además dejaremos una imagen resumen con todas estas fechas y evolución del Testing Exploratorio. ¡Esperamos que os sea de interés!
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Recientemente he publicado un libro «How to trap a bug: Best practices for top bug hunters» en Amazon que esta muy relacionado con el Testing exploratorio como base de pruebas. El libro es un manual de buenas practicas de QA basado en mi experiencia personal como tester y manager de pruebas.
https://www.amazon.com/How-trap-bug-practices-hunters/dp/1536824593
Curioso enfoque, no lo conocía, espero las siguientes partes.