"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)

2 thoughts on “"Exploratory testing is simultaneous lerning…

  1. Javier,

    Muy buen post!!! Es un buen resumen de la escencia del ET lo cual creo que mientras mas se oriente a trabajar en metodolias agiles mas se va a aplicar el Testing Exploratorio ya que van totalmente de la mano.

    Una consideracion que me gusta hacer al momento de hablar de ET es que el mismo no es solo agarrar la aplicacion un rato a ver que pasa, requiere de estar concentrado en lo que probamos y ser muy creativos, sin caer en la repetición de las acciones que realizamos ya que se reducirian las probabilidades de encontrar nuevos errores. Por lo que he visto y realizado el pilar fundamental de esta practica es la experiencia, ya que como decis al inicio tu intuicion te llevo a probar ciertaas cosas que por experiencia en la tecnologia o negocio sabes que puede fallar….

    Saludos,

    José Pablo Sarco

    • Lo que comencé a utilizar un tiempo atrás es algo muy parecido al SBTM (Session-Bassed Testing Management) lo cual me ha servido mucho a la hora de ser aplicado con los resultados obtenidos, sobre todo cuando eventualmente permitimos que un proyecto completo se testee de manera exploratoria.
      Cierta vez expuse ante los chilenos amigos de CHILEAGILE, que dirigí el testing exploratorio planificado para un proyecto de dos iteraciones. El proyecto fue uno de los que mejor testeados, por la velocidad de nuestras respuestas, el foco del equipo, la interacción y colaboración lograda y sobre todo las oportunidades de mejoras a partir de nuestras observaciones, lo que hicieron que desde el managamente de USA bajaran felicitaciones y pedían que repitamos lo que nos hizo avanzar tan bien y tan rápido.
      Para mi fue un hito del testing de nuestra organización, sin embargo muy pocos apreciaron esto y desde el top-management, dado los mismos criterios agilistas, se atribuyó al foco de todo el team, lo cual es válido.
      Pero sabes? hay un problema con esto, es dificil de explicarlo y hay poco interés por aquello aún desconocido o que no es empíricamente demostrable, por eso me ayudé con SBTM y allí conseguí que esto se pudiera repetir, aunque aún tengo algunos problemas para que sea una metodología aprobada o algo por el estilo.

      Saludos, Javo.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s