Cómo implementar una estrategia de pruebas E2E exitosa.

Hace un tiempo, en otro artículo, te contamos la importancia que tiene en nuestra empresa la automatización de pruebas, el tipo de arquitectura de pruebas utilizamos, las tecnologías que adoptamos y sus ventajas.

En este post te mostraremos cómo implementamos una estrategia de automatización de pruebas en un proyecto de migración de una solución monolítica no documentada (legacy) a una de microservicios. Basándonos en esta evaluación empírica compartiremos cuáles son los principales beneficios de automatizar pruebas, la inversión requerida, los resultados cuantitativos que obtuvimos y su comparación con las pruebas manuales en la reingeniería de un producto.

Beneficios y costos de la automatización

En la actualidad, la industria del software intenta acelerar los ciclos de desarrollo para obtener entregables en corto tiempo y maximizar el retorno de las inversiones. Si bien, día a día, surgen nuevas técnicas, tecnologías y metodologías que permiten acelerar estos ciclos, las pruebas tradicionales se han vuelto un cuello de botella. Esto ha forzado a la industria a considerar a las pruebas como “time-boxed tests” poniendo en riesgo la calidad de los productos de software. Por esto, las empresas de software necesitan descartar las técnicas de pruebas tradicionales y moverse hacia una estrategia que reduzca los tiempos de prueba sin poner en riesgo la calidad del producto.

Los beneficios de esta estrategia de automatización tanto como para las empresas como para los productos finales y clientes son evidentes. Sin embargo, la inversión inicial que se requiere para automatizar toda una suite de pruebas suele ser muy alta. El retorno de la inversión suele demorar un tiempo y está directamente relacionado con la cantidad de ejecuciones de la suite. Por eso, se recomienda aplicar la estrategia de automatización de pruebas en proyectos de larga duración que utilicen metodologías de desarrollo incremental. Por el contrario, no se recomienda para un proyecto con otra metodología de desarrollo que contemple pocas entregas y en el que la aplicación no evolucione de manera incremental, ya que se tendría que invertir mucho tiempo para luego usar la suite automatizada pocas oportunidades durante la vida del proyecto, resultando imposible la amortización de la inversión inicial.

Estructuración de la suite de pruebas

Teniendo en cuenta que los ciclos de desarrollo al aplicar metodologías ágiles son cortos, evaluamos la implementación de una estrategia de pruebas continuas funcionales automáticas. Dado que las suites de regresión son buenas candidatas para ser automatizadas, decidimos implementar una estrategia de pruebas híbridas donde la automatización fue el foco principal. Solo se definieron pruebas manuales en casos particulares donde las pruebas automatizadas no fueran candidatas. Para este desafío nos enfocamos en la experiencia de usuario y dividimos las pruebas en tres categorías según su importancia para los usuarios finales y el tamaño de la población afectada en caso de falla.

La automatización comenzó por los casos más críticos (Smoke Tests) y se extendió siguiendo el criterio de criticidad. Para poder relevar la importancia de cada escenario en la experiencia de usuario, nos basamos en el histórico de defectos reportados por el usuario tanto en la solución legacy como en aplicaciones similares.

Capacitación de equipos

Además de las consideraciones relacionadas con la estructuración de las suites, la necesidad de capacitar a los equipos en estas tecnologías es un punto importante al momento de migrar de pruebas manuales a automatizadas. En este proyecto, nos enfrentamos a dos situaciones diferentes: la participación de una persona con más de 8 años de experiencia en pruebas manuales, pero sin conocimientos de automatización; y, la colaboración de otra persona sin experiencia laboral previa. En el primer caso, nos apoyamos en sus conocimientos puros de aseguramiento de la calidad. Este valor nos ayudó al momento de priorizar los casos de prueba y optimizarlos generando pruebas eficientes que redujeron los tiempos de ejecución. Mientras tanto, se capacitó a esta persona en las nuevas tecnologías durante los 10 meses que tomó llegar a una cobertura del 100% de los casos de prueba automatizados. En el segundo caso, la persona involucrada no poseía conocimientos previos en aseguramiento de la calidad y por eso el enfoque fue distinto. Se priorizó su capacitación en las tecnologías, delegando los conocimientos técnicos sobre aseguramiento de la calidad en otros referentes del equipo. Una vez que esta persona consiguió la madurez necesaria para automatizar casos de prueba definidos por otros, comenzó su capacitación en aseguramiento de calidad. En 5 meses, esta persona logró contribuir de manera activa en la automatización de casos de prueba.

Los resultados que obtuvimos

Antes de iniciar este proyecto de automatización de pruebas, para ejecutar el ciclo completo de pruebas se necesitaban 5 personas por release y les tomaba 2 semanas finalizar esta acción. Tras 9 meses de trabajo, se automatizó la suite de pruebas manuales y el ciclo de pruebas pudo completarlo solo 1 persona en un solo día. La fórmula del costo acumulado de los tests por número de release C(i) (Fórmula 1) se puede calcular sumando: el costo del diseño de pruebas (C_D), la implementación (C_I), el costo acumulado de ejecución de pruebas (C_E(i)) y los costos acumulados multiplicados por el mantenimiento de las pruebas (C_M(i -1)).

En la siguiente tabla se muestra la comparación de la cantidad de horas destinada a cada tipo de suite.

Si analizamos el costo acumulado de las pruebas manuales y las automatizadas podemos ver que al sexto release del proyecto el costo de ambas suites se iguala. De aquí en adelante, notamos que el costo de pruebas manuales excede el de las automatizadas.

Otra característica que vale la pena evaluar es la evolución de la suite de pruebas automatizadas en el tiempo. Como se muestra en la siguiente figura, al mes de iniciada la automatización, disponíamos de la suite de Smoke Tests completamente automatizada. Al ejecutar esta suite de manera automática en el pipeline de integración continua y antes de promover la aplicación al entorno de pruebas, se detectaron defectos críticos de manera temprana. Luego de 4 meses, la suite de Sanity Tests estaba completamente automatizada. Esto permitía detectar defectos importantes de manera automática al momento de desplegar la aplicación en el entorno de pruebas. Por último, a los 9 meses la suite de Regression Tests se encontraba también completamente automatizada. Dado que esta suite toma 4 horas en completarse, se ejecuta periódicamente todas las noches. Esto facilita la identificación diaria de los defectos introducidos en la aplicación el día anterior.

Dado que en este proyecto era muy difícil construir datos sintéticos para pruebas, se optó por usar datos reales de la base para la automatización. Como consecuencia, los datos de prueba son altamente dependientes del tiempo (fechas) tal como puede observarse en la figura a continuación.

A medida que el tiempo transcurre, deja de haber datos de prueba válidos y se debe actualizar la base de prueba con datos reales del entorno productivo. Obsérvese el descenso de casos de prueba fallidos, a fines de julio 2021, al realizar dicha actualización. También se aprecia el incremento de los casos de prueba fallidos el 12 de julio, debido a un problema de integración en la aplicación. Con este reporte, se pudo encontrar y resolver defectos en menos de 24 hs.

Conclusión

El mayor rendimiento de la suite de pruebas automatizadas se obtiene al ejecutarlas de manera frecuente. Esto se puede lograr al integrarla en un pipeline de despliegue continuo con el objetivo de tener un feedback constante de la calidad del producto en construcción. Por otro lado, es muy importante capacitar a los equipos involucrados en técnicas de aseguramiento de calidad y en herramientas de automatización para que puedan reducir el tiempo dedicado a las pruebas manuales y concentrarse en una mayor comprensión de las reglas de negocio. Contar con pruebas automatizadas mitiga la gran rotación de recursos de la industria y reduce su impacto directo en la calidad del proyecto, ya que traslada el conocimiento del negocio a la suite automatizada de pruebas (un activo que pertenece a la organización) y el conocimiento deja de estar presente únicamente en quienes participan del proyecto.