[04/01/2022] Los ingenieros de automatización de control de calidad prueban aplicaciones desarrolladas internamente, desde monolitos heredados hasta aplicaciones nativas de la nube que aprovechan los microservicios. Una aplicación típica de misión crítica requiere una combinación de pruebas unitarias a nivel de código, revisión de código, pruebas de API, pruebas automatizadas de experiencia del usuario, pruebas de seguridad y pruebas de rendimiento. La mejor práctica de DevOps es automatizar la ejecución de estas pruebas y luego seleccionar un subconjunto óptimo para las pruebas continuas dentro de los pipelines de CI/CD (integración continua y entrega continua).
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Pero ¿qué pasa con las aplicaciones, los flujos de trabajo, las integraciones, las visualizaciones de datos y las experiencias de usuario configuradas mediante plataformas SaaS (software como servicio), herramientas de desarrollo de código bajo o plataformas sin código que empoderan a los desarrolladores ciudadanos? El hecho de que haya menos o ninguna codificación involucrada, ¿implica eso automáticamente que los flujos de trabajo funcionan según se requiere, el procesamiento de datos cumple con los requisitos comerciales, las configuraciones de seguridad se alinean con las políticas de la empresa y el rendimiento cumple con las expectativas del usuario?
Esta pregunta me recuerda algo que nos enseñó mi profesora de cálculo de la escuela secundaria. Ella diría: "Si asumes algo, entonces te burlas de ti y de mí”. En los casos de SaaS, de código bajo y sin código, asumir que la aplicación funciona como se requiere sin un plan de prueba puede generar muchos problemas:
- Molestias y frustraciones en las partes interesadas con resultados inesperados.
- Agujeros de seguridad que exponen los datos al público o a los empleados que no deberían tener acceso.
- Problemas de datos que pueden propagarse a otros flujos de trabajo integrados y experiencias del cliente.
- Problemas de rendimiento cuando la aplicación se adapta a muchos usuarios y conjuntos de datos más grandes.
- Frustración en los equipos de TI llamados para reelaborar aplicaciones o desarrollar soluciones alternativas.
Entonces, ¿qué se debe probar? ¿Cómo se pueden probar estas aplicaciones sin acceso al código fuente subyacente? ¿Dónde debería priorizar las pruebas TI, especialmente teniendo en cuenta que muchas organizaciones de DevOps no tienen suficiente personal en ingeniería de control de calidad?
Hablé con varios expertos para que me ayudaran a encontrar algunas respuestas.
Empiece por definir e implementar pruebas ágiles de aceptación
John Kodumal, CTO y cofundador de LaunchDarkly, les recuerda a los miembros de TI que las pruebas de aceptación deben aplicarse a todas las aplicaciones soportadas por TI, no solo a las que requieren desarrollo de software. Él señala: "en un modelo SaaS tradicional, el equipo de desarrollo realiza pruebas de aceptación como parte del procedimiento de prueba de lanzamiento normal”.
La definición de pruebas de aceptación empresarial y de usuarios es un lugar importante para comenzar porque la mayoría de las aplicaciones de SaaS, código bajo y sin código requieren configuración, y la implementación puede seguir scrum u otra metodología ágil. Las disciplinas ágiles incluyen requisitos de redacción, como historias de usuario con criterios documentados de aceptación aprobada o reprobada. Un equipo ágil debe gestionar la historia de un usuario ágil como un pequeño contrato funcional del negocio y requisitos no funcionales.
La definición de los criterios de aceptación es un primer paso importante y debe seguirse incluso para las aplicaciones SaaS que no requieren codificación o configuración limitada.
Pero suponga que TI no asume las responsabilidades de definir los criterios de aceptación y automatizar estas pruebas. En estos casos, la falta de pruebas crea riesgos o los equipos comerciales asumen la tarea de realizar pruebas. Ninguno de estos es óptimo. TI debe ser el departamento responsable de liderar la implementación, incluidas las funciones de prueba.
El código bajo y sin código requieren poner a prueba la lógica de negocio
Las plataformas de código bajo y sin código proporcionan una capa de abstracción y simplifican el desarrollo, el soporte y la mejora de las aplicaciones. Pero al usar estas plataformas, todavía está codificando la lógica del negocio, configurando un flujo de trabajo, definiendo reglas de procesamiento de datos y eligiendo roles de acceso. La plataforma realiza la simplificación, pero aún existe el riesgo de que el desarrollador implemente la lógica de manera incorrecta o no sepa completamente cómo cumplir, con precisión, los requisitos en la plataforma de código bajo o sin código.
Kodumal añade que las pruebas agregan dos responsabilidades adicionales. "Probar una solución de código bajo se enfoca en probar dos cosas diferentes: poner a prueba la lógica de negocio que expresa el usuario de código bajo y probar que la estructura que soporta la solución de código bajo está funcionando correctamente. Estos dos tipos de pruebas garantizan que la aplicación funcione de la forma en que los usuarios finales esperan que funcione".
Puede probar la lógica empresarial con herramientas que capturan las interacciones del usuario a través del navegador y automatizan la prueba de estos flujos. La prueba de la estructura subyacente puede requerir revisiones de los modelos de datos, permisos, formularios, informes y automatizaciones para garantizar que cumplan con los estándares y no presenten riesgos.
Andrew Clark, director de tecnología de Monitaur, sugiere que las pruebas de automatización deben centrarse en el flujo de trabajo y en cómo la aplicación soporta un proceso empresarial. Él afirma: "Una buena forma de probar SaaS y aplicaciones de código bajo es realizar una validación básica de input y output. Deberá crear una matriz de eventos/acciones clave que esperamos que realice el sistema y configurar casos de prueba para validar que el sistema está funcionando como se esperaba”.
Rosaria Silipo, directora de evangelismo de ciencia de datos en KNIME, lleva esto un paso más allá y sugiere que las aplicaciones sin código y con código bajo deben seguir estándares de prueba similares. Ella afirma: "una aplicación de código bajo debe venir con su propio conjunto de pruebas, que debe seguir exactamente las mismas pautas que para las aplicaciones basadas en código: unidades de prueba, tablas doradas, salida elegante, etc. Crear un servicio web sin un código de falla en la respuesta o una aplicación web sin una salida elegante en caso de error es poco profesional, exactamente como lo sería para una aplicación basada en código”.
Utilice plataformas de prueba de código bajo y aprendizaje automático
Aunque desarrollar con código bajo y sin código a menudo acelera el proceso de desarrollo y permite mejoras más fáciles, los equipos de DevOps aún deben realizar pruebas y revisiones de configuración.
La buena noticia es que los ingenieros de control de calidad pueden desarrollar pruebas con plataformas de prueba de código bajo. Ram Shanmugam, director ejecutivo de AutonomIQ, una empresa de Sauce Labs afirma: "con las pruebas de código bajo, usted está utilizando técnicas avanzadas de inteligencia artificial y aprendizaje automático, por lo que el proceso de escritura y mantenimiento de scripts de prueba es realizado a través de máquinas. Esto puede reducir significativamente el tiempo y el costo involucrados, al tiempo que disminuye su dependencia de los ingenieros de automatización de pruebas, ya que los codificadores normales, e incluso los que no son codificadores, ahora pueden generar scripts de automatización de pruebas. En última instancia, los evaluadores ahora pueden centrarse en las necesidades de negocio del software y garantizar que se mantenga la intención del usuario”.
Cómo las plataformas SaaS y de código bajo automatizan las pruebas
Si está probando la experiencia de usuario, la lógica de negocio, el procesamiento de datos y la configuración de su SaaS o aplicación de código bajo, ¿es eso una validación suficiente de calidad, confiabilidad y seguridad?
La calidad general también depende de cómo la plataforma de código bajo o el proveedor de SaaS prueben su tecnología y administran la infraestructura y los servicios subyacentes en la nube. La mayoría de los proveedores de plataformas comparten sus certificaciones de seguridad, niveles de servicio y credenciales de cumplimiento, como ISO, SOC, GDPR, PCI y FedRamp. Los principales proveedores también comparten sus programas de lanzamiento, notas de lanzamiento, defectos conocidos, registros de nivel de servicio y acceso a páginas web para verificar el estado del tiempo de actividad. Pero no muchos proveedores brindan detalles sobre su arquitectura, estándares de desarrollo y prácticas de prueba.
Hablé con Martin Laporte, vicepresidente sénior de investigación y desarrollo en Coveo, para discutir su enfoque de pruebas e implementaciones. Él afirma: "en un mundo donde los componentes de las plataformas SaaS se actualizan varias veces al día, la capacidad de observación es clave para detectar cualquier cambio en el comportamiento, como mayores tasas de error o variaciones en los tiempos de respuesta. Siempre que se detecte una anomalía, las implementaciones deben interrumpirse con una reversión automática de la versión de trabajo anterior”.
Esa es una barra alta para la frecuencia de implementación y las prácticas de prueba y lo que espera que otras plataformas SaaS y de código bajo tengan como objetivo. Este nivel de pruebas, complementado con los esfuerzos de automatización de pruebas del equipo de desarrollo, ayuda a reducir los riesgos de implementación, especialmente para aplicaciones que requieren alta confiabilidad.
En pocas palabras: si no está probando una aplicación de código bajo o SaaS, bueno, es posible que esté haciendo demasiadas suposiciones.
Basado en el artículo de Isaac Sacolick (InfoWorld) y editado por CIO Perú
Puede ver también: