Pruebas E2E, la forma de garantizar que un negocio está asegurado

En este artículo, analizaremos cómo las pruebas E2E pueden ser clave a la hora de asegurar un negocio. Os explicamos por qué estas pruebas son tan importantes y cuál es el procedimiento:

Dentro de un sistema SW conviven muchas partes o componentes, cada uno con una actividad diferenciada al resto, pero que trabajan en conjunto para hacer posible la funcionalidad para la cual se ha diseñado ese sistema.

Habitualmente un sistema comunica con otros dentro de un mapa de sistemas más o menos grande, que conforma un conjunto dedicado a satisfacer las necesidades para las que se diseñó este pequeño universo de actores que realizan un trabajo colaborativo.

Estas necesidades son las que componen habitualmente el negocio como tal del propietario del mapa de sistemas, y ya en este nivel no tiene sentido hablar de componentes, hablamos de flujos de negocio.

En este punto nos podemos preguntar: ¿Nuestra responsabilidad como QA Assurance es que todos los componentes de todos los sistemas, y todos los sistemas de un mapa de sistemas funcionen correctamente?

No. Nuestra responsabilidad es que, aparte de funcionar correctamente de forma aislada (comprobación con pruebas unitarias), el todo funcione. Nuestra responsabilidad, en definitiva, es que el negocio esté asegurado, y la forma de garantizarlo es mediante los test E2E.

Con estas premisas y metodología trabajamos en MTP en todos aquellos encargos del entorno del Digital Business Assurance, principalmente aseguramiento de la calidad (QA), pero también en otras áreas como DevOps & Agile, ciberseguridad o experiencia de usuario (UX).

Detección de errores en las Pruebas E2E

El objetivo de este conjunto de pruebas de software es el mismo que cualquier otro tipo de prueba: la detección de errores en todas y cada una de las fases (diseño y desarrollo, en las pruebas de integración, en la fase de ‘end testing’, etc). Pero la perspectiva E2E nos permite dar un paso más y, aparte de errores con una visibilidad más o menos inmediata, podremos determinar la existencia de indefiniciones funcionales o errores ocultos.

En las pruebas E2E detectamos principalmente:

• Errores en la definición de la comunicación de dos sistemas: Un sistema envía unos parámetros, pero el sistema con el que se comunica espera recibir otros y se genera un error.
• Ausencia de un sistema: No tenemos la versión actualizada de un sistema que forma parte del flujo de negocio a probar, o no se ha tenido en cuenta que ese sistema debe participar o debe modificarse.
• Error en la definición del funcionamiento del flujo funcional: Todos los componentes y sistemas funcionan ‘ok’, hemos ejecutado la prueba de principio a fin sin errores, pero el resultado final es incoherente con el esperado. Esta es la gran potencia del conjunto de pruebas E2E, la detección de errores de definición y la solución suele pasar por una redefinición del proceso.

Manos a la obra con el E2E testing

Una vez entendidas las particularidades y el objetivo de esta clase de pruebas de software, por ejemplo para un desarrollo web, describamos los puntos relevantes a la hora de plantearlas.

El equipo de pruebas E2E

Para la composición del equipo de pruebas E2E, seleccionaremos perfiles que cumplan principalmente tres requisitos:

• Expertise QA: Los recursos que diseñen y ejecuten este tipo de pruebas no deben ser junior, sino que deben tener experiencia en testing manual que aplicarán a este escenario más complejo.
• Analistas funcionales: Primaremos el perfil funcional frente al técnico. El perfil con facilidad de aprendizaje y entendimiento del proceso en conjunto, frente a las partes.
• Buenos comunicadores: Un aspecto vital, la resolución ágil de los errores detectados en un escenario con muchos actores de sistemas diferentes, solo será posible si el perfil que prueba es capaz de comunicar debidamente los errores de la forma adecuada, y a los interlocutores válidos.

El diseño de las pruebas

Ya tenemos el equipo conformado, y ahora queremos hacer un diseño de plan de pruebas o tipos de test que contemplen todas las validaciones necesarias a realizar, por ejemplo, en el desarrollo web citado. Conceptos a tener en cuenta en nuestro diseño:

• Flujo funcional: Proceso en el que se define un comportamiento a partir de unas entradas, y un tratamiento de esas entradas por parte de todos los sistemas o componentes, hasta llegar a un resultado final.
• Camino crítico: En un flujo funcional participan normalmente muchos sistemas o componentes. Sería un error pretender hacer la validación del todo, porque por una parte normalmente no hay tiempo material para hacerlo, y por otra, muchos de los sistemas no tienen relevancia. El camino crítico lo componen sólo los sistemas a validar en mi prueba E2E.
• Sistemas a validar: Nos encontraremos 3 tipos de sistemas a validar en mi prueba E2E del flujo funcional, y que definirán el camino crítico:
  • Sistemas que modifican SW: Aquellos sistemas que van a modificar el comportamiento del flujo y que por tanto son objeto principal de la prueba.
  • Sistemas de entrada y salida de datos: Sistemas en los que operamos y comprobamos resultado. Independientemente de que se modifique SW en ellos, son necesarios para la ejecución correcta de la prueba.
  • Sistemas intermedios con criticidad alta: Aquellos sistemas que sin tener una modificación SW, ni ser entrada, ni salida de datos, tienen una criticidad importante en el proceso y es necesaria su corroboración.

Nuestro plan de pruebas se diseñará teniendo como objetivo la validación de un flujo funcional, y por pasos, la operación y validación en los sistemas contenidos dentro del camino crítico.

La Fase de Ejecución

Tenemos equipo conformado, diseño de plan de pruebas realizado, y llega el día de arranque de ejecución. Nuestra ejecución ya está guiada por nuestro diseño, y sólo queda validar y operar en los sistemas ya marcados. No obstante para que la etapa de ejecutar pruebas sea exitosa, es necesario profundizar en varios puntos importantes:

• El entorno de pruebas: Nuestro escenario exige un entorno estable de pruebas ya que cualquier intervención en una parte de los sistemas, puede modificar e invalidar nuestra ejecución.
• Reporte de incidencias y bloqueos: Un aspecto vital, reportar clara e inmediatamente las incidencias detectadas al equipo que debe analizarlo y facilitar la comunicación con los equipos que pueden ser responsables de la resolución o partícipes suministrando información.
• Reporte adecuado y periódico de avances: El hecho de reportar la corrección o no de un flujo de negocio con muchos sistemas involucrados supone en muchas ocasiones que no tengamos ‘casos correctos’ hasta casi el final del tiempo de pruebas. Esto puede invitar al nerviosismo, así que una buena práctica es informar de los avances dentro del proceso, es decir, informar de ‘Oks’ en los pasos intermedios, como complemento al reporte de ‘Oks’ en la validación del flujo completo.

¿Alguna clave más a tener en cuenta?

Pues…… muchas. El escenario E2E es heterogéneo en función de tipo de cliente, tipo de proyecto, amplitud de mapa de sistemas, existencia de entornos dedicados…. No obstante apuntamos a continuación alguna clave adicional a tener en cuenta para que sea un proceso exitoso:

• Definición de proceso de pruebas: Una definición del proceso conocida por todos los actores redunda en agilidad y eficiencia. Por ejemplo, es muy importante hacer una definición del ciclo de vida de las incidencias, donde se deduzca de forma inmediata qué sistema y actor debe revisar el error reportado.
• Herramientas: Debemos apostar por herramientas que tengan información centralizada y que sirvan para registrar y mostrar los avances y bloqueos de una forma ágil.
• Formación continua: Las pruebas E2E crean una necesidad de formación en el equipo de testing muy importante. El responsable del equipo de pruebas debe planificar sesiones de formación que hagan que toda la información esté disponible para todos los integrantes del equipo.
• Regresión E2E: No sólo es importante hacer pruebas de progresión E2E, la potencialidad de estas pruebas también está en la regresión, en definitiva en asegurar que pequeños o grandes cambios a priori, no generan errores en los flujos críticos de producción.
• Automatización: De la mano del anterior punto, invertir en la automatización de los flujos E2E de la regresión, es invertir en productividad del equipo de pruebas, y además posibilita la validación de escenarios complejos de forma desatendida.

Sergio Peñalvo

Sénior Manager de MTP

Te puede interesar…

Conoce nuestros cursos de programación web y accede a formación especializada con MTP.

Ver más historias