Cómo los equipos financieros prueban los recorridos de usuario seguros sin comprometer la seguridad.

En las aplicaciones financieras, los aspectos más importantes —autenticación, control de acceso y flujos de trabajo seguros— son también los más difíciles de probar.

Estas no son capas opcionales. Definen cómo interactúan los usuarios con la aplicación.

Además, introducen limitaciones que los métodos de prueba estándar no siempre manejan bien.

La seguridad forma parte de la experiencia del usuario.

El proceso de inicio de sesión en una aplicación financiera no se limita simplemente a un nombre de usuario y una contraseña.

Puede incluir autenticación biométrica, autenticación multifactor, validación de sesión y comprobaciones a nivel de dispositivo.

Cada uno de estos pasos puede comportarse de manera diferente dependiendo del dispositivo, el sistema operativo y el entorno.

Al mismo tiempo, muchas aplicaciones se distribuyen a través de sistemas empresariales y se rigen por políticas que influyen en su funcionamiento.

Las pruebas deben tener en cuenta todo esto, no solo si la funcionalidad subyacente funciona.

Por qué los equipos simplifican las pruebas

En la práctica, muchos equipos adaptan su enfoque de pruebas para gestionar la complejidad.

• La autenticación puede omitirse para acelerar la ejecución.
• Las funciones de seguridad pueden desactivarse para evitar inestabilidad.
• Se pueden utilizar compilaciones separadas para aislar la funcionalidad.

Estas decisiones suelen tomarse por razones prácticas. Permiten que las pruebas se lleven a cabo sin generar gastos generales adicionales.

Pero también modifican las condiciones bajo las cuales se valida la solicitud.

Se dedica una cantidad considerable de esfuerzo a investigar fallos en lugar de ejecutar pruebas. Cuando las pruebas no reflejan las condiciones reales, la investigación se vuelve aún más difícil.

El papel de los entornos gestionados (MDM)

Un aspecto que a menudo se pasa por alto es la realización de pruebas en entornos gestionados.

Muchas aplicaciones financieras se implementan a través de sistemas de administración de dispositivos móviles como Microsoft Intune o VMware Workspace ONE. Estos sistemas aplican políticas, configuran dispositivos y controlan el acceso.

Esto afecta al comportamiento de la aplicación.

Por ejemplo, es posible que se requieran certificados para la autenticación, que las funciones estén restringidas según las políticas establecidas y que las configuraciones de red difieran de las configuraciones estándar.

Las pruebas realizadas fuera de este contexto pueden pasar por alto estas variaciones.

En muchos casos, las plataformas de prueba se basan en dispositivos no administrados, que no reflejan estas restricciones. Como resultado, el comportamiento que solo se observa en entornos administrados no se valida antes del lanzamiento.

Probar aplicaciones robustas se ha convertido en una verdadera limitación.

Otro reto que se ha vuelto más común en las aplicaciones financieras es probar software que incluye protecciones o técnicas de ofuscación en tiempo de ejecución.

Estas medidas de protección están diseñadas para evitar manipulaciones, ingeniería inversa y accesos no autorizados, y en muchas organizaciones financieras son obligatorias.

El problema es que a menudo interfieren en la forma en que las herramientas de prueba interactúan con la aplicación.

Para solucionar este problema, los equipos pueden desactivar las protecciones, usar compilaciones especiales o recurrir a la validación parcial. Sin embargo, una vez eliminadas las protecciones, la aplicación ya no se comporta como lo hace en producción.

Esto introduce un tipo de riesgo diferente, uno en el que los problemas relacionados con las capas de seguridad nunca se validan antes del lanzamiento.

A medida que más organizaciones adoptan el endurecimiento de las aplicaciones como parte de su estrategia de seguridad, esto se está convirtiendo en una restricción estándar que las pruebas deben tener en cuenta.

Para ver más a fondo cómo se puede abordar este desafío en la práctica, vea cómo Digital.ai lo abordó en Pruebas automatizadas y fortalecimiento de aplicaciones: una solución DevSecOps dilema.

¿Cómo sería un enfoque más realista?

Un enfoque más eficaz se centra en alinear las condiciones de prueba con las condiciones de producción.

• Los flujos de autenticación se ejecutan a medida que se utilizan, incluidos los datos biométricos y la autenticación multifactor (MFA).
• Las aplicaciones se prueban con las protecciones habilitadas, en lugar de depender de versiones modificadas o no seguras que no reflejan el comportamiento en producción.
• Los dispositivos se configuran con las mismas políticas y restricciones que experimentan los usuarios, incluidos los controles MDM.
• Las pruebas se realizan en una variedad de dispositivos y entornos para detectar la variabilidad.

Esto no necesariamente aumenta el número de pruebas. Lo que cambia es lo que esas pruebas representan realmente.

Por qué esto mejora la toma de decisiones

Cuando las pruebas reflejan las condiciones reales, los resultados son más útiles.

• Los fallos son más fáciles de interpretar porque se producen en escenarios realistas, incluidos flujos seguros y entornos gestionados.
• El tiempo de investigación disminuye porque el contexto ya está disponible.
• Release Las decisiones pueden basarse en pruebas que coincidan con el comportamiento de la aplicación en producción.

Mejorar la calidad de esa señal tiene un impacto directo en la rapidez con la que los equipos pueden comprender los fallos y tomar decisiones sobre los lanzamientos.

Equilibrar la seguridad y la capacidad de prueba.

A menudo se da por sentado que probar aplicaciones seguras requiere hacer concesiones.

O bien se mantiene la seguridad y se limitan las pruebas, o bien se amplían las pruebas reduciendo las restricciones de seguridad.

En la práctica, esta disyuntiva suele estar motivada por limitaciones en las herramientas o en la configuración del entorno, más que por una restricción fundamental.

Es posible probar aplicaciones seguras, gestionadas y protegidas sin comprometer su integridad, pero esto requiere un enfoque que tenga en cuenta cómo se ejecutan realmente estas aplicaciones en producción.

👉 ¿Ya te enfrentas a estos desafíos? Hable con un experto en pruebas. para analizar tu entorno y los próximos pasos. 

👉 ¿No estás seguro de si tu enfoque actual funciona? Toma la ruta Cuestionario de preparación para pruebas móviles.