Orders Of Ignorance y el Testing Exploratorio

Cuando inicias una actividad de testing en si, tienes dos opciones:

1, dispones de una magnitud de conocimiento suficiente para asegurar que pronto estarás en el descubrimiento de bugs

2, dispones de una magnitud de ignorancia suficiente para solo permitirte aprender, es decir, reducir esa magnitud de ignorancia, por lo que no estás en condiciones de encontrar bugs

Si nuestra situación actual es la del punto 2, entonces nuestra actividad principal no es la de encontrar bugs, sino la de aprender para posteriormente encontrar bugs. Esto debemos tenerlo en cuenta principalmente para aprender a planificar el testing (el que sirve para encontrar bugs)


Un modo efectivo de acortar este proceso natural, es la de pensar en ambientes colaborativos de muy alta comunicación, principalmente cara-a-cara, y un enfoque muy poderoso es el del Testing Exploratorio.

Recordemos la premisa del ET (Exploratory Testing), que nos indica que “ET es abarca un proceso simultáneo de aprendizaje, diseño y ejecución de pruebas.”

Con ET encontrámos la manera de hacer shortcuts a nuestro orden de ignorancia, permitiendo decrecer indefectiblemente desde los niveles alarmantes de aislamiento, donde se intenta buscar el conocimiento en documentación imprecisa o incluso irrelevante para el testing en si mismo, hasta magnitudes aceptables de ignorancia, mermada gracias a interdependencia con otros roles (principalmente desarrolladores).

Con este enfoque ET, es posible resaltar la colaboración entre miembros del equipo y del producto, lo que se traduce a que ET es mucho más que una actividad específica del tester, sino más bien es una actividad guiada por el tester, pero altamente interdependiente del caracter colaborativo de la organización para facilitar la interacción en pos del descubrimiento de mejores escenarios de usos y sus exigencias.

El apoyo organizacional es inevitable para tener éxito en evitar errores típicos del testing tradicional, que están ligados justamente a órdenes de ignorancia que incluso, no permiten pensar en como disminuir la magnitud de ignorancia en una manera razonable, por cuanto trabajando como departamentos independientes, se exige a QA/Testing la planificación up-front del testing, junto con el diseño exaustivo de scripts de testing, aún cuando la magnitud de ignorancia es del tipo “ni siquiera se lo que no se”.

Sugested: http://c2.com/cgi/wiki?OrdersOfIgnorance

Advertisements

Testing Exploratorio Vs. Diseño de Casos de Pruebas?

La principal diferencia no radica en si eres un “Testing tradicional” o un “Testing Agile”, sino en el enfoque del proceso de testing que facilita el aporte de valor al proceso de desarrollo. Ese enfoque es el testing exploratorio, que se basa principalmente en algunos aspectos que son claves para el proyecto, como la velocidad de respuesta y la generación de pruebas de valor.

Velocidad de Respuesta

El primer criterio (velocidad de respuesta) tiene que ver con la prontitud de la ejecución de pruebas para detectar fallos de criticidad, para ello el equipo debe congeniar un muy alto grado de sincronizmo y apertura a la colaboración.

Quiero decir que no debemos trazar líneas divisorias que impidan que algo se pruebe lo antes posible (considerar Fail Fast). Esto a su vez facilita un aprendizaje acelerado y continuo a cerca de las features que se desarrollan, como también la detección temprana de oportunidades de cambio.

Otro valor agregado es que como testers nos volvemos especialistas en el producto y podemos servir mejor a múltipleas áreas, no solo a los developers del equipo.

La imagen de dumies en un automovil prototipo representa la posibilidad real de probar algo sin que esté finalizado.

Pruebas de Valor

La segunda característica (pruebas de valor) radica en la inteligencia puesta en testing, lo cual deja de ser una potestad de los “probadores”, sino que por la falta de líneas divisorias que mencioné antes, todos, inclusive clientes, son responsables y partícipes de esa inteligencia aplicada a las pruebas.

Esto es un buen fundamento que explica por qué NO nos dedicamos al diseño de casos de pruebas al principio, aún cuando fuera posible, sino al diseño de sesiones exploratorias, las cuales no las puedes diseñar con solo tener un documento requerimiento frívolo o solo historias de usuarios, únicamente es posible si interactúas con todo el team para detectar escenarios de criticidad.

No olvidemos que las pruebas exploratorias, no son un procedimiento sino un enfoque y nunca deberíamos poner en riesgo el primer criterio que mencioné (velocidad de respuesta).

Consideremos un par de detalles para justificar la no cración de casos de pruebas y si el diseño de sesiones exploratorias:
Crear un set de pruebas de sistemas al inicio nos resta la posibilidad de interactuar con los productos en sus fases mas temprana, por ende nuestro aporte es menor a cada día que se avanza sobre el desarrollo. Dicho en otro términos, mientras escribo no pruebo.

Quiere decir esto que nunca más escribiremos casos de pruebas funcionales?

La verdad es que la respuesta tiende cada vez más a NO, NO LO HAGAS!.

Cada vez que sea posible busquemos la forma de automatizar el proceso de pruebas funcionales y cada vez que no sea posible automatizar, escribamos pruebas funcionales por que en algún momento a lo largo de nuestro proyecto, normalmente antes de un release, deberíamos considerar correr pruebas regresivas desde el punto de vista del cliente (Aquí es a donde le pido cordura a los desarrolladores que sostienen que las pruebas de regresión bajo CI son suficientes y deberían bastar).

El asunto importante es que no releguemos nunca la posibilida de hacer pruebas funcionales de regresión antes de un release y para hacerlo, te lo aseguro, las sesiones exploratorias podrían no servirnos y si serían útiles casos de pruebas que hayamos diseñado (escritos o automatizados).

La imagen del dumie en un automovil finalizado representa la necesidad de probar tambien en este momento. Pero ojo! lo absurdo seria que este fuera nuestro único momento.

Y cuando diseñamos casos de pruebas?

Sugiero que deben surgir luego de haber corrido cada sesión exploratoria, es decir son la salida del proceso exploratorio y son alimentadas por la inteligencia puesta en el diseño previo de esas sesiones. Nuevamente, utilicemos la inteligencia para comprender que solo debemos escribir casos de pruebas significantes para conseguir dos cosas fundamentales, verificar con caminos normal que las funciones funcionan (valga la redundancia) en su ejecución normal y verificar que las funciones funcionan (valga la redundancia) cuando la ejecución es “fuera de lo normal”.

Pruebas exploratorias Vs. Pruebas aleatorias

En muchos de los proyectos en los que he liderado pruebas, ejecuté un gran volumen de pruebas exploratorias y recientemente uno de esos proyectos fue testeado netamente bajo pruebas del tipo exploratorio.
El grado de éxito en este proyecto fue muy importante y básicamente me permitió demostrar que esta técnica es particularmente útil en algunos contextos.

Lo primero que hice fue transferir al equipo el concepto de pruebas exploratorias y contrastarlas con las pruebas aleatorias. Así es que cuando hablo sobre pruebas aleatorias, me refiero a todas esas pruebas ejecutadas en un contexto de muy alto riesgo, sin un soporte de un marco definido, sin expectativas más que las de detectar defectos.  Una consecuencia de este proceso aleatorio, sería la imposibilidad de repetir escenarios concretos que nos permitieron detectar un fallo en particular.

En su contraparte, a las pruebas exploratorias  suelo ejecutarlas dentro de unos límites tolerables bajo una planificación estratégica del testing, con alcances delimitados, modelando los escenarios para el contexto, formalizando los ciclos y contemplando resultados esperados. De otro modo creo que promovería el caos en el Testing y lo diseminaría por todo el proceso de desarrollo. En otras palabras gusto de contar con ciclos controlados para la exploración.

Ciclos bien controlados implican análisis de los requerimientos, del entorno de ejecución para el uso final, del entorno de ejecución para pruebas preliminares a las pruebas de sistemas, del entorno de ejecución para pruebas de sistemas, para pruebas de campo (post-despliegues), conocimiento de las dependencias, de las entradas y salidas y los procesos.

No deberíamos confundir “Testing aleatorio” con “Testing exploratorio”, puesto a que lo segundo aplica cierta formalidad en la técnica, aún cuando es libre de tomar algún camino alternativo no calculado o no premeditado.

La aliatoriedad del Testing no necesariamente ampliará la cobertura de pruebas, de hecho es demasiado factible que los criterios de aseguramiento de calidad (criterios de aceptación, modos de fallos-modos de pruebas) terminen siendo extraviados al violar límites y alcances por no calcularlos de antemano. Inclusive corremos demasiado el riesgo de modificar lo que se construye, si es que no mantenemos controlado el resultado de las pruebas.

¿Debemos responder al cambio? si lo antes posible. Pero no se puede hacer con pruebas no planificadas, con aliatoriedad mandatoria. Afrontar los cambios será posible a partir de la obtención de experiencia en los sistemas que necesitamos probar y garantizar, y junto con esta experiencia obtenida crece la posibilidad de un Testing Exploratorio más conveniente que cualquier otro tipo de Testing.

La repetitividad es un elemento absolutamente necesario en las pruebas que propongo, pero no van de la mano con la construcción de los casos de pruebas formales, sino del diseño que antes expliqué y la comprensión de la evidencias de construcción y de otros cientos de elementos que deberían, primero ser llevados a un nivel de abstracción dentro del contexto de las pruebas (no la abstracción típica de los requisitos y sus análisis de sistemas) y luego ser bajados al nivel de la ejecución.

En este nivel podremos configurar los distintos contextos, ya traducidos a ciclos ejecutables (hasrdware+software+testing), donde la adaptación de las pruebas será extremadamente simple aún cuando se generan nuevas características para el mismo sistema.

En conclusión, para mi el diseño de pruebas para diferentes contextos de ejecución es posible y es preferible. Las pruebas planteadas en Casos de Pruebas no sirven salvo que hablemos de productos enormes y sin posibilidades de cambios a traves del tiempo.

Las pruebas aleatorias son sinónimo de pruebas sin planificación y sin conocimiento del impacto de los resultados, pero las Pruebas Exploratorias son el resultado del estudio y aplicación del sistema en el contexto adecuado.