La importancia de un buen patrón de diseño POM en la automatización de pruebas (con ejemplo al final)

Por Francisco Nava

Nota del editor: Este artículo forma parte del volumen 01. Al final del artículo, encontrarás un video de demostración y un ejemplo de código proporcionados por Francisco para complementar la lectura.

Vivimos en una época en la que la mayoría de los procesos se están automatizando, permitiendo que se realicen mediante aplicaciones que funcionan desde computadoras de escritorio hasta relojes inteligentes. Por ello, en las empresas se ha incrementado la demanda tanto de desarrolladores como de testers que aseguren la calidad y el funcionamiento esperado de dichas aplicaciones.

Debido a que todas las aplicaciones desarrolladas en las empresas pasan por un riguroso proceso utilizando diferentes metodologías, es necesario planificar una estrategia que se adapte perfectamente a cada aplicación para poder realizar las pruebas pertinentes y asegurar la calidad. Esta estrategia debe contemplar tanto pruebas manuales como pruebas automatizadas.

En cuanto a las pruebas automatizadas, hay que tener en cuenta algunas consideraciones:

• Solo se deben planear para aplicaciones que ya tienen cierto grado de madurez, ya que no tiene sentido planificarlas para una aplicación que está a punto de lanzarse.

• Preferiblemente, se deben planear las pruebas para flujos y/o procesos de negocio de la aplicación que ya han sido previamente probados por testers manuales.

• Cada prueba debe tener un máximo de 15 pasos para que las ejecuciones sean rápidas y ofrezcan un buen rendimiento.

Si la aplicación cumple con estas características, el equipo de testing automatizado se encargará de planificar una solución que permita ejecutar las pruebas utilizando algún framework de código abierto o cerrado, y un IDE para escribir todo el código que controlará las ejecuciones. Dicha solución debe contener un POM, de modo que todos los scripts estén alineados entre sí, facilitando la comprensión y el mantenimiento del código.

¿Qué es POM?

POM es un patrón de diseño que, como su nombre lo indica (Page – Object – Model), permite tener un objeto por página. En otras palabras, el código escrito para controlar los elementos de una página es completamente independiente de otro.

A diferencia del método convencional, donde en un solo script se escribía el código para controlar más de una página, el patrón POM es más útil, ya que al tener cada página seccionada por objeto, permite una mejor reutilización del código y evita por completo la redundancia. Además, facilita el mantenimiento y otorga un mayor control sobre el proyecto, por lo que un buen diseño de patrón POM es crucial al planificar pruebas automatizadas.

Un buen POM se puede construir de la siguiente manera, considerando esta estructura:

• Locators (Carpeta): Esta carpeta contendrá todos los elementos de todas las páginas en forma de diccionario. Se recomienda crear un diccionario por cada página.

• Methods (Carpeta): Esta carpeta contendrá las páginas principales, tales como la “Login page”. Se recomienda crear un objeto por cada página.

• Business Processes (Carpeta): Esta carpeta contendrá todas las páginas para ejecutar los flujos de la aplicación. Se recomienda crear un objeto por cada página.

• Sections (Carpeta): Esta carpeta contendrá secciones compartidas entre páginas, tales como menús hamburguesa, encabezados, pies de página, etc. Se recomienda crear un objeto por cada sección.

• Test Cases (Carpeta): Esta carpeta contendrá todos los scripts. La característica principal es que cada script tendrá pocas líneas de código, ya que cada línea será una referencia a algún proceso de negocio. En otras palabras, cada línea será una llamada a otra sección de código que ahora sí contendrá las instrucciones para controlar los elementos de la página.

• Test Data (Carpeta): En esta carpeta se almacenarán archivos Excel o de cualquier otro formato que provea datos para ejecutar las pruebas.

• Utilities (Carpeta): En esta carpeta se almacenarán las funciones para controlar el driver del navegador.

• Results (Carpeta): En esta carpeta se almacenarán todas las evidencias de las ejecuciones.

En conclusión, tener un buen POM en nuestros proyectos de automatización permitirá que el mantenimiento del código sea mucho más amigable, escalable y reutilizable. Además, hará que las personas involucradas sean más productivas y eficientes, ya que siempre es más satisfactorio trabajar con código bien estructurado y siguiendo buenas prácticas que con código redundante y poco organizado.

Nota del editor: Aquí encontrarás el ejemplo de la implementación de un patrón de diseño POM para la ejecución de pruebas automatizadas de una aplicación de e-commerce.

Este es el Git donde puedes ver el ejemplo del artículo.

A continuación puedes ver un video de demostración:

---

Mi nombre es Francisco Javier Nava y me apasiona el desarrollo de aplicaciones web y móviles, y he acumulado más de 4 años de experiencia trabajando en el área de testing.

Actualmente, estoy promoviendo mi framework de automatización de pruebas, Frankenstein Test Lab, una interfaz gráfica que permite ejecutar scripts de Selenium, Appium y Playwright con solo un par de clics, sin necesidad de un IDE o servidor de pruebas, lo que hace la automatización más accesible para cualquier usuario.

Este proyecto fusiona mis conocimientos en automatización y desarrollo web, ya que mi framework es una aplicación web capaz de ejecutar código de las librerías más populares para la automatización de pruebas.