Las trampas de la automatización de pruebas
Automatización, cortada en lonchas finas
No se puede negar que la automatización de pruebas ha revolucionado las pruebas de software. ¡Y justo a tiempo! En el mundo actual de servicios ultra distribuidos, contenedorizados y en continua actualización, unas pruebas de software significativas serían imposibles sin ella.
Tenemos la suerte de contar con tantas herramientas sofisticadas de pruebas automatizadas a nuestra disposición. Y, no menos importante, con ingenieros de QA bien formados para utilizarlas en beneficio de todos durante el desarrollo.
Sin embargo, por alguna razón, en nuestra industria es habitual reducir avances tan significativos en capacidad a modas pasajeras, y estas modas a insulsas combinaciones de palabras y eslóganes que son repetidos robóticamente por altos directivos, gurús y consultores que solo buscan una excusa para dejar de pensar en el problema. O para hacer dinero rápido.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Así ha sucedido con los avances en la automatización de pruebas, que rápidamente han sido atrapados por la narrativa reductora de: “¡solo necesitamos automatizar todas nuestras pruebas! ¡Ahora mismo! ¡Y todos nuestros problemas de pruebas quedarán resueltos!”
No solo es una pésima idea, incluso si la proponen personas que intentan tomarse el problema en serio y no simplemente evitarlo. Además, resulta perniciosa porque es una narrativa que, al descartar la oportunidad de pensar en profundidad sobre cómo integrar la automatización en los esfuerzos de prueba, garantiza su fracaso. Y es injusto para todas las personas (incluyendo clientes) que dependen de su éxito.
En este sentido, la automatización de pruebas simplemente hereda una situación especial del enfoque general hacia el SQA por parte de quienes no lo entienden, ni quieren entenderlo. Se trata como una mercancía a granel, no como una experiencia compleja. Por eso las personas de QA siguen escuchando de la alta dirección: “¡solo necesitamos más QA!”, como si existiera una charcutería de software donde se pudiera pedir por kilo, cortado en finas lonchas.
Por eso, ahora el mantra es “¡solo necesitamos más automatización!” sin pensar realmente en lo que eso implicaría en el contexto de los esfuerzos de desarrollo de software. Como tal, este discurso alimenta las disfunciones de tu organización. No las soluciona.
Intentar resistirse directamente a estas tendencias pasajeras es como intentar impedir que salga el sol. O, en este caso, que se ponga. La mejor forma de oponerse es asentir y sonreír ante los vicepresidentes y consultores, volver a tus cubículos, averiguar la forma adecuada de hacer la automatización y después presentar esas ideas como el brillante resultado de la imaginación de tus jefes. Pero probablemente ya hayas aprendido esa lección con otros temas.
Así que hagamos justo eso. Aquí está mi lista de escollos al implementar la automatización de pruebas, y formas de mitigarlos, para que la automatización pueda cumplir su gran promesa en tus propios esfuerzos de pruebas.
Alcance de la automatización
La pregunta más importante que hay que responder al principio es dónde la automatización de pruebas ofrece el mejor retorno por la inversión en tus esfuerzos de pruebas. Tomarse el tiempo para analizarlo te ahorrará muchos, muchísimos dolores de cabeza más adelante.
Responder a esta cuestión se reduce a saber cuánto de tus pruebas deben automatizarse y cuánto debe seguir siendo manual. Esto puede sorprender a quienes reciben constantemente el evangelio de “¡automatiza todas las pruebas!”. Pero no hagas caso a esas tonterías, esas personas no tienen idea de lo que están diciendo.
Automatizar todas tus pruebas - suponiendo que esto sea siquiera posible - sería una decisión desastrosa que solo podría conducir al fracaso de tus esfuerzos de pruebas.
Hay cosas maravillosas que la automatización puede hacer y que la prueba manual no puede, o al menos no de forma tan rápida y repetitiva. Pero también ocurre lo contrario. Hay cosas que sólo las pruebas manuales pueden hacer bien y que la automatización no puede. ¿Cuáles son esas cosas en cada caso?
Donde más destaca la prueba manual frente a la automatizada es, sencillamente, en el factor humano. El beneficio de contar con una persona realizando con paciencia pruebas exploratorias profundas simplemente no se puede duplicar con la automatización. Y no hablo solo del descubrimiento de errores.
Cualquiera puede encontrar errores. Los clientes lo hacen gratuitamente todo el tiempo. El valor que aporta un profesional de QA es ese sentido intuitivo de cómo romper un software, especialmente en cuanto a identificar cómo los clientes pueden utilizar el software de formas para las que no fue pensado, y que sin embargo —a menudo con resultados catastróficos— pueden hacerlo.
Otra ventaja de la prueba manual es que, tras encontrar un fallo, el tester manual puede determinar de inmediato su alcance y gravedad. Es decir, puede acotar directamente los contextos de prueba (sistemas operativos, flujos de trabajo, interacciones y dependencias entre servicios) donde se manifiesta específicamente y aquellos donde no lo hace.
Los scripts de prueba automatizados no pueden hacer esto con eficacia y, desde el punto de vista del ingeniero de software, esta es precisamente la información crucial que necesita para diagnosticar y corregir cualquier bug. Un reporte de errores que solo indique "Hice esto y ocurrió algo malo" no les sirve de nada.
De hecho, la prueba manual es mucho más eficiente al proporcionar esta información y, por ser intrínsecamente interactiva y estar en el momento con el equipo de ingeniería, resulta también mucho más rica en retroalimentación y análisis de causa raíz.
Sí, Virginia, la prueba manual no siempre es la forma menos eficiente y más lenta de encontrar, diagnosticar y corregir errores, y validar (o no) sus soluciones.
Sin embargo, donde la automatización tiene una ventaja obvia es en las pruebas continuas de tiempo de actividad y estabilidad, especialmente para sistemas distribuidos. Esto es algo que ahora es mucho más central dado nuestro contexto actual de desarrollo, con integración y despliegue continuos en entornos distribuidos en tiempo real.
La automatización también es más eficiente en lo que podría llamarse “pruebas masivas”, donde se debe cubrir una enorme matriz de miles de condiciones del sistema y sus variables para ver si alguna de ellas está completamente rota o puede hacer que el sistema colapse.
La regla básica que debes usar para guiar tus diseños sobre dónde priorizar las pruebas manuales o automatizadas es la siguiente:
Por lo general, se prefiere la prueba manual para las pruebas iniciales de nuevas funcionalidades y capacidades. La prueba automatizada es claramente la mejor para la regresión general continua, así como para pruebas de carga y rendimiento.
A lo largo del ciclo de vida de un producto o servicio, las pruebas de la misma capacidad deberían evolucionar de manuales a automatizadas. Es un continuo en el ciclo de vida de la capacidad. No es un muro infranqueable entre ambos enfoques, en el que ninguna parte necesite saber de la otra. La suposición por defecto debe ser que lo que hoy se prueba de forma manual, con el tiempo debe pasar a automatizarse.
Cualificaciones del Ingeniero de Automatización
Quizás sea inevitable que, al contratar ingenieros de pruebas automatizadas, las cualificaciones clave deseadas sean los niveles de competencia de los candidatos en (a) las herramientas de automatización que se espera usen y (b) los lenguajes de scripting de pruebas de esas herramientas.
Pero si éstas son las únicas cualificaciones en las que te enfocas, estarías cometiendo un gran error. Son necesarias, pero están lejos de ser suficientes para el rol de ingeniero de automatización.
¿Por qué? Por la sencilla razón de que saber usar una herramienta de automatización y cómo crear scripts en su lenguaje de scripting no te dice absolutamente nada sobre su comprensión del aseguramiento de la calidad propiamente dicho.
Lamentablemente, casi nunca veo ingenieros de automatización que tengan esta formación o experiencia. Se les contrata simplemente porque son expertos en scripting, no porque tengan habilidad para diseñar una prueba efectiva y diagnóstica.
Estas cualificaciones son, de hecho, más importantes que la experiencia con las herramientas y lenguajes de automatización que vayan a usar. Ellos pueden aprender eso fácilmente si lo necesitan. Pero formar a alguien en el diseño de pruebas y la interpretación de sus resultados lleva mucho tiempo y esfuerzo.
De hecho, sería mejor tomar a un analista experimentado que ya tengas y formarlo en las herramientas de automatización necesarias. Estas habilidades de automatización son, después de todo, ahora una mercancía. La intuición y el criterio de un tester experimentado no lo son.
Automatizar la ignorancia solo te da ignorancia más rápido, de manera más repetible y socava la eficiencia que buscabas con las pruebas automatizadas.
Estándares de Diseño de Automatización
Es incuestionable que, si vas a iniciar un esfuerzo de automatización de pruebas a gran escala, primero necesitarás definir estándares generales a los que toda automatización debe ajustarse para que sea aceptada en las pruebas. Sin embargo, como ocurre con muchas cosas obvias, parece que hay menos sentido común de lo que uno esperaría.
Estos son los aspectos que esos estándares deberían cubrir.
Inteligibilidad
Uno de los misterios frustrantes del desarrollo de software es cuán artesanal puede llegar a ser. Por desgracia, no es en absoluto raro que un ingeniero de software te diga que no puede corregir un error porque no escribió el código donde aparece. Es como si el código escrito por otro ingeniero estuviera en un idioma extranjero que no entienden.
Esto, lamentablemente, es igual de común en la ingeniería de automatización de pruebas. No puedo decir cuántas veces un ingeniero de QA me ha dicho que no sabe cómo actualizar una pieza de automatización de pruebas para una actualización importante de producto porque no la escribió y, por tanto, no la entiende ni puede entenderla. Ah, y el ingeniero que lo hizo se marchó de la empresa hace dos meses.
Esto es aún menos aceptable en el caso de scripts de pruebas automatizadas que en el caso del código de software nuevo que implementa lógica de diseño, y no solo ejecuta ciertos pasos. Aun así, es sorprendentemente común.
Lo que esto significa es que, antes de contratar a una docena de ingenieros de QA y ponerlos a generar alegremente cientos de scripts de pruebas automatizadas, asegúrate primero de definir y formar sobre estándares generales de inteligibilidad.
Debe ser un requisito que todos los scripts de prueba sean comprensibles para cualquiera de tus ingenieros de QA, de modo que no termines dependiendo de un único recurso, muchas veces transitorio, para su mantenimiento.
Define y aplica un proceso de revisión/aceptación de todos los candidatos a scripts automatizados frente a estos estándares antes de que puedan ser desplegados en las pruebas.
Mantenibilidad
La mantenibilidad está estrechamente relacionada con el problema de la inteligibilidad, sin embargo, ambas son cuestiones lógicamente y operativamente separadas. Un script de prueba puede ser fácilmente entendido por ingenieros de pruebas que no lo escribieron y, aun así, estar estructurado de tal manera que sea una pesadilla actualizarlo o modificarlo.
Aquí tienes un ejemplo de la vida real.
En una de las empresas donde trabajé, estábamos preparando el esfuerzo de pruebas para una actualización de nivel medio del producto principal. Estaba programada para un ciclo de lanzamiento de cuatro semanas, lo que en este caso era realmente razonable.
Mientras planificaba el esfuerzo de pruebas necesario, me di cuenta de que también tendríamos que actualizar el principal script automatizado de pruebas de regresión. Cuando le pregunté al ingeniero líder de QA cuánto tiempo tomaría esa actualización, respondió “ocho semanas”. ¡El doble de tiempo que todo el lanzamiento! Incluso concediendo el clásico pecado de inflar estimaciones, esto era extremo.
Pedí a otros ingenieros de pruebas que revisaran el script y la estimación. Todos estuvieron de acuerdo en que el script estaba escrito de forma tan torpe e ineficiente que tomaría semanas de arduo trabajo reescribirlo por completo para adaptarlo a la nueva versión, aunque las actualizaciones en sí no fuesen cambios fundamentales del producto.
Esa situación era un ejemplo clásico de cómo un pecado de la ingeniería de software se teletransportó al ámbito de la ingeniería de pruebas. Es hora de detener la locura.
Mi consejo aquí es idéntico al que doy arriba sobre el tema de la inteligibilidad. No permitas, bajo ninguna circunstancia, que tus ingenieros de QA se escondan en sus cuevas de ingeniería de pruebas y emerjan una o dos semanas después con algo que quizás funcione como test, pero que será una pesadilla de sufrimiento sin sentido cada vez que haya que actualizarlo con rapidez.
Establece estándares para la capacidad de actualización oportuna y crea un proceso de revisión y aceptación para garantizar que se cumplan. Esto puede integrarse fácilmente en los mismos esfuerzos para asegurar la inteligibilidad, así que puede formar parte del mismo proceso de revisión.
Tus ingenieros de QA no son pintores renacentistas, no les estás pidiendo que repinten la Capilla Sixtina. No debería llevarles toda la vida.
Roles de Pruebas y Automatización de Pruebas
Uno de los patrones de ineficiencia que inhiben una integración fluida y productiva de la automatización en tu esfuerzo de pruebas es la suposición errónea de que cada paso del proceso de pruebas automatizadas debe ocurrir dentro del propio grupo de automatización.
Este es otro error. Aunque en este caso, no del todo evidente.
Los ingenieros de automatización probablemente serán los recursos mejor pagados de tu equipo, por lo que su tiempo es valioso. Además, el volumen de scripts de pruebas que ese equipo tendrá que crear y actualizar continuamente solo crecerá con el tiempo, y sin embargo, tu grupo de ingenieros de prueba no podrá crecer lo suficientemente rápido para mantenerse al día. Ni siquiera si trabajas para Google.
Tiene sentido operativo, entonces, introducir divisiones de trabajo entre el equipo de automatización y el resto de tu equipo. En concreto, la división entre los recursos que crean y mantienen scripts y herramientas automatizadas, y aquellos que realmente ejecutan las pruebas automatizadas.
Claramente, las primeras responsabilidades solo pueden ser realizadas por el propio equipo de automatización. Para eso los contrataron, después de todo. Sin embargo, esto no es cierto para las segundas.
No hay ninguna razón para que los analistas no puedan también ejecutar pruebas automatizadas por sí mismos e interpretar sus resultados.
Pocas personas piensan en estos términos, pero esta división de trabajo tiene todo el sentido. Por un lado, libera una gran cantidad de tiempo que permite a los ingenieros de automatización enfocarse en crear nuevas automatizaciones.
Por otro lado, reforzará el requisito de inteligibilidad definido antes. Si la automatización es fundamental en tu esfuerzo de pruebas, entonces debe ser igualmente fundamental que todos en tu equipo de pruebas, sean ingenieros de automatización o no, puedan entender y utilizar tus pruebas automatizadas. Incluso los testers manuales.
Tal sistema de definición de roles aumentará enormemente la flexibilidad de recursos de todo tu equipo de QA, y por lo tanto también creará eficiencias de tiempo y calendario que, de otro modo, no existirían.
Reflexiones Finales
Desarrollar una capacidad de pruebas automatizadas robusta, como se definió antes, es sencillamente una necesidad hoy en día. No se puede hablar de QA profesional y efectiva sin ello.
Sin embargo, muchas aventuras prometedoras comienzan con entusiasmo y alegría, solo para terminar en derrota al final del viaje. Veo esto ocurrir en QA respecto a la automatización de pruebas en muchas, muchas ocasiones.
El problema es que la automatización de pruebas es relativamente fácil de comenzar. Cara, pero fácil, al menos para aparentar que estás haciendo el esfuerzo. Sin embargo, la automatización de pruebas también puede ser un precipicio, como el Coyote en los dibujos del Correcaminos, que corre sin darse cuenta hasta que mira abajo y cae.
Debe entenderse desde el principio que la automatización de pruebas tiene un ciclo de vida. Cada script de prueba tiene un ciclo de vida de meses, si no de años.
No se trata solo de escribir un montón de scripts de prueba automatizados que cubran todas tus necesidades para el producto tal como está en un momento de su desarrollo. Se trata de cómo vas a poder evolucionar sin problemas toda esa automatización a medida que el producto evoluciona a lo largo de su propio ciclo de vida.
Si ignoras los problemas del alcance de la automatización, las cualificaciones del ingeniero de QA, la inteligibilidad, el mantenimiento y la definición de roles, descubrirás que, con el tiempo, todo ese esfuerzo de automatización se ha convertido en un elefante blanco y un pozo sin fondo de dinero imposible de entender o mantener.
Y todo el dinero que invertiste habrá sido desperdiciado. Algo que los jefes de tus jefes no dejarán de notar.
Por otro lado, si sigues el consejo que te doy arriba, adaptado por supuesto a las particularidades de tus propios desafíos y situación, evitarás en gran medida esta crisis de obsolescencia y disfrutarás durante años de los frutos de una automatización de pruebas productiva.
Como siempre, te deseo la mejor de las suertes.
Lecturas relacionadas:
- 10 MEJORES HERRAMIENTAS PARA MONITOREO DE SERVIDORES WEB
- MEJORES PRÁCTICAS PARA LA AUTOMATIZACIÓN EN LA TRANSFORMACIÓN DIGITAL
Vale la pena revisar: ¿QUÉ ES MABL? VISIÓN GENERAL Y RECORRIDO POR SUS FUNCIONES
