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.