Cómo habilitar la reutilización con repositorios de objetos en las pruebas de automatización
Como desarrolladores de automatización, ¿no sentimos una satisfacción especial cuando escuchamos al equipo de pruebas manuales, o al cliente, comentar cómo se han beneficiado al usar la automatización que hemos desarrollado? Para lograr esto, respaldamos una suite de automatización de alta calidad que no solo sea robusta, sino también fácilmente adaptable a actualizaciones requeridas según cualquier cambio en los requisitos empresariales o técnicos. El mantenimiento debe ser sencillo, es lo que nos repetimos constantemente. ¿Cuáles son las maneras de asegurarlo?
Entre las diversas formas en que podemos garantizar la alta calidad de una suite de Automatización de Pruebas, una de ellas es asegurar la reutilización—no solo reutilizando pasos de prueba comunes, sino también reutilizando objetos de UI frecuentemente utilizados. En este artículo, explicaré cómo podemos usar los repositorios de objetos para mejorar el aspecto de reutilización empleando objetos en un proyecto de automatización de pruebas de UI.
- ¿Qué es un repositorio de objetos en las pruebas de automatización?
- ¿Por qué es importante?
- Buenas prácticas al utilizar repositorios de objetos
- Cómo crear repositorios de objetos (ejemplos)
¿Qué es un repositorio de objetos en las pruebas de automatización?
Cuando se comienza a diseñar la suite de automatización de pruebas, la mayoría de nosotros procuramos no reescribir bloques de código. Para esto, creamos funciones reutilizables y ponemos a disposición los bloques de código común en bibliotecas de código. Sin embargo, ¿has reutilizado alguna vez objetos de UI recurrentes? Si no es así, déjame explicarte cómo puedes lograrlo utilizando un repositorio de objetos como base.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Un repositorio de objetos es una colección de objetos de UI que suelen estar asociados entre sí. Esto no solo mejora la reutilización, sino que también garantiza la fiabilidad y la gestión de los elementos de la UI en la suite de automatización.
Mientras desarrollas los scripts de automatización de pruebas, seguramente habrás asociado pasos del script de prueba con cada uno de estos objetos de UI. Por ejemplo, al –
- Escribir en un objeto de UI tipo cuadro de texto
- Obtener el texto de un objeto de UI tipo Etiqueta
- Hacer clic en el objeto de hipervínculo... y así sucesivamente.
Entonces, ¿cómo puedes mejorar la reutilización al reaprovechar los objetos de UI sobre los que actúan tus scripts?
Pues bien, si la herramienta de automatización de pruebas que utilizas posee un “repositorio de objetos”, es sencillo. Usando un repositorio de objetos, puedes reunir los objetos de UI y agregar, eliminar, gestionar o actualizar los objetos de UI de dicho repositorio de manera organizada. Posteriormente, puedes reutilizar los objetos simplemente referenciándolos.
Analicemos una situación en la que no has utilizado un OR en tu suite de automatización de pruebas. En este caso, para scripts de automatización distintos que usan el mismo widget de UI, agregarías múltiples copias del mismo objeto de UI en cada uno de los scripts de prueba para realizar actividades sobre él.
Ahora, pongamos el caso contrario, en que sí se utiliza un OR. En ese caso, tendrías una única ubicación/repositorio donde almacenarías los objetos de UI. Así, en cada script de prueba que necesite actuar sobre el mismo objeto/widget de UI, se asociaría a ese mismo objeto de UI, almacenado en el OR. Solo hay una copia del objeto de UI en la suite de pruebas, con múltiples scripts de prueba referenciando/llamando al mismo objeto de UI. ¡Y aquí es donde entra en juego la reutilización!
¿Por qué es importante?
Mi primera experiencia usando un OR fue cuando lo utilicé en la herramienta de Automatización de Pruebas Funcionales IBM Rational. Desde entonces, cada vez que aprendo una herramienta nueva, espero con interés comprobar si esa herramienta posee la funcionalidad de OR o no.
La primera vez que utilicé un OR fue cuando nuestro equipo estaba automatizando una vasta consola Web administrativa con varias páginas. Teníamos más de 100 casos de prueba por automatizar. Si no hubiéramos usado el OR, habría sido un gran reto llevarlo a cabo. Analizamos y llegamos a la conclusión de que la suite de automatización de pruebas que pretendíamos construir era el caso ideal para emplear un OR.
¿Las razones?
1. Cada uno de los casos de prueba que automatizábamos tenía varios sub-flujos en común, y por lo tanto objetos de UI asociados en común.
Como había subflujos en común, obviamente existían objetos de UI comunes en los distintos escenarios. No queríamos añadir copias de los mismos objetos de UI una y otra vez, así que decidimos reutilizar los objetos de UI.
Por ejemplo, un conjunto de casos de prueba debía navegar por los mismos enlaces del menú de navegación antes de ejecutar una serie de pasos. Por ello, planificamos tener un repositorio nombrado solo para almacenar y gestionar todos los enlaces de navegación. Así pudimos reutilizar esos enlaces de menú de navegación en un archivo OR.
2. Nos informaron que en el futuro podrían darse situaciones de actualización de la UI—por ejemplo, cambios en hipervínculos, etiquetas, etc.
Por lo tanto, queríamos asegurarnos de que, cuando ocurriera una actualización en la UI, la suite de automatización de pruebas pudiera adaptarse fácilmente y el esfuerzo de mantenimiento fuera rápido y sencillo.
Aquí es donde el OR vino a nuestro rescate: no tuvimos que hacer cambios en los repositorios de objetos de UI de cada copia del mismo objeto de UI. Cada vez que había un cambio, solo teníamos que actualizar el objeto asociado en el OR, y los scripts de prueba se ejecutaban según el objeto de UI actualizado.
3. ¡Tuvimos que construir una suite de automatización de pruebas con más de 100 scripts en un mes!
Aquí es donde entró en juego otra ventaja de usar un OR: al tomar el enfoque de construir un OR y no tener que volver a agregar los mismos objetos de UI, ahorramos tiempo. Construimos un OR bien organizado y todo lo que teníamos que hacer era construir nuestro código alrededor de los objetos que habíamos organizado en el OR.
Nos enfocamos en el objetivo del caso de prueba y en la lógica de negocio de los casos de prueba en lugar de perder tiempo reinventando la rueda añadiendo objetos para cada script de prueba. Ahorramos tiempo y finalmente entregamos la suite de automatización de pruebas en el plazo objetivo de un mes!
Mejores prácticas a seguir al usar repositorios de objetos
Ahora que conoces situaciones en las que un repositorio de objetos UI sería útil, ¿no quieres saber qué lo hace funcionar?
1. Como equipo, construyan un objetivo común de reutilización. Entiendan juntos por qué puede ayudar a su equipo de automatización, al equipo de pruebas manuales y, finalmente, al cliente.
2. Mientras desarrollan la suite de automatización de pruebas, como equipo, manténganse siempre sincronizados e informados sobre los objetos que están construyendo. Tengan un conjunto de reglas de agrupación y convenciones de nombres que todos respeten. Cuando comiencen, pueden idear un plan de cómo organizarán y almacenarán cada uno de los archivos OR. Por ejemplo, objetos del menú de navegación en un archivo OR, objetos de la página de inicio de sesión en otro archivo OR, etc. También pueden definir las convenciones de nombres de los objetos para que sean fáciles de encontrar.
3. Asegúrense de nombrar los objetos UI de tal manera que sean legibles, fáciles de encontrar y relacionar. Nombren los objetos UI de modo que cualquier persona que revise el repositorio de UI con la intención de actualizarlo pueda encontrar fácilmente el objeto. En el ejemplo de abajo, mostraré una situación así.
Cómo crear repositorios de objetos (Ejemplos)
Ahora vamos a ver cómo puedes empezar rápidamente con los repositorios de objetos. Herramientas como UFT, IBM RFT, UiPath Test Automation Suite y Power Automate tienen repositorios de objetos incorporados. Entonces, ¿por qué esperar? ¡Créeme, es súper fácil!
Aquí tienes un ejemplo donde he creado un OR con respecto al sitio web de QAL:
Observa la interfaz UI anterior: agrupé todos los widgets asociados con las acciones en la UI de inicio de sesión juntos, ya que serían comunes en varios casos de prueba. Luego, agrupé los enlaces de navegación. Si registramos estos objetos en un grupo, cuando todos los scripts de prueba utilicen definitivamente este grupo de objetos de enlaces al inicio de cada caso, estos objetos pueden reutilizarse en lugar de volver a agregarlos al repositorio
Ejemplo de uso del repositorio de objetos en UiPath
Así se ve el repositorio de objetos en la herramienta UiPath:
En este ejemplo del repositorio de objetos, he organizado los objetos de la “Página de Inicio de Sesión” en un conjunto y los “Enlaces de Navegación Principal” en otro. Con esto, si tuviera que crear varios scripts de prueba para, digamos, probar la Página de Inicio de Sesión, todos los scripts de prueba llamarían a los mismos objetos que coloqué en la “Página de Inicio de Sesión”.
Ejemplo de uso del repositorio de objetos en PowerAutomate
Así es como se ve el repositorio de objetos en la herramienta PowerAutomate:
Como mencioné antes, la clave de la reutilización también es asegurarse de nombrar los objetos de manera que sean fáciles de encontrar después. Observa el objeto UI “meprmath_quiz”. A diferencia de los otros campos, realmente no podemos identificar fácilmente a qué objeto UI se refiere. Por eso, en un caso como el anterior, aunque al agregar el objeto UI para el cuadro de texto "quiz" apareciera el nombre de campo como “meprmath_quiz”, podríamos nombrarlo como “login_add” o algo similar para que el objeto sea fácil de localizar durante la automatización y el mantenimiento del OR.
En resumen
¿Y tú, cómo usas el OR en tu herramienta favorita de automatización de pruebas? Nos encantaría saberlo.
Espero que este artículo te ayude a comprender cómo el OR ayuda al equipo a largo plazo. Tenemos la suerte de estar en una era en la que la mayoría de las herramientas de automatización de pruebas tienen la función de OR disponible. ¡Así que solo tienes que explorar cómo funciona en tu herramienta favorita!
¿Has aprendido algo nuevo en este artículo? Si quieres más artículos como este, ¡no olvides suscribirte al boletín The QA Lead!
Lecturas relacionadas:
Lista relacionada de herramientas: SOFTWARE DE PRUEBAS DE RENDIMIENTO PARA EQUIPOS DE QA
Tampoco te pierdas:
