Introducción al Testing: Pruebas Exploratorias para ser ágiles

En entornos de DevOps, se están adoptando, progresivamente, pruebas exploratorias. Estas, se adaptan muy bien a esta filosofía y al trabajar de manera tan flexible, nos permite tener cierta garantía en despliegues muy rápidos.
 

 
El problema que tenemos con este tipo de pruebas, es que, a veces no sabemos como realizarlas correctamente o de manera eficiente.

El primer paso es estructurarlas, si nos centramos únicamente en caminos felices, el resultado será muy pobre y si, por el contrario, nos enfocamos en ampliar la cobertura, el tiempo, nos puede ganar la batalla y nos ser óptimas.

Una estructura lógica para realizar pruebas exploratorias es la de utilizar la criticidad de los módulos para la compañía, comenzando a probar lo más crítico, ya que, de esto, dependerá el negocio y los ingresos de la misma.

Si la funcionalidad crítica y más “económica”, funciona correctamente, al menos, salvamos los ingresos empresariales y los usuarios seguirán utilizando la herramienta en su capacidad “inicial”, por lo tanto, podría ser una buena estrategia.

En el caso de entornos puramente de desarrollo, este tipo de pruebas se llevan la palma, ya que son las más sencillas de realizar y son las que pueden decidir que un evolutivo está listo para desplegar. Lo malo, es que se suelen hacer sin estrategias ni técnicas de diseño de pruebas o cobertura y esto genera que aparezcan puntos ciegos y regresiones inesperadas en producción que pueden ser demoledoras. También, tenemos el ejemplo de las pruebas de integración, en las que, se suele tender a probar el camino feliz y el resultado, vuelve a ser muy pobre si no se estructura correctamente. 

También, tenemos diferentes problemas a la hora de realizar pruebas de UAT o de aceptación en la que los clientes realizan una caza de defectos, pero no se estructuran las pruebas adecuadamente y son muy poco eficientes. Esto, por ejemplo, nos pasó en un proyecto no hace mucho tiempo, los tiempos de pruebas eran escasos, no había una buena estructura de desarrollo y los directores del proyecto no habían decidido ni gestionado ningún tipo de estrategia, solo estaban centrados en facturar y facturar, por lo tanto, el proyecto fue un completo desastre. Evidentemente, la culpa de todo el desastre era de las personas de desarrollo y de testing, cosa muy lejana de la realidad, pero es lo que suele suceder. Al final, el jefe de proyecto, hizo una labor espectacular y mano a mano, decidimos crear una estrategia de pruebas de UAT y se hizo una batida de pruebas muy completa que permitió poner el software en producción con bastante garantía y el proyecto dio la vuelta completamente, tras ello, lo que suele suceder, los directores del proyecto se colgaron la medalla y lo celebraron por todo lo alto (qué tire la primera piedra a quien no le haya pasado esto en algún momento).

Con este tipo de situaciones, debemos de mantener unas estrategias de pruebas exploratorias estructuradas, para que, al menos, podamos mantener cierta integridad y garantía a la hora de poner algo en producción.

El primer paso, evidentemente, es ayudar a realizar mejores requisitos. Desde QA, debemos de dar las pautas y formar a las personas para que los requisitos cubran las necesidades de todo el mundo. Que sirvan para realizar unos buenos casos de prueba y para que el cliente, pueda comprobar y verificar lo que se le va a entregar, teniendo toda la información de la mano.

El segundo paso es hacer una evaluación o un análisis de posibles riesgos en el producto, tratando con todas las personas del equipo y que pusieran encima de la mesa los diferentes puntos ciegos que viesen para cubrirlos con anexos a los requisitos o a la documentación que se utilice.

Otro punto que debe de realizarse es hacer pequeños listados de cosas críticas o importantes que deben de probarse, incluyendo caminos felices y posibles casuísticas no contempladas a simple vista. Un extra en este punto, es el realizar guionesdetallados en módulos complejos del producto, esto le da a todo el equipo, una seguridad enorme.
Estos documentos e información, se pueden utilizar como mapas mentales, ahorrando tiempo y esfuerzo a todas las personas.

En estos casos, las pruebas, las suele hacer el tester, pero con esta documentación, se pueden realizar por cualquier persona. Esto, genera una serie de informes con datos y resultados que se pueden utilizar para saber que probamos y que no probamos en los siguientes evolutivos, tratando de eficientar cada segundo de las personas dedicadas a estas labores.

Como podéis observar, esta estrategia está definida, según habíamos hablado antes, sobre la criticidad de los módulos y no es algo cerrado ni fijo, pero nos ayuda con un guión que puede ser todo lo flexible que queramos y se puede adaptar a cualquier momento o situación.

Una vez tenemos estas partes definidas y funcionando, ya podemos ir introduciendo otras etapas, como la automatización en dispositivos móviles, por ejemplo.

Con todo lo realizado anteriormente, se van captando las pruebas que hemos lanzado, capturando las más críticas, ya que, si no, el tiempo de realización, mantenibilidad y ejecución puede ser demasiado alto y costoso, y el retorno de inversión bajaría considerablemente, no mereciéndonos la pena.

La idea, es capturar un pequeño número de pruebas, con una cobertura amplia basándonos en la criticidad y adaptándonos a un “presupuesto” que hayamos estudiado anteriormente. La ventaja de automatizar esta pequeña lista, es que los evolutivos o despliegues, se pueden garantizar bajo diferentes situaciones y la confianza que genera a todas las personas irá en aumento.

Si conseguimos que esto sea factible, el presupuesto se irá ampliando y evidentemente, la garantía será mayor y conseguiremos automatizar, prácticamente todo.
Una vez que realicemos este tipo de pruebas estructuradas, vamos a aprender una serie de cosas, como, por ejemplo:

·      Aprender a que la estrategia de pruebas debe de ser flexible, preguntándonos que hay que probar, que es más crítico y actuar en consecuencia.

·      Utilizar técnicas de diseño y cobertura adecuadas. Cada proyecto, es un mundo y en base a la utilización y los módulos que sean más críticos y que nos generen ingresos directamente, nos deberán de dar el punto de partida para realizar toda la estrategia en torno a ellos.

·      Otro punto, que, aunque yo sea un loco de la documentación, en este caso, es muy factible, es no dedicar mucho tiempo a ella, si no que se deben de realizar mapas mentales que generen una documentación más liviana.

·      Y otro punto, aunque ahora no estará del todo bien visto, es que la automatización no es la respuesta a todos los problemas. En ocasiones, nos puede generar más de los que resuelve. Hay que seguir haciendo estrategias híbridas ya que muchas herramientas no cubren todas las casuísticas ni pueden probar todos los sistemas.

·      Y como punto final, podríamos decir que las pruebas son un oficio independiente y acotado. Una cosa es que desarrolladores y otras personas ayuden y apoyen a realizar pruebas, pero una persona de QA aportará una garantía y una excelencia, que lamentablemente, nadie más puede aportar (al igual que las otras personas de los otros oficios). Organizaciones que piensan que QA somos todos y que cualquier puede hacer pruebas, a corto plazo, se la acaban pegando.

Con esta serie de pautas, ideas y organización estructurada de pruebas exploratorias, podemos comenzar a implantar una muy buena estrategia en nuestra empresa y así, garantizar mucho más cualquier puesta en producción.