Aprovechando la RPA para pruebas de software: Un enfoque estratégico

La automatización ineficaz de pruebas de software es notoria por retrasar lanzamientos mientras consume cantidades increíbles de recursos.

De vez en cuando, mi feed de noticias presenta un artículo que ofrece "Los 10 mejores trucos de vida". Estos son consejos y trucos sobre cómo usar productos domésticos ordinarios de formas inesperadas para mejorar tu vida— "...y el truco número 7 te volará la mente!!!"

Admitidamente, he caído en hacer clic en este cebo. Para ser honesto, hay veces que me sorprendo gratamente. Por ejemplo, ¿quién sabía que podías cortar molestos envases blister de plástico con un abrelatas, o usar un rollo de papel higiénico para evitar que el papel de regalo se desenrolle?

Probé los dos "trucos" anteriores y adivina qué? "Casi" funcionaron... por un tiempo. El abrelatas cortó la costura donde el plástico estaba fusionado, pero no logró cortar a lo largo del envase. El rollo de papel higiénico sujetó el papel de regalo por un tiempo, pero finalmente el cartón se debilitó y el papel de regalo se desenrolló. No sorprendentemente, usar tijeras para los envases blister y un pequeño trozo de cinta para el papel de regalo funcionó mucho, mucho mejor.

De manera muy similar, muchas organizaciones ahora están considerando usar RPA para automatizar pruebas de software: un "truco tecnológico" para pruebas de software, de cierta forma. Sin embargo, al igual que el rollo de papel higiénico no presentó una solución sostenible para mantener mi papel de regalo de desenrollarse, la RPA no es una solución sostenible para la automatización de pruebas de software... y las modificaciones requeridas para hacer la herramienta RPA sostenible para la tarea de automatización de pruebas de software serían, bueno, un truco.

Si ya tienes una herramienta RPA en tu organización y buscas empezar con la automatización de pruebas, tu herramienta RPA puede parecer una opción lógica. Suele ser relativamente fácil automatizar algunos escenarios de prueba fundamentales (ej., crear un nuevo usuario y completar una transacción), añadir validación, y creer que estás en el camino hacia la automatización de pruebas.

Sin embargo, es importante reconocer que la automatización de pruebas exitosa —y sostenible— requiere mucho más que la capacidad de hacer clic a través de rutas de aplicación. Para superar el desolador promedio de la industria de tasa de automatización de pruebas <20%, los equipos también deben ser capaces de construir y estabilizar una suite de pruebas automatizada efectiva. Las herramientas RPA usualmente no están diseñadas para permitir esto. Como resultado, te toparás con obstáculos de automatización de pruebas como retrasos esperando los datos de prueba y entornos de prueba requeridos, resultados inconsistentes que erosionan la confianza en la iniciativa de automatización, y "suites de pruebas infladas" que consumen recursos considerables pero no entregan retroalimentación clara y accionable.

Para una visión rápida de la diferencia de alcance entre herramientas RPA y herramientas de automatización de pruebas, compare las siguientes definiciones de Gartner:

Las herramientas RPA "realizan declaraciones 'si, entonces, sino' en datos estructurados, típicamente usando una combinación de interacciones de interfaz de usuario (UI), o conectándose a APIs para impulsar servidores cliente, mainframes o código HTML. Una herramienta RPA opera mapeando un proceso en el lenguaje de la herramienta RPA para que el 'robot' de software lo siga, con tiempo de ejecución asignado para ejecutar el script por un panel de control".

Las herramientas de automatización de pruebas "permiten a una organización diseñar, desarrollar, mantener, gestionar, ejecutar y analizar pruebas funcionales automatizadas... Proporcionan amplitud y profundidad de productos y características a lo largo del ciclo de vida de desarrollo de software (SDLC). Esto incluye diseño y desarrollo de pruebas; mantenimiento y reutilización de casos de prueba; y gestión de pruebas, gestión de datos de prueba, pruebas automatizadas e integración, con un fuerte enfoque en soporte para pruebas continuas".

La necesidad de estas capacidades de prueba adicionales se vuelve clara cuando consideras algunas de las diferencias fundamentales entre:

• Automatizar secuencias de tareas en entornos de producción para ejecutar con éxito un camino claramente definido a través de un proceso para completar el trabajo más rápido, y
• Automatizar procesos de negocio realistas en entornos de prueba para ver dónde falla una aplicación y poder tomar decisiones informadas sobre si una aplicación es demasiado arriesgada para lanzar

¿Qué significan estas diferencias para las pruebas de software?

• La automatización debe ejecutarse en un entorno de prueba que típicamente está incompleto, en evolución y restringido
• Gestionar datos de prueba con estado, seguros y cumplidores se convierte en un gran desafío
• El diseño efectivo de casos de prueba es esencial para el éxito
• Los fallos necesitan proporcionar información sobre el riesgo de negocio

Para ponerlo en términos más concretos, consideremos el ejemplo de probar un servicio de viajes en línea. Asuma que quiere verificar la funcionalidad que permite a un usuario extender su reserva de hotel prepagada. Primero, necesitaría decidir cuántas pruebas se requieren para ejercitar exhaustivamente la lógica de la aplicación— y qué combinaciones de datos cada una necesitaría usar.

Luego, necesitaría adquirir y proveer todos los datos requeridos para establecer la aplicación en el estado donde el escenario de prueba puede ejecutarse. En este caso, necesita (al menos) una cuenta de usuario existente con una reserva prepagada existente para alguna fecha en el futuro—y no podría usar datos de producción reales, debido a regulaciones de privacidad como GDPR.

Luego, necesita una forma de invocar el rango requerido de respuestas del sistema de reserva de hotel conectado (una habitación disponible/no disponible), la tarjeta de crédito (transacción aprobada/denegada) etc.—pero sin realmente reservar una habitación o cobrar una tarjeta de crédito.

Necesitaría automatizar el proceso, por supuesto. Esto implica iniciar sesión, recuperar la reserva existente, indicar que quiere modificarla, luego especificar la duración de la extensión.

Una vez que tenga el proceso completo automatizado, necesitaría configurar una serie de validaciones en diferentes puntos de control. ¿Se enviaron los detalles apropiados al hotel en el formato de mensaje apropiado? ¿Se actualizó la reserva en su base de datos de usuarios? ¿Se enviaron correctamente los datos de pago al proveedor de tarjeta de crédito? ¿Se aplicaron créditos de cuenta? ¿Recibió el usuario un mensaje apropiado si la reserva no pudo extenderse? ¿Qué pasa si se denegó la tarjeta de crédito? Y si se denegó la tarjeta de crédito, ¿su sistema revirtió a la duración original de la reserva en lugar de añadir noches adicionales que no se pagaron realmente?

Ahora imagine que su empresa decidió añadir una tarifa de cambio de $10 para todas las reservas prepagadas. ¿Podría deslizar fácilmente este nuevo requisito en sus pruebas automatizadas existentes—o tendría que retrabajar sustancialmente cada una de las pruebas para acomodar este cambio menor?

Incluso este simple ejemplo expone algunas de las muchas complejidades de las pruebas de software que las herramientas RPA simplemente no están diseñadas para abordar. Las herramientas RPA están construidas para automatizar tareas específicas dentro de una secuencia. Las herramientas de automatización de pruebas de software están diseñadas para medir la resiliencia de una secuencia más amplia de tareas. Para decirlo sin rodeos: las herramientas RPA están arquitectadas para hacer que un proceso funcione. Pero para las pruebas de software, necesita herramientas que le ayuden a determinar cómo un proceso puede romperse posiblemente.

La automatización ineficaz de pruebas de software es notoria por retrasar lanzamientos mientras consume cantidades increíbles de recursos. A medida que los CIOs invierten cada vez más en iniciativas de transformación digital que mejoran la experiencia del cliente a través de una entrega de software más rápida, escatimar en pruebas de software es contraproducente. Elegir la herramienta adecuada para el trabajo dará sus frutos significativamente en términos de entrega acelerada, riesgo de negocio reducido, y más recursos para dedicar a la innovación.

Wayne Ariola es el autor de Continuous Testing for IT leaders y un conocido orador principal en el espacio DevOps y App Dev.