Prueba de automatización

Para sacar el máximo partido a tus esfuerzos de prueba, considera las siguientes prácticas recomendadas de automatización de pruebas basadas en las pruebas RPA o de aplicación.

Prueba de aplicación

• Utiliza la plantilla Marco de automatización de pruebas para implementar proyectos de automatización estables y escalables.
• Los casos de prueba deben ser independientes entre sí. Un caso de prueba no debería depender de la ejecución de otro caso de prueba.
• Un caso de prueba solo debe tener un propósito específico. Cada flujo de trabajo de prueba debe contener solo una verificación.
• Cada característica debe tener una prueba de unidad. Si se permiten excepciones, crea una prueba y una excepción independientes para cada caso de prueba.
• En una estructura de caso de prueba Dado-Cuando-Entonces, si la parte dada se está volviendo demasiado extensa e inmanejable, trata de redefinir el caso de prueba. Podría necesitar más granularidad o refactorización.
• Mantén los casos de prueba y actualízalos después de cualquier solicitud de cambio.
• Considera establecer una lógica de gestión de pruebas para tener una única manera de definir casos de prueba.
• Para aumentar la reutilización entre proyectos de prueba individuales, así como entre proyectos de prueba y RPA, trata de usar bibliotecas y repositorios de objetos siempre que sea posible.
• Incluye las pruebas en el proceso de CI/CD.
• Las pruebas funcionales como parte de tu proceso de CI deberían ejecutarse lo más rápido posible para no retrasar tu diseño. Por lo tanto, trata de ejecutar estas pruebas en paralelo con tantos robots como sea posible.
• Los nombres de actividad deben reflejar la acción realizada. En los comportamientos no evidentes, considera la posibilidad de utilizar anotaciones en tus actividades.
• Considera usar un registro detallado y el manejo de excepciones para depurar el proceso y evitar resultados negativos falsos.
• Planifica la recuperación o reintenta en caso de error en diferentes etapas para evitar resultados fallidos.
• Considera tener una estructura de carpetas dedicada a probar y usar la misma convención de denominación de casos de prueba en todos sus proyectos.
• Usa activos para variables que sean susceptibles de cambiar y usarse muchas veces.
• Para escenarios en los que el estado de una aplicación deba validarse antes de continuar con ciertos pasos en un proceso, considera la posibilidad de aplicar medidas de validación. Estas medidas pueden incluir el uso de actividades adicionales que esperan el estado de la aplicación deseado antes de otras interacciones (los retrasos codificados no se consideran buenas prácticas).
• Considera usar simulación de clic/escribir o enviar mensajes de Windows siempre que sea posible.
• No elimines, muevas ni renombres los casos de prueba fuera de Studio. Realiza estas acciones solo en Studio. Usa Importar casos de prueba en caso de que haya casos de prueba de otro proyecto que deban referenciarse.

Prueba de RPA

• Los casos de prueba deben ser independientes entre sí. Un caso de prueba no debería depender de la ejecución de otro caso de prueba.
• Considera crear pequeños flujos de trabajo que aborden el menor número de acciones posible. De esta manera, será más fácil entenderlo y realizar pruebas de unidad.
• Un caso de prueba solo debe tener un propósito específico. Cada flujo de trabajo de prueba debe contener solo una verificación.
• Cada característica debe tener una prueba de unidad. Si se permiten excepciones, crea una prueba separada para cada caso de prueba.
• Para aumentar la reutilización entre proyectos de prueba individuales, así como entre proyectos de prueba y RPA, trata de usar bibliotecas y repositorios de objetos siempre que sea posible.
• En una estructura de caso de prueba Given-When-Then (Dado-Cuando-Entonces), si la parte Dado se está volviendo demasiado extensa e inmanejable, intenta redefinir el caso de prueba. Podría necesitar más granularidad o refactorización. La modularidad es la clave para una buena prueba unitaria. Las pruebas de escritura podrían actuar como comentarios/revisión de código en el desarrollo.
• Usa la simulación siempre que existan pasos complejos que sean irrelevantes para el propósito del caso de prueba que puedan reemplazarse.
• Considera establecer una lógica de gestión de pruebas para tener una única manera de definir casos de prueba.
• Mantén los casos de prueba y actualízalos después de cualquier solicitud de cambio.
• Incluye las pruebas en el proceso de CI/CD.
• Ejecuta tus casos de prueba cada vez que realices un cambio en RPA para asegurarte de que no se introduzca ningún error.
• Prepara un conjunto de pruebas RPA que pueda ejecutar el equipo de TI en un entorno de preproducción, siempre que planee implementar un cambio de entorno (como una actualización de Windows) para que puedas detectar problemas potenciales antes de que lleguen a la fase de producción.
• Los nombres de actividad deben reflejar la acción realizada. En los comportamientos no evidentes, considera la posibilidad de utilizar anotaciones en tus actividades.
• Planifica la recuperación o reintenta en caso de error en diferentes etapas para evitar resultados fallidos.
• Considera tener una estructura de carpetas dedicada a probar y usar la misma convención de denominación de casos de prueba en todos sus proyectos.
• Usa activos para variables que sean susceptibles de cambiar y usarse muchas veces.
• Para escenarios en los que el estado de una aplicación deba validarse antes de continuar con ciertos pasos en un proceso, considera la posibilidad de aplicar medidas de validación. Estas medidas pueden incluir el uso de actividades adicionales que esperan el estado de la aplicación deseado antes de otras interacciones (los retrasos codificados no se consideran buenas prácticas).
• Considera usar simulación de clic/escribir o enviar mensajes de Windows siempre que sea posible.
• No elimines, muevas ni renombres los casos de prueba fuera de Studio. Realiza estas acciones solo en Studio. Usa Importar casos de prueba en caso de que haya casos de prueba de otro proyecto que deban referenciarse.