Como construir una suite de pruebas E2E robusta y mantenible

Un conjunto de pruebas que funciona de manera óptima requiere una priorización eficaz. Probablemente no tengas un presupuesto infinito para un equipo de automatización de QA.

El mantenimiento de la Test Suite de pruebas E2E puede ser costoso y lento, y puede requerir una cantidad considerable de trabajo manual. Una de las mejores maneras de facilitar el mantenimiento de tus suites E2E es priorizar lo que realmente agregara valor en las ejecuciones.

Algunas empresas insisten en ejecutar innumerables pruebas E2E innecesarias. He visto ejecutar muchas que realmente no aportan valor.

En estas situaciones, reviso el conjunto de pruebas y pregunto: “¿Por qué no se trata de una prueba de nivel inferior a E2E?” La respuesta a algunas veces es: “Bueno, nos comentaron que tenemos que manejarlos como pruebas E2E”. Un punto de vista seria, enfocar las pruebas al producto y las características que les interesan a los usuarios.

Google ha publicado varios artículos sobre esto. Sugiere una estructura piramidal, donde tiene un número limitado de pruebas E2E, un buen número de pruebas de integración y un gran número de pruebas unitarias de nivel inferior. Las pruebas de nivel inferior son más baratas de construir, son más fáciles de mantener y producen comentarios de mayor calidad.

No tiene sentido construir una prueba E2E cuando una prueba de nivel inferior será suficiente. Las pruebas E2E son de misión crítica. Pero la mayoría de las pruebas deben asegurarse de que los componentes específicos funcionen, por lo que deben ser pruebas de nivel inferior. Cuando trabajes con la filosofía de “utilizar siempre las pruebas de nivel inferior cuando sea necesario”, podrás crear un conjunto de pruebas ágiles, eficientes y actualizadas.

 

Optimiza el mantenimiento a tus Test Suites.

También he visto fallar el mantenimiento de las suites de pruebas porque todas las solicitudes de actualización de casos de prueba se incluyeron en una lista de tickets de JIRA sin ninguna prioridad u organización. En dicho sistema, de esa forma se trabaja en las cosas más fáciles, en lugar de lo más importante. El equipo de pruebas se puede atrasar con lo importante, incluidos los casos de prueba que esperan actualización.

Además de organizar el tamaño de las suites de pruebas con los recursos disponibles, puedes dividir el mantenimiento de las pruebas en tres tipos: actualización de código, estabilidad y mantenimiento a largo plazo. La categorización del mantenimiento en estas formas te permitirá optimizar el trabajo para cada categoría al tener diferentes procesos y reglas de priorización.

 

Actualización de código

Utiliza la actualización de código cuando los desarrolladores necesiten realizar cambios en la interfaz de usuario (UI). Si algo importante sobre la IU cambia, o si el flujo de trabajo que se prueba cambia, la prueba fallará porque no podrá encontrar el elemento con el que está tratando de interactuar.

Cuando los cambios en la interfaz de usuario surjan, debes tener una forma de comunicación entre los desarrolladores y el equipo de QA, que informe los próximos cambios en la interfaz de usuario. Esta retroalimentación debe ocurrir después del diseño y antes del desarrollo. Tu equipo de QA ahora podrá anticipar estos cambios y responder con pruebas actualizadas listas para enviar antes de que se haya creado el cambio de UI.

El mantenimiento de actualización de código se realiza bien cuando el equipo de QA conoce los próximos cambios en la interfaz de usuario y puede prepararse para ellos.

 

Estabilidad

La clave para mantener la estabilidad en un conjunto de pruebas es no esperar hasta que la prueba falle después de la implementación. En su lugar, ejecuta tus pruebas repetidamente contra la misma versión de la aplicación. Busca cualquier inconsistencia en las pruebas UAT y prepárate para resolverla.

Para evitar el caos en implementar algo así, configura un pipeline de integración continua (CI) alternativa y ejecuta estas pruebas repetidamente en el entorno de QA, no como parte del pipeline de UAT, sino como parte de un pipeline alternativo que es específicamente para que el equipo de QA monitoree los resultados. Si tus pruebas pasan de manera rutinaria, pero algunas fallan repentinamente, ahora eres consciente de la inestabilidad en algunas pruebas y podrás resolverla.

La corrección de estas pruebas inestables debe ser una prioridad, o se degradará. La cantidad de pruebas que omites debido a su inestabilidad crecerá hasta que tengas tantas que el conjunto de pruebas se vuelva inmanejable. Para cualquier prueba que valga la pena mantener, estabilizarla debe tener prioridad sobre la creación de nuevas pruebas. De lo contrario, unos meses más adelante te encontrarás con un conjunto de pruebas que no podrás ejecutar.

 

Mantenimiento a largo plazo

El mantenimiento a lo largo del tiempo consiste en asegurarse de que tu conjunto de pruebas siempre esté alineado con los flujos de trabajo de máxima prioridad en tu aplicación.

Una de las principales causas de la degradación del conjunto de pruebas a largo plazo surge cuando se agregan constantemente nuevas pruebas cada vez que el desarrollo lanza nuevas características o cambios en la interfaz de usuario. Es cierto que, si están agregando nueva funcionalidad, necesitarás expandir tu conjunto de pruebas hasta cierto punto. Pero aquí hay un principio que es universalmente cierto que te ayudará a guiarte en la priorización de las pruebas:

Siempre ten presente el alcance de la aplicación y enfócate en lo más importante.

Identifica realmente que tanta funcionalidad se utilizara, puede que el software tenga más funciones, pero quizás se utilicen rara vez. Hay que priorizar las funciones que realmente se usaran, en lugar de simplemente agregar más pruebas.

Si sigues agregando pruebas, quizás tu equipo de QA deberá aumentar, aunque tu equipo de desarrolladores se mantendrá del mismo tamaño, y cada prueba adicional proporcionará un valor aún más marginal. Agregar continuamente pruebas a medida que modifican tu aplicación aumentara tu carga de mantenimiento de pruebas sin mejorar significativamente la garantía de calidad, por lo que la única forma de evitar que las suites de pruebas se desmoronen en esta situación, es hacer crecer constantemente tu equipo de QA con el tiempo, lo que nadie quiere hacer o tiene el presupuesto para hacer.

¿La solución? Aprender a identificar que pruebas agregaran más valor a la entrega y mantenerlas actualizadas.

 

Análisis en PRD

Si te mantienes firme a las pruebas anteriores que diseñaron, y cada prueba sigue siendo una prueba de “máxima prioridad” que debe permanecer en el conjunto de pruebas E2E, la carga de mantenimiento del conjunto de pruebas será insostenible. La inestabilidad y los tiempos de ejecución aumentarán hasta que el conjunto de pruebas se desmorone. Cuando las suites de prueba tardan demasiado en ejecutarse, las personas dejan de ejecutarlas con la frecuencia suficiente para garantizar la calidad a cualquier velocidad de desarrollo significativa. Si el conjunto de pruebas es inestable y falla, cualquier equipo de ingeniería que tenga prisa simplemente enviará a producción en lugar de pasar ocho horas analizando todas esas pruebas fallidas.

La mejor manera de evitar este escenario demasiado común es con análisis de producción. Al utilizar los datos de comportamiento del usuario en vivo de su aplicación, puedes volver a priorizar y reorientar tu Suite de pruebas a lo que realmente les importa a tus usuarios. El análisis de producción te dice exactamente qué probar en función de cómo tus usuarios realmente usan la aplicación.

 

Implementa sabiamente

Finalmente, se necesita un líder firme para poner restricciones alrededor del tiempo de ejecución o tamaño de las Test Suites en las que los equipos de QA deben trabajar. Pero hacerlo bien, el líder motivara a sus equipos a usar más datos para priorizar las pruebas de manera eficiente, en lugar de simplemente hacer nuevas pruebas. Lo más perezoso, y desafortunadamente esto es lo que hacen la mayoría de las organizaciones, es simplemente agregar nuevas pruebas. Y en ausencia de un liderazgo fuerte, basado en datos, continuarán haciéndolo.

 

Saludos Testers, desde un mundo donde cada vez son mas importantes los datos y su análisis.