Las pruebas de software son un mecanismo esencial para garantizar el correcto funcionamiento de nuestras aplicaciones. Existen distintos tipos de test, cada uno de ellos enfocado en evaluar una característica diferente o posee un enfoque particular.
Dentro del repertorio de pruebas que se pueden realizar en un entorno de testing, analizaremos las end-to-end (E2E). Estos test se encargan de simular escenarios reales para validar que el comportamiento de un producto final es el deseado y se ajusta a las necesidades de los usuarios que van a interactuar con ellas.
¿Para qué se utilizan las pruebas E2E?
Los test end-to-end son métodos que validan de forma exhaustiva el flujo de trabajo completo de nuestras aplicaciones. Desde la interfaz de usuario hasta la base de datos y los servicios backend, las E2E permiten que detectemos problemas de rendimiento, usabilidad y accesibilidad.
Se centran en reproducir el comportamiento de un usuario dentro de nuestras aplicaciones funcionales (sistemas desplegados en producción o entornos muy similares) para comprobar que el software en su conjunto se comporta de la manera que esperamos.
Alcance de las pruebas end-to-end
El alcance de las pruebas E2E abarca las funcionalidades críticas y de alto riesgo de nuestra aplicación. Dado que resultan costosas de mantener, su uso se enfoca en aspectos como la interfaz de usuario y sus acciones más comunes dentro de la aplicación, la comunicación entre servicios, la autenticación y autorización, integraciones con terceros y el rendimiento bajo carga.
Por ello, no debemos volcarnos en obtener una cobertura extremadamente alta haciendo uso únicamente de este tipo de pruebas. Lo ideal es complementarlas mediante test de integración y unitarios que son menos costosos y más recurrentes.
Para decidir en qué casos emplearlas, es importante que identifiquemos los recorridos claves de los usuarios. Además de ser capaces de comprender cuáles son las funcionalidades más frecuentes dentro del sistema. De lo contrario, podríamos no estar detectando el mal funcionamiento de un componente crítico en él. Ejemplos claros de casos donde resulta importante implementarlas, son los que se corresponden con las historias de usuario que hayamos desarrollado previamente para configurar nuestra aplicación.
Tipos de pruebas E2E
Las end-to-end se pueden dividir en distintos subtipos dependiendo de la característica que traten de implementar. Entre el repertorio total que existe, un buen conjunto de tipos de pruebas E2E que podemos realizar sería el siguiente:
- Pruebas funcionales: comprueban que cada característica funciona según lo descrito en los requisitos. Además de que los flujos de trabajo se realicen correctamente.
- Pruebas de usabilidad: se aseguran de que el uso de la aplicación es intuitivo.
- Pruebas de compatibilidad: evalúan si la aplicación funciona correctamente en distintos dispositivos, sistemas operativos, navegadores y versiones.
- Pruebas de rendimiento: comprueban la capacidad de respuesta y la estabilidad de la aplicación bajo distintas condiciones de carga.
- Pruebas de seguridad: detectan si existen vulnerabilidades o si los datos están siendo protegidos frente a accesos no autorizados, ataques o pérdidas.
- Pruebas de recuperación ante desastres: determinan la capacidad del sistema para restablecerse en caso de caídas o recuperarse ante fallos.
- Pruebas de conformidad: validan si el sistema cumple con las normas establecidas en el determinado sector. Por ejemplo, normativas legales o estándares de calidad. Quizás estas pruebas solo sirvan algunos entornos específicos, ya que se relacionan con las auditorías.
Como en la mayoría de enfoques de testing de un sistema, también podemos distinguir pruebas horizontales y verticales:
- Las pruebas horizontales se centran en el recorrido completo por los distintos componentes de la aplicación, simulando situaciones reales desde el punto de vista de un usuario. Los tipos más relacionados con esta categoría serían las pruebas funcionales y de compatibilidad, ya que evalúan la interacción entre los diferentes componentes del sistema.
- Las verticales se enfocan en los componentes internos de las capas individuales del sistema (servicios backend, bases de datos y middleware), probando que cada una de ellas realiza su trabajo de forma correcta. Aquí encontramos las pruebas de seguridad, de rendimiento y de recuperación ante desastres si las analizamos desde el punto de vista de procesos concretos aislados, como flujos de trabajo específicos.
Los dos enfoques anteriores pueden realizarse manualmente o mediante automatización.
Mejores prácticas
Existen unos puntos clave importantes a considerar a la hora de realizar nuestras pruebas E2E para aplicarlas de forma adecuada. Es posible que las más comunes sean las siguientes:
- Definir la cobertura de las pruebas: se trata de establecer un alcance a la hora de implementarlas para no realizar pruebas que sean menos importantes (de casos de uso que prácticamente no tengan lugar), dado que son costosas de mantener.
- Identificación de los escenarios clave: nuevamente, consiste en priorizar los escenarios más importantes, evitando probar casos poco frecuentes.
- Usar datos deterministas y conocidos: datos cuyos resultados sean predecibles y podamos anticipar sin que ocurra un cambio. O, por el contrario, que el resultado sea al azar. Esto podría aplicarse a los módulos que interactúan con componentes externos donde no sepamos si obtendremos o no un resultado concreto.
- Verificación de la comunicación entre distintos servicios: comprobar el comportamiento de sistemas conectados entre sí. Por ejemplo, APIs, bases de datos y sistemas externos.
- Autenticación y autorización: enfocados en probar el acceso de los usuarios en el sistema y sus permisos para la garantizar seguridad del mismo.
- Integración con sistemas de terceros: evaluación del comportamiento entre la aplicación y sistemas de terceros. Únicamente debe implementarse cuando se cumple que los datos que se van a obtener son predecibles.
- Rendimiento bajo cargas de trabajo elevadas: evaluación del comportamiento del sistema bajo estrés por múltiples usuarios operando en él. Sirve para detectar posibles cuellos de botella en el rendimiento.
- Pruebas continuas: se trata de realizar pruebas de forma regular y constante para asegurar que el sistema funciona perfectamente durante todo su ciclo de vida.
Considerar las mejores prácticas para realizar nuestras pruebas E2E nos permitirá ver el funcionamiento general de la aplicación. Por otro lado, seremos capaces de detectar problemas a tiempo en las partes críticas de nuestro sistema. Además, podremos determinar si el sistema final cumple los requisitos técnicos y empresariales antes de su puesta en marcha.
Vulnerabilidades principales
Pese a que son muy importantes, las pruebas E2E presentan algunos inconvenientes que pueden dificultarnos su implementación y mantenimiento:
- Lentas y de alto coste debido a que simulan todo el flujo de la aplicación. Por eso, es necesario el empleo de más recursos para usarlas que con otro tipo de pruebas.
- Frágiles ante cambios e interacciones con el exterior. Pueden presentar fallos por cambios en la interfaz de usuario. O, incluso, generar resultados menos predecibles cuando están conectadas con APIs externas.
- Pueden resultar difíciles de debuggear. Cuando la prueba falla, hay ocasiones en las que el error puede estar relacionado con varios componentes del sistema y sea difícil detectarlo.
- Falsos positivos o negativos. A veces, algunas pruebas no bien definidas podrían pasar aunque la funcionalidad real tenga errores si éstos no han sido detectados.
- Problemas de escalabilidad. Existe una complejidad añadida en el momento en el que las aplicaciones comienzan a crecer. Esto se debe a que los conjuntos de pruebas E2E se hacen más grandes y difíciles de gestionar. Por tanto, aumenta el tiempo de ejecución de las pruebas y dificulta su ejecución en paralelo sin interferencias.
Riesgos de seguridad
A la hora de desarrollar las pruebas E2E, es importante que sepamos que existen algunos riesgos relacionados con la exposición de datos sensibles si no se siguen algunas pautas de seguridad:
- Envío de datos sensibles: puede ocurrir al interactuar con APIs externas. Se evita usando entornos de pruebas aislados (por ejemplo, simulaciones con mocking), utilizando datos falsos o registrando todas las interacciones con APIs externas.
- Exposición de datos privados: en ocasiones, las pruebas podrían requerir registros en los que se emplean datos sensibles. En ese caso, es importante usar buenas prácticas de seguridad, como las variables de entorno o gestores de secretos.
- Ataques de Denegación de Servicio (DoS): pueden producir este tipo de ataque de forma involuntaria si no están bien diseñadas. Podrían agotar los recursos del servidor entrando en bucles no controlados o consumiendo excesivamente de la base de datos.
- La exposición de APIs y endpoints también puede ocurrir. Por eso, es importante configurar entornos seguros con firewalls y autenticación. Además de implementar mocks, establecer el límite de tasa y detectar tráfico anómalo.
- Manipulación y ataques a las pruebas automatizadas: se produce cuando se inyecta código malicioso o se falsifican las solicitudes Cross-Site Request Forgery (CSRF). También cuando se manipula la ejecución de las pruebas o se aprovecha las vulnerabilidades en los entornos de prueba para atacar a la aplicación real.
Algunas tecnologías de interés
Existen numerosas herramientas para realizar pruebas E2E. Cada una de ellas tiene una serie de características que se enfocan en abordar diferentes necesidades. Quizás, algunas de las más recurrentes a día de hoy sean las siguientes:
- Selenium: podría resultar más complejo de usar en comparación con otras opciones más adaptadas a un perfil menos técnico. Sin embargo, es extremadamente flexible y personalizable. Es la herramienta más adecuada para proyectos grandes.
- Katalon Studio: es una solución muy sencilla, ya que posee un grabador de pruebas con el que no es necesario escribir código. Además, su interfaz es muy intuitiva. Sin embargo, no es demasiado flexible para pruebas complejas.
- Cypress: a diferencia de otras herramientas, se ejecuta dentro del navegador, lo que lo hace más rápido y eficiente. El nivel de dificultad podría ser intermedio, ya que usa JavaScript pero tiene interfaz de usuario.
- Playwright: al igual que Cypress, se ejecuta en el navegador, pero es más rápido. A diferencia de éste, se ejecuta en diferentes pestañas y ofrece soporte nativo para múltiples navegadores.
La lista de herramientas continúa y entre ellas existen diferencias que debemos entender para seleccionar la que mejor se ajuste a nosotros. Por ejemplo, si son o no de software libre, simples o complejas, rápidas o lentas, o qué navegadores soportan.
Conclusión
Como hemos visto en este post, las pruebas E2E son una parte muy importante del testing software. Nos permiten asegurar la calidad y confiabilidad de nuestras aplicaciones, simulando el comportamiento de un usuario real y los resultados que debe obtener.
Sin embargo, resulta imprescindible combinarlas con pruebas unitarias y de integración, dado que su coste en términos de tiempo y recursos es elevado. Te invito a que pongas en práctica este tipo de pruebas para evaluar si tus aplicaciones son robustas y cumplen con tus expectativas.
