"Exploratory testing is simultaneous lerning…

“Exploratory testing is simultaneous learning, test design, and test execution”

Esta hermosa frase me leventó el ánimo luego de haber ejecutado en forma manual una secuencia de TestCases diseñados en Testlink (una buena herramienta open source). Durante la ejecución no hice más que salirme de los caminos planificados e intentar alternativas que por mi intuición, sabía generarían un fallo.
Lo gracioso del asunto es que ciertamente, cada vez que me salía del plan, detectaba alguna anomalía y comencé a dudar del diseño de TestCases.

Esto tiene cierta lógica, ya que quien diseña un plan de prueba naturalmente tiende al enfoque conservador orientado a la comprobación del correcto funcionamiento del software, similar a la postura del desarrollador y poco orientado a la “destrucción creativa” que propone un buen testing. Esta actitud nos propone diseñar pruebas en las cercanías de “el camino feliz” y respondiendo al juego de datos que normalmente haría que la aplicación tuviera un desempeño natural y eficiente.

Un enfoque de “destrucción creativa” basado en técnicas exploratorias, podría incluir un juego de datos poco convencional y alternativas de uso no contempladas, ni aún en los planes de testing más abultados.

La debilidad se centra en la mentalidad del diseñador

Independientemente de si un plan se aplican pruebas exploratorias o se ejecutan scripts de pruebas, surgen problemas comunes a ambas técnicas cuando un incorrecto diseño rige el proceso de testing:

  • Uno podría ser la merma de creatividad en el acto de ejecución
    • en consecuencia la pérdida de enfoque para la detección de fallos  y aumento del enfoque que busca la confirmación del funcionamiento.
  • Las extensiones de las pruebas no corrigen un mal enfoque inicial
    • aún si garantizo la repetibilidad de los casos y aún teniendo la facultad de ampliar el diseño original, si el diseño original es trivial, mal enfocado o demasiado restrictivo, las ampliaciones solo serán una ampliación del error.
  • Aplicar técnicas exploratorias sin consensos (fuera del plan) equivale a aleatoriedad y es malo
    • por lo tanto se manifiestan los desvío en las ejecuciones de modo tal que resultados aleatorios se presentan y aunque pueda detectar mayor cantidad de defectos, se pone en riesgo la naturaleza de los objetivos centrales del plan, la repetitividad y la rastreabilidad.
    • adiciono también la aparición de la necesidad de análisis por cada defectos detectado, por el solo hecho de explicar el contexto de detección donde se manifiesta el fallo.
    • indudablemente aumenta el riesgo de desviación de los tiempos de ejecución del plan.

La cobertura corre el mayor de los riesgos

Este enfoque se presenta con tanta frecuencia en planes convencionales que aquí es donde propongo la creación de planes que permitan la aplicación de técnicas exploratorias.

Antes que nada tengamos en cuenta que las técnicas exploratorias, se caracterizan por ser unscripted e improvisadas pero en un contexto especial, por lo que no es posible que cualquiera de los recursos afectados al testing pueda beneficiarse de este contexto, sino aquellos que tienen amplia experiencia en el aprendizaje, una gran intuición y gobiernan el ámbito general del sistema y los negocios afectados.

Particularmente, solo me he permitido utilizar testing exploratorio en casos donde tengo la garantía de otros colaboradores ejecutando “testing tradicional” y me asigno tiempo en los planes para actuar como un satélite que ejecuta “pruebas libres” como motor de ampliación de los caminos diseñados en los planes.

Muchos me han dicho que la ejecución del testing de manera exploratoria la puede ejecutar cualquiera, pero lo interesante es cuando se puede explicar el contexto y el modo de ejecución lo más detalladamente posible sin perder el hilo. Conseguir que lo intangible se transforme en tangible con solo la explicación verbal, excluye a la mayoría de los testers y managers.

Por esto mismo pienso que lo ideal es cuando se logra pasar a un punto donde las técnicas de diseño tradicional se mezclan con las bases del testing exploratorio y aun cuando ambas parezcan contradictorias, en realidad “lo que se establece es un juego de expectativas” que solo nos indica que tipo de trabajo debemos hacer, pero no da más detalles que solo aquellos que proveen la garantía de un excelente marco para el diseño.

Como líder de testing, siempre he querido ser quien más conoce de cada producto, sus características y sus comportamientos, pero no estár restringido a caminos normales y alternativos diseñados en base a otra documentación. Como tester, siempre tuve la intención de ser limpio en mis ejecuciones y facilitar la registración de nuevos caminos posibles.

La ambiguedad esta presente en todo pero hay que saber lidiar con ella. En este marco, creo que este enfoque es ideal, pues propone agilidad y creatividad sin la pérdida de exactitud, repetición y rastreo.

Lectura sugerida: Session-Based Test Management (A method for measuring and managing exploratory testing)

Advertisements