Manual (Exploratory) Tester is not dead at all…

“My team (Pivotal Tracker) is looking for an exploratory tester. We are based in Denver, and I think we have about 25 people total on the team. It’s a really nice environment with great people. As with the rest of Pivotal Labs, we use XP practices such as pairing, TDD, and automating tests at all levels. We’re doing some exciting experiments to improve our ability to build quality in. For example, we’re automating all of our build and deployment processes, moving towards continuous delivery. We’re also starting to use story workshops and BDD (automated with Cucumber and Capybara) to guide development at the acceptance test level.”

Así es como inicia uno de sus post la muy famosa Lisa Crispin en el grupo público de Yahoo “Agile Software Tester”.

En ésta porción de texto nos muestra lo grandioso de su entorno de trabajo, donde lo más destacado es el “gran grupo de profesionales” que conforma su equipo de aproximadamente veinticinco (25) profesionales.
También nos cuenta que mayormente sus prácticas, como las del resto de la empresa, son del estilo XP (Extreme Programing) entre las que destaca trabajo en pares, TDD (Desarrollo Dirigido Por Pruebas, según siglas en inglés), automatización en todos los niveles :O lo que incluye la generación de sus paquetes de software (builds) en un esquema de Entregas Continuas (Continuous Delivery).

Además al parecer han encarado algunos “experimentos” con el objeto de mejorar la calidad en el proceso de desarrollo, aunque le anteceden técnicas para mejorar los contenidos y comprensión de las Historias de Usuarios, tales como “story workshops”. Inclusive han incorporado Desarrollo Dirigido Por El Negocio (BDD) utilizando algunas conocidas herramientas de automatización como Cucumber y Capybara, para conseguir un desarrollo orientado por Testing de Aceptación (AUT).

Como podrán ver, es un entorno ideal de trabajo donde las técnicas están “en la ola de la cresta” y no dudo de que se encuentren al mismo nivel las prácticas agilistas.  Los productos que desarrollan detrás de Pivotal Tracker son sin dudas innovadores y están entre los mas requeridos al rededor del mundo, así que no puedo menos que imaginar que la fuerza de conocimientos tecnológicos y el grado operativo están también en una máxima expresión.

El artículo de la señora Crispi continua diciendo:

“We need a tester who not only rocks at exploratory testing, but knows how to teach others (mainly programmers) some exploratory testing skills. The developer pairs are trying to do some exploring before they mark a story finished, but there are so many of them and only two testers right now. Our goal is that with BDD/ATDD, and the developers doing some exploring too, there will be more time for testers to do exploring at a more end-to-end level.”

En éste pedido en particular, no están buscando un nuevo desarrollador con habilidades única en un lenguaje o framework, ni un arquitecto de software eximio que establezca las bases tecnológicas, ni un experto consultor (ellos deben serlo todos) que determine los lineamientos de un proceso para trabajo Agile. No han mencionado tampoco  a un experto analista de negocios (BA) o dueño de producto (PO) para fortalecer la cadena de valor de ideación o gestación del producto, como tampoco se habla de un experto automatizador de pruebas.

Si ya sé, la página de ofertas laborales de Pivotal seguramente están todos o algunos de esos pedidos, de acuerdo, pero eso al menos lo podemos suponer todos, verdad? Lo realmente interesante es que en una de las empresas más conocidas del planeta están pidiendo un Exploratory Tester, algo a lo que en nuestra industria realmente no estamos acostumbrados.

Si son observadores en el posteo de Crispi, el pedido además de ser cordial y convincente, también es muy claro en varios aspectos a los cuales no debemos dejarlos pasar por alto:

“We need a tester who not only rocks at exploratory testing, but knows how to teach others (mainly programmers) some exploratory testing skills.”

Esta persona en particular tendrá un interesante y duro desafío al intentar explicar el enfoque del Testing Exploratorio a desarrolladores. Aunque ella (Lisa) lo expone como algo simple, liviano y muy “al paso” … “…to teach others SOME exploratory testing skills”, estoy seguro que quien tome este empleo, deberá extender sus conocimientos y habilidades a escala empresarial.
Seguramente Lisa sabe a que se enfrenta este postulante, por cuanto éste enfoque no es algo simple ni liviano, ni se aprende sin esfuerzo de la noche a la mañana, muy por el contrario tiene un sin número de particularidades que lo hacen complejo y difícil de implementar con éxito. Por un lado requiere de “practicantes” con una base conceptual importante “fuera de los estándares del testing tradicional”, pero también es necesario un absoluto apoyo de la empresa en todos los niveles.

“The developer pairs are trying to do some exploring before they mark a story finished”

Quien no ha notado que las Historias de Usuario usualmente son entregadas con un estado de “hecho” (done) dudoso, y que finalmente el ciclo de desarrollo se extiende hasta el final de Sprint tratando de resolver los defectos y errores que solo se detectaron en las pruebas de sistema?
Claramente la señora Crispi transparenta aquí una de las debilidades de casi todas los equipos que juegan a XP delimitando la participación de los Testers a fases tardías como en Waterfall.

 but there are so many of them and only two testers right now

O bien puede ser que el tan alto y preciado nivel de aplicación tecnológica les hace pensar que se necesitan menos personas en el proceso de desarrollo y por ello “recortaremos Testers”

Our goal is that with BDD/ATDD, and the developers doing some exploring too..

y “eventualmente sumaremos a algún tester”, pero esperamos que desarrollo tenga tiempo de hacer sus propias pruebas de integración garantizando algún flujo mínimo que de cierta cobertura antes de hacer “committ”.

…there will be more time for testers to do exploring at a more end-to-end level.”

porque actualmente no estamos llegando a hacer pruebas punto-a-punto y nuestros testers no logran hacer pruebas completas en los distintos flujos de negocio, ya que deben hacer sus pruebas en los puntos intermedios, revisar los datos para múltiples tipos de usuarios y sus accesos, más sus acciones posibles según los roles, analizar datos en las bases, chequear cambios de estados y trabajar contra servicios web de terceros.
La Hiper-super-archi automatización de las pruebas no son suficientes y el cliente se ha quejado tantas veces de que nuestro producto falla en algunas acciones complejas, o en los resultados mostrados, que exige que seamos mucho más cuidadosos en el análisis y en las pruebas.

Finalmente todo esto por supuesto y como es costumbre, es percibido como un “Issue de calidad” (de la vieja y nunca bien amada “área QA”), pero no asumiremos que necesitamos más testers analistas (los famosos “manual testers”) insertos en el proceso y menos herramientas intentando suplantar la inteligencia del ser humano.

You have a passion for customer-focused web & mobile apps, and discovering interesting interactions and side effects. You know good testing isn’t about quality gates that hold back releases, but about sharing information and helping to release faster and with more confidence. Whether you know how to code or not, you find you have the most fun testing. You are sharp, curious and enjoy exploring the dark corners of complex software. You judge your success by customer feedback and the success of your team, not how many problems you find. You enjoy collaborating closely with other team members.

Claro, los grandes volúmenes de datos dan una sensación de velocidad y cobertura y las enormes cantidades de horas insumidas en generación de estos frameworks de automatización y su mantenimiento, sumado a las horas de generación de las pruebas automáticas, nos dan la idea de que lo estamos haciendo bien y así muchas cosas menos podrían fallar.

Lo cierto es que haciendo cierto tipos de lecturas (totalmente sesgadas por supuesto) de éste pedido de Pivotal Tracker, podremos deducir que el Tester analista debe ser un practicante del Testing Exploratorio, que el Testing no puede ser ejecutado por herramientas o robots, que no cualquiera puede hacer Testing… pero lo que más me agrada de haber leído éste pedido en particular, es que puedo concluir que simplemente el Tester no ha muerto.

Advertisements

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

Exploratory Testing: Olfato e intuición amplificada

Fortalezas y debilidades de las Pruebas Exploratorias

Muchas veces se habla del Testing Exploratorio sin tener una verdadera conciencia de lo que se trata ni del modo en que se debe ejecutar. Los detractores de este tipo de verificaciones, opinan mostrando la práctica como informal, sin procedimiento y fuera de los cánones del Testing y por transferencia intentan establecer que no existe Calidad del Software.

Les doy la razón únicamente en que este tipo de pruebas del software no están en los cánones del Testing, puesto a que es una actividad extremadamente compleja de interpretar y realizar si no se tienen en cuenta los elementos de soporte que finalmente avalan la práctica.

Las pruebas exploratorias muestran sus resultados y garantías en base a los resultados y garantías de prácticas previas y del mismo modo, fallan sus resultados y garantías cuando prácticas que le anteceden son ejecutadas en forma endeble o imprecisa.

Para esta práctica son necesarios ciertos elementos que le anteceden:

  • Conciencia de que todo lo que se verifica está orientado a la detección de problemas que impidan satisfacer requisitos funcionales y no funcionales
  • Capacidad de análisis elevado para entendimiento cabal de requisitos en base a la observación y análisis de la evolución de los mismos
  • Abstracción para la elaboración de circuitos de pruebas de verificación y validación
  • Capacidad de ampliación de caminos de pruebas para mejora espontánea de la cobertura
  • Conocimiento y dominio del negocio al que pertenece el problema
  • Alta proactividad y gran capacidad comunicacional para generar ambiente colaborativo
  • Conocimiento cabal del proceso que rige para reconocer las fallas que se manifiestan en los resultados no deseados
  • Gran capacidad para definir y variar las estrategias, tácticas y técnicas de validación y verificación
  • Olfato e intuición amplificada

Hay que considerar que para el éxito de esta técnica se utilizarán las definiciones que se hacen a nivel de Historias de Usuario y/o Requerimiento,  para verificar mediante pruebas exploratorias (sin script), que el sistema esté haciendo lo que se solicita y se ampliará el grafo de pruebas para verificar que el sistema no haga lo que no debe hacer.
Es decir que básicamente la información disponible conforman nuestros Scripts de ejecución y también evidencia de funcionalidad.

Según este tipo de proceso de verificación y validación, las evidencias de funcionamiento se deben dar inicialmente en la fase de desarrollo y manifestarse en las diferentes integraciones de los sistemas, más no pretender que las pruebas exploratorias indiquen que las funciones del sistema funcionen correctamente, sino entender que el concepto es en si mismo, la detección de fallos y errores.

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”.

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

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.