¿Por qué la automatización de pruebas es tan importante para los sitios web de comercio electrónico?
Los proyectos de software no son precisamente como los coches, que pueden descomponerse fácilmente en elementos independientes. Así, la sustitución de un neumático no exige encender el motor para comprobar que el resto del vehículo siga funcionando. Sin embargo, en los proyectos de software, podría producirse una situación de este tipo.
¿Por qué es necesario automatizar las pruebas?
Todos los componentes de un software están muy interrelacionados, de modo que cualquier pequeño cambio en uno de ellos podría provocar la ruptura de otro totalmente diferente. Este es el motivo por el que los sistemas con unainterdependencia tan alta deben someterse a una verificación exhaustiva. Cada vez que se modifica algo, todo el proyecto debe comprobarse según un proceso conocido como «pruebas de regresión».
Como cabría esperar, las pruebas de regresión requieren una gran cantidad de tiempo y recursos, pero no solo eso. Cuando se trabaja en un proyecto de software en calidad de probador, el hecho de cubrir el mismo formulario una y otra vez se vuelve con el tiempo tedioso y favorece las distracciones. Se empieza por no ver esto o lo otro, y es aquí donde entra en escena la automatización de pruebas.
En este artículo, se explica el funcionamiento de la automatización de pruebas, se analizan los desafíos que plantea este proceso y se describe cómo los comercios electrónicos pueden sacarle el máximo partido.
Uso y función
¿Qué es la automatización de pruebas y cómo funciona?
La automatización de pruebas es la creación de programas que simulan la interacción de los usuarios con una aplicación, de modo que se trata de la aliada perfecta para las pruebas de regresión. Basta con ejecutar estos programas para que realicen todas las comprobaciones necesarias y, al terminar, informen de dónde han detectado problemas con sus flujos predefinidos.
Recuerdo haber trabajado en un proyecto en que los desarrolladores se olvidaron de dar formato a las fechas de una tabla. Debido a esto, en lugar de la fecha, la tabla mostraba el número de segundos que habían transcurrido desde 1970. Nadie se percató del error. Al cabo de un tiempo, el ojo humano simplemente reconoce números y los da por buenos. Por el contrario, las pruebas automatizadas detectaron el error e incluso verificaron que cada fecha fuese correcta.
Al configurar una automatización de pruebas, lo lógico es crear verificaciones que abarquen casi todas las funciones que los visitantes pueden usar en un sitio web. A continuación, lo ideal sería definir una prueba para cada una de estas funciones. Sin embargo, la mayoría de las veces, las pruebas automatizadas se ejecutan simplemente como un flujo de extremo a extremo que consiste, por ejemplo, en seleccionar un producto, añadirlo al carrito, introducir los datos personales, seleccionar un método de entrega y pago, y comprobar el correcto procesamiento del pedido.
Retos
Desafíos que plantean las pruebas automatizadas
Evidentemente, todo tiene un coste. Las pruebas automatizadas deben crearse paso a paso. Mientras que un probador manual actúa de manera autónoma pudiendo pinchar aquí y allá dentro de una aplicación, las pruebas automatizadas deben construirse con esmero.
En este sentido, con un simple clic, los probadores o los usuarios manuales pueden hacer que una ventana emergente desaparezca, algo para lo que una prueba automatizada tendrá que configurarse debidamente. La prueba debe conocer cuándo aparecerá dicha ventana y cuándo podrá cerrarse porque, de lo contrario, se atascará.
Este es el motivo por el que se tarda cierto tiempo en crear este tipo de verificaciones. Y, puesto que normalmente solo pueden desarrollarse una vez que exista una versión lo suficientemente estable de la aplicación, los automatizadores de pruebas acostumbran a vivir en esa «tierra de nadie» comprendida entre la creación y la publicación de nuevas características.
Una vez terminado el desarrollo, los gestores de proyecto intentan entregar lo antes posible porque todo está listo y, a menudo, no queda tiempo para la automatización de pruebas. He aquí otro motivo por el que la automatización de pruebas a menudo se ignora.
¿Por qué los comercios electrónicos están apostando por la automatización de pruebas?
En la actualidad, cada vez son más las empresas que confían en la automatización de pruebas. De hecho, en mi opinión, ningún comercio electrónico debería estar dispuesto a colaborar con ninguna empresa de software que no emplee la automatización de pruebas. Ignorar la automatización de pruebas es el primer paso para ignorar la calidad.
Evidentemente, siempre se puede optar por hacer clic aquí y allá. Sin duda, esto será suficiente para detectar si algún elemento relevante no funciona correctamente. Sin embargo, un símil parecido sería el de un mecánico que echa un vistazo rápido bajo el capó de un coche para ver si tiene motor y si este parece estar en buen estado. Es probable que nadie quiera conducir ese vehículo. Y, ciertamente, nadie querría que este fuese el procedimiento habitual antes de coger un avión. Por suerte, las aplicaciones web son mucho menos peligrosas, pero conviene reflexionar acerca de lo siguiente: cualquier cliente que se quede colgado un par de veces probablemente no querrá volver a probar suerte y se marchará en busca de otros proveedores de servicios
¿Por qué la automatización de pruebas tiende a perderse en medio de mantenimientos?
Los automatizadores de pruebas tienden a perderse en medio de mantenimientos. Las pruebas automatizadas no son esa herramienta de ensueño que se puede ejecutar así como así para obtener exactamente el número de errores que existen en una aplicación y conocer dónde se encuentran. No cabe duda de que la automatización de pruebas detectará errores, pero habrá muchos otros diagnósticos negativos que no se deberán a errores.
Las pruebas automatizadas son unas criaturas muy frágiles que deben interactuar con los mismos elementos que los propios usuarios, pero si cualquiera de estos elementos se modifica, dejarán de identificarlos para siempre. ¿Cómo es esto posible? Veamos un ejemplo sencillo. Pensemos en un botón «Continuar» disponible después de seleccionar un método de pago y que presenta el siguiente código html asociado:
- <button class=”continue”>
Teniendo en cuenta que podrían existir varios botones diferentes en la página, las pruebas automatizadas deberán programarse para buscar un botón de la clase «continue». Sin embargo, si se produce algún cambio en dicha clase, obtendremos este código:
- <button class=”continue_payment”>
En ese caso, la prueba automatizada no identificará el botón e informará de que no existe, de tal forma que el resultado de la prueba será negativo. Por supuesto, se trataría de un falso negativo desde un punto de vista funcional, puesto que el botón realmente sí existe. Por tanto, la prueba deberá someterse a un mantenimiento para adaptarse al botón modificado.
A menudo, el incremento en el volumen de mantenimientos se debe a una falta de sincronización entre automatizadores y desarrolladores. Suele suceder que los automatizadores no reciban información sobre los componentes de la aplicación que se han modificado y que, por su parte, los desarrolladores desconozcan por completo los elementos que emplean los automatizadores para conectar sus pruebas al sitio web. En concreto, es habitual que los automatizadores de pruebas sufran las consecuencias de los cambios masivos de diseño,puesto que a menudo se enfrentan a infinidad de pequeñas modificaciones de este tipo.
Las pruebas automatizadas adoran los formularios largos y aburridos que logran cubrir con una rapidez tal que el ojo humano es incapaz de seguir. Si no se modifica ningún campo, estas pruebas podrán ejecutarse hasta el infinito. Por otra parte, un problema adicional de las pruebas automatizadas son las junglas de ventanas emergentes,puesto que no consiguen interactuar con los elementos que se hallan detrás de dichas ventanas.
Los usuarios simplemente tienen que pinchar en ellas cuando aparecen. En cambio, una prueba automatizada debe esperar a que la ventana aparezca —aunque no corresponda— para luego cerrarla y, solo entonces, empezar a interactuar con los elementos de la página. Como cabría esperar, lo anterior es especialmente complejo cuando estas ventanas no son obligatorias y podrían mostrarse o no.
La solución para que todo funcione
Por suerte, existe una solución para estos problemas de mantenimiento que se consigue con una información adicional mágica. Si los desarrolladores conociesen los elementos de los que depende el trabajo de los automatizadores, todo marcharía sobre ruedas. Y esto es algo que puede conseguirse a bajo coste. Los desarrolladores solo tienen que incorporar unos elementos específicos. Tomemos como ejemplo el botón del que hablábamos más arriba, al que podría añadírsele un atributo especial de automatización:
- <button class=”continue” auto=“continueAfterPayment“>
En este caso, las pruebas podrían tomar como referencia este atributo especial y no se verían afectadas por posibles modificaciones del resto de los atributos o, incluso, del propio Elemento cuando, por motivos de diseño, pueda haberse transformado de botón a enlace. Además, las pruebas se volverían muy estables si cada elemento de interacción de una página web contase con uno de estos atributos a modo de referencia para la automatización de pruebas. Sin embargo, esto implica un trabajo adicional para los desarrolladores que difícilmente acometerán si la automatización no se considera como una parte importante del proceso de desarrollo en su conjunto.
Existe incluso un aspecto en que se hace patente la exclusión de la automatización del proceso de desarrollo. Cuando los automatizadores aprenden su oficio, suelen apoyarse en los atributos «id» de los elementos web con un formato como este:
- <button id=”continue”>
Estos atributos «id» se supone que son estables y únicos en una página web. Así, numerosas herramientas de automatización funcionan con referencias integradas a estos identificadores. Por ejemplo, en Selenium, una herramienta habitual para la automatización de pruebas, se puede pedir al ordenador que detecte un elemento a partir de su identificador. Si se prefiere emplear la clase —como en el ejemplo anterior—, la tarea se vuelve un poco más complicada. Lo cierto es que muchas plataformas de desarrollo generan automáticamente estos identificadores, aunque lo hacen de una forma totalmente inconsistente, de modo que no resultan útiles para la automatización. Existe una gran descoordinación entre ambos mundos con respecto a esta cuestión.
Una correspondencia mágica entre desarrollo y automatización
Entonces, ¿qué sucede con esa información adicional mágica que se ha mencionado anteriormente? Pensemos en una página web en que cada elemento funcional cuente con un atributo fijo que sirva como referencia para la automatización de pruebas, tal y como se ha explicado en el ejemplo anterior:
- <button class=”continue” auto=“continueAfterPayment“>
Una automatización de pruebas de este tipo es algo bastante sencillo, puesto que simplemente traduce las descripciones de la etapa de verificación funcional en descripciones de la etapa de verificación automatizada. Pinchar aquí, luego rellenar este campo y pinchar allí. Lo más difícil de indicar a un programa informático qué hacer es explicar qué elementos deberían funcionar con esto y con aquello, qué botón o qué campo queremos que pinche o rellene... Ahora, imaginemos que estos elementos cuentan con un tipo de referencia fijo como en el ejemplo anterior. En ese caso, el paso de averiguar la referencia se convertiría en algo sencillo, que incluso podría conseguirse a través del propio programa informático. Esto significa que se podrían automatizar las referencias y, de este modo, se podría automatizar la automatización de pruebas en su conjunto. Solo habría que redactar casos de prueba en un lenguaje bastante formal para que los casos de prueba automatizados se generasen de manera automática a partir de ahí. De esta forma, se conseguiría una automatización automatizada.
Un antiguo jefe mío, quien se parecía mucho a Leonardo da Vinci y pensaba mucho como él, solía decir que la producción de software todavía se encontraba en una fase muy similar a la de la producción de herramientas con piedras del Neolítico, en que cada una se fabricaba individualmente y era diferente de las demás. Siempre dibujaba un panorama en que, en una forma de producción de software más industrializada del futuro, los seres humanos no escribirían ningún tipo de código, sino que todo se crearía a partir de modelos. Entonces, tanto las interfaces de usuario como las pruebas automatizadas se podrían generar a partir de los mismos modelos y ofrecer una simbiosis perfecta. Si embargo, todos sabemos que las herramientas de piedra neolíticas se situaron a la vanguardia tecnológica durante millones de años y que únicamente se sustituyeron por los metales hace tan solo unos miles de años. Por tanto, todavía podríamos encontrarnos muy lejos de este ideal de automatización integral. Sin embargo, es bueno tener una idea como esta en mente al pensar en posibles mejoras.
