Uso de RPA para pruebas de software:¿un "truco tecnológico"?

La automatización ineficaz de las pruebas de software es conocida por retrasar los lanzamientos y consumir cantidades increíbles de recursos.

De vez en cuando, mi fuente de noticias presenta un artículo que ofrece "Los 10 mejores trucos para la vida". Estos son consejos y trucos sobre cómo usar productos domésticos comunes de formas inesperadas para mejorar tu vida:"... ¡y el consejo número 7 te dejará boquiabierto!"

Es cierto que me han engañado para abrir este cebo de clic. Para ser honesto, hay veces que estoy gratamente sorprendido. Por ejemplo, ¿quién sabía que podrías cortar los molestos blísteres 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 ¿adivinen qué? Ellos "un poco" trabajaron... por un tiempo. El abrelatas cortó la costura donde se fusionó el plástico, pero no logró cortar el largo del empaque. El papel higiénico retuvo el papel de envolver por un tiempo, pero finalmente el cartón se debilitó y el papel de envolver se deshizo. Como era de esperar, usar tijeras para los blísters de plástico y un pequeño trozo de cinta adhesiva para el papel de regalo funcionó mucho, mucho mejor.

En una línea muy similar, muchas organizaciones ahora están considerando usar RPA para automatizar las pruebas de software:una especie de "truco tecnológico" para las pruebas de software. Sin embargo, así como el rollo de papel higiénico no presentó una solución sostenible para evitar que mi papel de regalo se desenrollara, RPA no es una solución sostenible para la automatización de pruebas de software... y las modificaciones necesarias para que la herramienta RPA sea sostenible para la tarea de prueba de software. la automatización sería, bueno, un truco.

Si ya tiene una herramienta RPA en su organización y está buscando comenzar con la automatización de pruebas, su herramienta RPA puede parecer una opción lógica. Por lo general, es relativamente fácil automatizar algunos escenarios de prueba fundamentales (por ejemplo, crear un nuevo usuario y completar una transacción), agregar validación y creer que está 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 en las rutas de las aplicaciones. Para superar la deprimente tasa de automatización de pruebas promedio de la industria de <20 %, los equipos también deben ser capaces de construir y estabilizar un conjunto de pruebas automatizado eficaz. Las herramientas de RPA generalmente no están diseñadas para habilitar esto. Como resultado, encontrará obstáculos en la automatización de pruebas, como retrasos en la espera de los datos de prueba y los entornos de prueba requeridos, resultados inconsistentes que erosionan la confianza en la iniciativa de automatización y conjuntos de pruebas "inflados" que consumen recursos considerables pero no entregan resultados claros y claros. comentarios prácticos.

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

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

Las herramientas de automatización de pruebas “permiten que una organización diseñe, desarrolle, mantenga, gestione, ejecute y analice pruebas funcionales automatizadas... Brindan una variedad y profundidad de productos y funciones a lo largo del ciclo de vida del desarrollo de software (SDLC). Esto incluye el 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 el soporte para pruebas continuas”.

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

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

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

• La automatización debe ejecutarse en un entorno de prueba que normalmente está incompleto, en evolución y restringido
• La gestión de datos de prueba con estado, seguros y compatibles se convierte en un gran desafío
• El diseño eficaz de casos de prueba es esencial para el éxito
• Las fallas deben proporcionar información sobre el riesgo comercial

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

Luego, deberá adquirir y aprovisionar todos los datos necesarios para configurar la aplicación en el estado en el que se puede ejecutar el escenario de prueba. En este caso, necesita (al menos) una cuenta de usuario existente con una reserva prepaga existente para una 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 está disponible/no disponible), la tarjeta de crédito (transacción aprobada/rechazada), etc., pero sin reservar una habitación o cargar una tarjeta de crédito.

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

Una vez que haya automatizado el proceso completo, deberá 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 usuario? ¿Se enviaron correctamente los datos de pago al proveedor de la tarjeta de crédito? ¿Se aplicaron créditos en la cuenta? ¿Recibió el usuario un mensaje adecuado si la reserva no se podía ampliar? ¿Qué pasa si la tarjeta de crédito fue denegada? Y si se denegó la tarjeta de crédito, ¿su sistema volvió a la duración original de la reserva en lugar de agregar noches adicionales que no se pagaron realmente?

Ahora imagine que su empresa decidió agregar una tarifa de cambio de $ 10 para todas las reservas prepagas. ¿Podría incluir fácilmente este nuevo requisito en sus pruebas automatizadas existentes, o tendría que volver a trabajar sustancialmente en todas y cada una de las pruebas para adaptarse a 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 diseñadas 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 de RPA están diseñadas para hacer que un proceso funcione. Pero para las pruebas de software, necesita herramientas que lo ayuden a determinar cómo un proceso puede fallar.

La automatización ineficaz de las pruebas de software es notoria por retrasar los lanzamientos y consumir cantidades increíbles de recursos. A medida que los CIO 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 las pruebas de software es contraproducente. Elegir la herramienta adecuada para el trabajo dará sus frutos significativamente en términos de entrega acelerada, riesgo comercial reducido y más recursos para dedicar a la innovación.

Wayne Ariola, es el autor de Pruebas continuas para líderes de TI y un conocido orador principal en el espacio DevOps y App Dev.