Patrones de automatización de pruebas de software y buenas prácticas

Te mostramos cómo asegurar que la automatización de pruebas no solo promueva que el equipo trabaje más rápido, sino también en la dirección correcta, con una combinación idónea de herramientas, patrones de automation y prácticas.

La automatización de pruebas ofrece varias ventajas: ahorro tiempo al equipo, recursos y evitar inconvenientes que provoca hacer todo manualmente. Sin embargo, la automatización de pruebas por sí sola no garantiza el éxito. Si no configuras las pruebas de la manera correcta, terminarás con los mismos malos resultados (¡pero mucho más rápido!).

En este artículo te mostramos algunos patrones y mejores prácticas para la automatización de pruebas, para que puedas asegurarte de que tu equipo está obteniendo el máximo valor de los esfuerzos de automatización.

Revisión del código de prueba (Test Code Review)

Las pruebas (a nivel de unidad, API, UI y rendimiento) deben revisarse para analizar su calidad y encontrar discrepancias o malas prácticas. Por ejemplo, un conjunto de pruebas podría estar cumpliendo con los criterios de cobertura, invocando suficientemente las secciones de código previstas, pero si no se escriben las afirmaciones adecuadas, las pruebas serán ineficientes para identificar problemas (es decir, solo ejecutarán el código y no analizar si lo que hace es bueno o no).

La práctica de la revisión del código de prueba también permite que otra persona con una nueva perspectiva agregue más pruebas que evalúen otros aspectos del sistema, y también verifique que los requisitos del sistema sean claros y se cumplan.

Aplicar aserciones (assertions)

Las aserciones marcan la diferencia entre un test que solo prueba el código y uno que realmente identifica problemas. Cada herramienta de automatización de pruebas verifica las respuestas brindando claridad sobre si una prueba ha fallado.

Por otro lado, también es mejor prestar especial atención en la definición de assertions para evitar falsos negativos y falsos positivos, ya que una aserción demasiado genérica puede resultar en pruebas inexactas o no válidas.

Behavior-Driven Development (BDD)

BDD se refiere al desarrollo impulsado por el comportamiento. Como su nombre lo indica, esta no es una técnica de prueba, sino una estrategia de desarrollo (como TDD, desarrollo basado en pruebas).

Se debe establecer un lenguaje común para que el negocio y los ingenieros sean el punto de partida para el desarrollo y el testing. Por lo general, las historias de usuario se definen y luego se utilizan como base para la creación de casos de prueba. Más allá de la posibilidad de automatización, el enfoque debe estar en el uso de ciertos requisitos comerciales que luego pueden transformarse en pruebas de aceptación.

Una ventaja obvia de BDD es que los desarrolladores tienen especificaciones claras, por lo que pueden concentrarse en lo que se debe hacer, y de qué manera, a nivel empresarial. Al igual que TDD donde tienen un método junto con las pruebas, con BDD ya hay una “prueba de aceptación” a nivel comercial.

Otra ventaja del enfoque BDD es que brinda capacidad de prueba al sistema. Pensar las funcionalidades de forma independiente (de manera completa e involucrando a todas las capas del sistema) guía a un tipo de desarrollo que facilita las pruebas.

Patrón de Page Object para pruebas de UI

Cuando se trabaja con automatización en cualquier nivel, es fundamental centrarse en la escalabilidad y la capacidad de mantenimiento de una solución. Es decir, no debería tomar más tiempo resolver inconvenientes o actualizar un framework de automatización que el tiempo ahorrado por la ejecución automática. Para lograrlo, el uso correcto de los patrones de diseño es crucial.

Al escribir test automatizados, se comienza a generar código que contiene mucho conocimiento sobre la estructura de la aplicación, como los ID de campos, botones y enlaces, etc. Con el tiempo, la aplicación escalará y se modificará, por lo que es importante que las pruebas se pueden mantener con el mínimo esfuerzo.

El patrón de objetos de página le permite reutilizar este conocimiento de la aplicación mientras hace que cada cambio en el patrón tenga un impacto mínimo en las pruebas. Consiste en desacoplar por completo lo que concierne a la estructura de la interfaz de usuario del código de prueba, y encapsular esta información en objetos que representan elementos de la interfaz de la aplicación. De esta forma, el Page Object Pattern fortalece las pruebas.

Siguiendo un enfoque de BDD, este tipo de patrones también deberían aplicarse, ya que son prácticas complementarias. Esto también se aplica a cualquier validación automatizada a nivel de interfaz gráfica, independientemente de si se utiliza Selenium (para web), Appium (para mobile) o cualquier otra herramienta.

Data-Driven Testing

Si bien las pruebas basadas en datos van más allá de un patrón de diseño e implican un enfoque de testing completo, las incluimos en este post como parte de las buenas prácticas de programación.

Esencialmente, las pruebas automatizadas están parametrizadas para que los mismos pasos puedan ejecutarse con diversas cantidades de datos de prueba. De esa manera, agregar datos al archivo de datos crea nuevos casos de prueba.

El mayor beneficio de hacer esto se produce cuando se ejecuta la misma secuencia de pasos con diferentes conjuntos de datos, parametrizando tanto los datos de entrada como los datos de salida esperados.

Ejecución paralela de Pruebas

Las pruebas unitarias y las pruebas de nivel de API generalmente se ejecutan más rápido que las pruebas de interfaz de usuario. Por otro lado, las pruebas automatizadas a nivel de interfaz gráfica requieren acceso end-to-end al sistema y un manejo de elementos de interfaz, por lo que requieren mayor tiempo de ejecución. Es por eso que diferentes estrategias como la ejecución en paralelo (Parallel execution) se han vuelto realmente útiles.

Si trabajas en una aplicación web y automatizas con Selenium (la herramienta más popular), es una buena práctica usar Selenium Grid. Con sus múltiples nodos, Selenium Grid tiene la ventaja de combinar fácilmente los sistemas operativos con varios navegadores que acceden a la aplicación. Esto lleva a ejecutar varias pruebas en paralelo utilizando Grid, lo que reduce el tiempo de prueba.

Al combinar Selenium Grid con cualquier herramienta de integración como Jenkins, las pruebas se activan al conectarse a Grid y se ejecutan en cada nodo. Los resultados se almacenan en relación con la tarea (trabajo en la terminología de Jenkins) y realizan un seguimiento de las ejecuciones.

Estos son solo algunos patrones y buenas prácticas a considerar para mejorar la automatización de pruebas de software.

Con la combinación correcta de herramientas y prácticas, puedes avanzar teniendo la certeza que la automatización de pruebas está impulsando a tu equipo en la dirección correcta.

¿Cuáles son las prácticas de automatización de pruebas que has encontrado útiles? ¿Algún consejo que quieras aportar? ¡Déjanos un comentario y lo sumaremos a este post!