Probar procesos de Maestro

Enfoque de prueba

Las pruebas de procesos de Maestro se basan en tres principios:

1. Mantén lo que funciona: prueba los flujos de trabajo de RPA dentro de tu proceso de Maestro de la misma manera que siempre los has probado.
2. Prueba cada parte por separado: la RPA, los Agents y las tareas humanas tienen sus propios patrones de prueba. Al probar las partes individualmente es más fácil saber lo que se ha roto cuando algo sale mal.
3. Prueba todo el proceso: las pruebas de extremo a extremo verifican que los pasos estén conectados correctamente, que los datos fluyan como esperas y que el resultado empresarial sea el correcto.

Los procesos de Maestro difieren de los Flujos de trabajo de RPA en aspectos que condicionan este enfoque. Los flujos de trabajo de RPA se ejecutan en segundos, y las mismas entradas siempre producen las mismas salidas. Los procesos de Maestro pueden ejecutarse durante minutos, horas o días. Combinan RPA, Agents y pasos humanos en un único flujo. Dependen de sistemas externos que no controlas.

Los procesos de Maestro se están pudiendo probar directamente, con herramientas creadas para ellos. Las siguientes mejoras permiten llegar a este resultado.

Qué puedes hacer hoy

Pruebas de flujos de trabajo de RPA: los flujos de trabajo de RPA que se utilizan en un proceso de Maestro pueden probarse con casos de prueba en el proyecto de RPA, de la misma manera que con cualquier otro flujo de trabajo de RPA. Las entradas de prueba verifican que la salida coincide con las expectativas. No son necesarias herramientas específicas de Maestro.

Pruebas de agentes: los agentes utilizados en los procesos de Maestro pueden probarse con conjuntos de evaluación en Studio Web. Un conjunto de evaluación es una lista de entradas de prueba emparejadas con las respuestas que esperas del agente. Ejecuta el agente con cada entrada y compara la respuesta real con la esperada. Esto es más importante para los procesos en los que los agentes toman decisiones importantes.

Pruebas de procesos de extremo a extremo: un caso de prueba de Studio puede ejecutar un proceso de Maestro publicado con datos de prueba preparados y, luego, comprobar la salida final. Para cualquier persona nueva en las pruebas de procesos de Maestro, este es el lugar más importante por el que empezar.

Ejecuciones de depuraciones: la ejecución de depuraciones en Studio Web es la herramienta correcta para comprobar cómo se comporta un proceso durante la creación. Proporciona seguimientos paso a paso, actualizaciones de variables en tiempo real y un historial de ejecuciones de depuraciones pasadas.

Cómo crear tu práctica de prueba de Maestro

Crea la cobertura en orden:

1. Comienza con pruebas de extremo a extremo en tus procesos más críticos: una prueba por cada resultado crítico del negocio. Estas son las pruebas que evitan que tus problemas más graves lleguen a producción.
2. Añade pruebas de agente a procesos que dependen de agentes: las respuestas del agente varían más que otras partes del proceso. Pruébalos por separado para poder detectar problemas específicos del agente desde el principio.
3. Expande el sistema para gestionar fallos y casos límite: añade pruebas para entradas no válidas, pasos fallidos y otras situaciones en las que las cosas van mal. Añade pruebas para los flujos de trabajo de RPA utilizados en varios procesos de Maestro.

Las partes más difíciles de probar Maestro

Cuatro desafíos son habituales. Planifica para ellos por adelantado.

Procesos de larga duración

Los procesos de Maestro pueden ejecutarse durante horas o días. El mismo proceso puede tardar 30 minutos en producción y 2 minutos en prueba, lo que depende de los datos y de la capacidad de respuesta de los sistemas externos. Eso hace que las comprobaciones basadas en tiempos no sean fiables. Prueba lo que produjo el proceso y conoce qué pasos ejecutó, no cuánto tiempo tardó.

Dependencia de sistemas externos

Las pruebas de extremo a extremo se conectan a sistemas externos reales. Eso significa que las pruebas pueden fallar por razones que no tienen nada que ver con tu proceso: un tiempo de espera de conexión, un límite de velocidad de terceros o un sistema inactivo. Usa un sandbox o una versión de prueba de esos sistemas cuando sea posible. Si una conexión falla aleatoriamente durante el desarrollo, trátala como un problema de conexión, no como un error real de la prueba.

Variabilidad del agente

Dos ejecuciones del mismo agente con la misma entrada pueden producir diferentes salidas. Las comprobaciones de igualdad fallarán de forma intermitente. Los conjuntos de evaluación están diseñados para esto. Usa reglas de comparación que permitan una variación razonable en lugar de exigir una coincidencia exacta.

Pasos con intervención humana (HITL)

Las pruebas deben ejecutarse de extremo a extremo sin intervención humana, pero los pasos HITL de Maestro esperan a que una persona real realice acciones. No hay integrada ninguna forma de inyectar una respuesta alternativa. La alternativa correcta depende de cómo configures tus pasos de HITL. El equipo de tu cuenta puede ayudarte con el enfoque específico.