La automatización de pruebas y el desarrollo ágil de software van de la mano, pero hablar de automatización es más fácil que ponerla en práctica. La mayoría de los desarrolladores reconocen los beneficios de la automatización de pruebas: acelera las pruebas, reduce los costos, aumenta la cobertura, etc. Pero en muchos casos no logran superar la inversión inicial requerida para comenzar.

Al igual que en esta caricatura, muchos equipos se atascan al usar métodos de prueba menos eficientes porque creen no tener tiempo para implementar cambios. En realidad esto termina siendo un problema que empeora aún más la situación. ¡No caigas en este mal hábito!

Hoy te compartimos una de nuestras mejores prácticas de testing para equipos ágiles: ¿Cómo empezar? ¿Cómo saber en qué áreas enfocarse? ¿Qué casos de prueba deben automatizarse? 

Pirámide de Automatización de Pruebas Funcionales de Mike Cohn

En el desarrollo de software no ágil, muchas personas terminan cayendo inadvertidamente en el “anti-patrón de cono de helado” para realizar pruebas, al poner mayor énfasis en la automatización en el nivel de la interfaz de usuario.

En Abstracta, nos orientamos al enfoque que invierte el cono de helado. Estamos de acuerdo con el enfoque popularizado por Mike Cohn, la pirámide de automatización de pruebas ágiles, que proporciona un máximo rendimiento a su inversión, mejorando el ROI de la automatización y garantizando que recibas los mayores beneficios de la automatización.

Cuando la mayoría de nuestros esfuerzos se centran en la automatización a nivel de la interfaz de usuario, el objetivo es encontrar bugs; mientras que con la pirámide ágil, la idea es prevenirlos.

En la siguiente gráfica puedes visualizar las diferencias entre los dos enfoques de automatización de la pirámide de Cohn:

Nivel Inicial: Pruebas Unitarias

Claramente en la pirámide (como parte de las mejores prácticas de prueba para equipos ágiles), la mayoría de las pruebas deben tener lugar en la etapa de desarrollo, ejecutando pruebas unitarias después de cada compilación. Estas pruebas son las más fáciles, económicas y rápidas de completar y son un aspecto importante del desarrollo basado en pruebas.

Ejecutar más pruebas en un nivel más bajo nos permite “verificar nuestro trabajo” a medida que avanzamos, obteniendo feedback a un ritmo sostenido y permitiéndonos saber exactamente dónde están los errores cuando es mucho más difícil encontrarlos.

Aquí, los errores también tendrán una vida útil más corta, habiendo sido identificados y eliminados en menos de un minuto, probablemente. Durante las pruebas de la interfaz de usuario los errores habrán permanecido hasta incluso un par de días.

Nivel intermedio: API/Integración/Pruebas de componentes

Una vez que ejecutamos todas las pruebas unitarias y pasan, podemos continuar con la fase de pruebas de API/integración/componentes. Se ejecutan pruebas de integración para asegurar de que todos los componentes juntos funcionen correctamente. Aquí es donde podemos probar la mayoría de la lógica y los procesos comerciales sin pasar por la interfaz de usuario.

En este punto, es recomendable automatizar tanto como sea posible. Si tienes que decidir si automatizar en este nivel o en el nivel de la interfaz de usuario, aquí obtendrás un mantenimiento más sencillo, una ejecución de pruebas más rápida (lo que significa encontrar errores antes y disminuir su vida útil) y podrá probar la lógica del sistema.

Si bien estas pruebas son más lentas y complejas que las pruebas unitarias, son más rápidas y menos frágiles que las pruebas de UI.

Nivel superior: Pruebas de GUI

Las últimas y menos ejecutadas son las pruebas de interfaz gráfica de usuario (UI). Es mejor ejecutar la menor cantidad posible, ya que son costosas, más difíciles de preparar y mantener y requieren mucho tiempo. Aquí solo deseamos asegurarnos de que la interfaz de usuario funcione correctamente, sabiendo que todos los demás aspectos del sistema ya deberían haber sido probados.

Automatiza solo las pruebas más críticas, de un extremo a otro, con un flujo que comienza desde el inicio de sesión del usuario y termina con su acción final, como el mensaje de éxito de la transacción.

También es útil centrarse en aspectos relacionados con los navegadores o la interfaz de usuario. Ten cuidado con estas pruebas, ya que es más probable que proporcionen falsos negativos y falsos positivos. Después de ejecutar las pruebas de IU, se pueden realizar pruebas manuales y exploratorias (como se muestra en la forma circular sobre la pirámide). 

Como puedes ver, el enfoque piramidal es una forma más sólida, más beneficiosa y rentable de implementar la automatización de pruebas, que centrarse en las pruebas automatizadas de interfaz gráfica de usuario y seguir inadvertidamente el “anti-patrón de cono de helado”.

La pirámide proporciona una base sólida en la fase de pruebas unitarias, a partir de la cual se pueden construir más pruebas en las fases de integración e IU, mientras que el enfoque del cono de helado es más “pesado” en la parte superior y menos estable.

Importancia de los Equipos con una Cultura Ágil sólida

Para destacar en el mundo del desarrollo ágil, es imperativo seguir la pirámide de automatización para liberar software de la mejor calidad posible. Y es que la gran capacidad de adaptación de la metodología ágil en los equipos de trabajo, y su facilidad de implementación, permiten iniciar a trabajar de manera ágil con tu equipo y el desarrollo de una cultura organizacional en torno a la agilidad de manera integral.

Si los equipos no adoptan completamente los valores del manifiesto ágil, la aplicación de metodologías como Scrum no será óptima. Los equipos que están siendo ágiles adoptan el cambio, la innovación y el aprendizaje y la creación de valor lo antes posible. 

---

Otros contenidos relacionados

Automatización de Pruebas: el motor de la Ingeniería de Calidad

Testing Manual vs. Automatizado: ¿cuál es mejor?

Cómo elegir la mejor Herramienta de Automatización de Pruebas para tu proyecto en 5 simples pasos

Diferencias entre testing funcional y no funcional

---