Este contenido refiere a la charla dada por Israel Gárate durante la 9na edición del Testing en Chile.
La charla titulada «Automatizando lo imposible: Desmitificando SAP con QA Estratégico», se centró en los desafíos del aseguramiento de la calidad (QA) y la automatización en entornos SAP.
I. Introducción y contexto de SAP en la brecha del conocimiento
SAP se posiciona como un sistema ERP de utilización global, fundamental para la mayoría de las empresas del S&P 500. La implementación y el aseguramiento de la calidad (QA) en este entorno revelan una brecha del conocimiento y diferencias culturales significativas entre las organizaciones.
Se distinguen dos tipos de empresas que utilizan SAP:
1. Empresas de productos digitales: Caracterizadas por su alineación con la filosofía del software y el uso de metodologías ágiles. Sus pruebas suelen ser estructuradas, con procesos de automatización y donde la calidad forma parte de las métricas de desarrollo.
2. Empresas productoras: Enfocadas en la generación de materias primas o productos de consumo. Sus requerimientos tienden a ser tradicionales, la automatización es a menudo inexistente, y la calidad no siempre se prioriza sobre el negocio.
Una segunda brecha crucial existe entre el usuario de negocio (experto en procesos contables u órdenes de compra) y el automatizador (experto en herramientas como Tosca, UFT, Selenium o Catalon). La participación del usuario de negocio es primordial, ya que ellos aportan el know-how esencial sobre roles, datos y variantes de los casos de prueba. Si esta alineación fracasa, el riesgo principal es construir procesos automáticos que no satisfagan las necesidades reales del negocio ni aporten valor.
II. Desafíos técnicos de la automatización en SAP
La naturaleza de SAP presenta obstáculos técnicos específicos para la automatización, variando según la interfaz:
1. SAP GUI (Interfaz de Escritorio)
Esta interfaz está desarrollada principalmente para entornos Windows, lo que impone una dependencia de infraestructura de escritorio. Los identificadores de elementos pueden ser dinámicos, cambiando entre sesiones, requiriendo estrategias rigurosas de localización. El mayor reto técnico, según Gárate, son las Transacciones Z, flujos customizados o desarrollos particulares que a menudo son aplicaciones web embebidas dentro de la aplicación de escritorio, creando un híbrido complejo de automatizar.
2. SAP Fiori (Interfaz Web)
Si bien es una interfaz más moderna y web, utiliza su propia UI, complicando la sincronización de elementos. Los escenarios de prueba deben enfocarse en ciclos punta a punta (end-to-end), buscando completar procesos completos en lugar de transacciones aisladas, y se caracteriza por el uso excesivo de tablas.
III. Estrategias de ejecución remota y CI/CD
Para lograr confiabilidad y medición, la ejecución de pruebas automatizadas debe ser remota, desatendida e integrada a un flujo de Integración Continua/Despliegue Continuo (CI/CD).
El principal impedimento arquitectónico reside en las políticas de seguridad empresarial, que típicamente prohíben mantener sesiones activas de Windows 24/7. Dado que SAP GUI exige un entorno Windows activo, es imprescindible configurar un entorno RDP (Escritorio Remoto) que se abra y se cierre de forma dinámica y automática a través del pipeline. Esto requiere agentes y orquestadores con soporte para herramientas de automatización y el manejo seguro de credenciales.
Es crucial consolidar los resultados en una herramienta de gestión de pruebas (como X-ray o Azure DevOps) para vincular la ejecución a los requerimientos, proporcionando trazabilidad y cobertura. La evidencia debe ser automática (capturas o logs relevantes); de lo contrario, la automatización carece de fiabilidad.
IV. La evolución del rol QA: del silo a la colaboración holística
El éxito en la automatización de sistemas complejos como SAP depende de una transformación cultural en el enfoque de la calidad, pasando del trabajo en silos a la colaboración.
1. El movimiento Shift Left y la calidad de todos
La calidad ya no es responsabilidad única del tester. El principio de Shift Left busca involucrar la calidad y las pruebas desde las fases más tempranas del desarrollo. El QA debe comenzar a aportar desde los requisitos, haciendo preguntas interesantes e inteligentes, y no esperar a que haya código funcional.
La evolución profesional del aseguramiento de la calidad se define en tres etapas:
• Tester: Ve solo el árbol. Es un ejecutor de checklists que se centra en tareas puntuales y trabaja en silos.
• QA moderno: Ve el bosque. Tiene una visión sistémica, entiende los riesgos de producto y calidad, y comienza a colaborar y automatizar tareas.
• Quality Engineer (QE): Ve el ecosistema. Entiende el negocio, el usuario y el contexto técnico. Conecta la calidad con el valor de producto, anticipa, diseña, y es consciente de que siempre está aprendiendo.
El QA, en su rol de puente comunicativo, tiene que estudiar y entender lenguajes técnicos (ethical hacking, ciberseguridad, Git) y lenguajes de negocio.
2. Gestión de la resistencia y colaboración
La migración de SAP es un proceso de transformación profunda que implica un cambio cultural. La resistencia al cambio por parte de los usuarios es un reto constante. Para mitigarlo, es clave la colaboración conjunta con el equipo de gestión del cambio.
Una estrategia exitosa es la gamificación, donde se incentiva al usuario a encontrar errores (bugs) dándoles premios, cambiando la mentalidad de «me va a encontrar un error, qué mal» a «cada error que encontremos en las pruebas es un error menos en producción».
V. La gestión de proyectos SAP: planificación y lecciones aprendidas
Los proyectos SAP (como migraciones o cambios de versión) son «gigantes» que pueden durar años. La automatización y la calidad deben planificarse con anticipación, idealmente antes o en las fases iniciales del proyecto. La metodología SAP Activate se utiliza para guiar estos proyectos.
1. Planificación y alcance
Es vital involucrar al equipo de seguridad desde el principio para abordar las casuísticas de ejecución remota (RDP). Las decisiones clave sobre cuándo automatizar dependen de si los procesos son críticos, repetitivos y estables, y si hay tiempo suficiente. Si los procesos son inestables o cambian frecuentemente, la automatización pierde sentido.
El volumen de casos de prueba en SAP puede ser masivo (hasta 100,000 pruebas). Por ello, es necesario seleccionar un conjunto específico (suite) de pruebas para cada ejecución.
2. Desafíos operacionales y colaboración
En proyectos grandes, el equipo de QA (a menudo llamado cross de procesos y pruebas) actúa como el puente entre la parte técnica y la operación.
• Mantenimiento dual (Dual Maintenance): Es un desafío significativo porque la compañía sigue operando y desarrollando en el sistema antiguo mientras se implementa la migración (HANA). Es crucial tener claridad sobre los desarrollos que se están realizando para incorporarlos en las pruebas de regresión.
• Alineación del negocio: Los consultores SAP con experiencia en módulos específicos pueden ser reconvertidos para el rol de QA, ya que conocen el proceso del negocio, aunque deben ser capacitados en técnicas de prueba.
• Necesidad de QA: Los expertos en el panel coincidieron en que es «impensable» o «no se imaginan» un proyecto de esa envergadura sin QA, ya que este rol mitiga las posibles casuísticas que podrían aparecer en producción.
VI. Herramientas y visibilidad estratégica
La gestión de la calidad requiere herramientas que proporcionen observabilidad y trazabilidad.
1. Xray y la documentación estructurada
Xray, como aplicación de gestión de pruebas para Jira, se integra en el ciclo de desarrollo entre el manejo de requerimientos y la gestión de defectos. Permite documentar tests manuales, automatizados (Gerkin), y genéricos, agrupándolos en Test Sets y Test Plans.
Xray facilita:
• Trazabilidad: Conectar los tests a las historias de usuario y seguir el estado de ejecución.
• Gestión de defectos: Mapear los issue types de Jira como defectos (bugs) y vincularlos directamente a las pruebas fallidas.
• Observabilidad: Crear dashboards automáticamente con gadgets de Xray/Jira que muestran el estado de las pruebas (cobertura, tests por tipo, tests por estado) en tiempo real para todo el equipo y el negocio.
2. La importancia de las métricas
Lo que no se puede medir, no existe o no se puede controlar. Los indicadores de gestión (OKRs/KPIs) son la respuesta para medir la salud del proyecto y el desempeño del equipo.
Las métricas deben ir más allá del porcentaje de cobertura o el número de defectos. Los indicadores clave de calidad deben medir:
• Aporte de valor: Defectos detectados en producción (para ver si la calidad preventiva funciona).
• Eficiencia: SLA de tiempo de corrección de defectos, ranking de calidad por fábrica de software.
• Productividad: Tiempo dedicado a actividades como análisis o diseño de casos.
VII. Productividad y madurez de la función QA
La productividad se define por lograr menor tiempo, mayor alcance y contención de costos. Esto se consigue a través de la madurez de la función QA, la cual se puede medir mediante modelos como el TMMI (Test Maturity Model Integration), que va desde un nivel inicial hasta un nivel optimizado, enfocado en la prevención.
La hoja de ruta para la madurez incluye:
1. Establecimiento de una Base Sólida: Conocer y aplicar protocolos ISTQB y un lenguaje común para las pruebas.
2. Automatización estructurada: Definir una estrategia transversal a toda la organización, con marcos de trabajo base y codificación eficiente para evitar la apilación de scripts no mantenibles.
3. Gestión de indicadores: Implementar métricas que permitan la toma de decisiones informadas, detectando causas raíz que no necesariamente se limitan al área de QA (como la falta de refinamiento de historias de usuario).
En última instancia, la función QA debe evolucionar hacia la prevención en lugar de ser reactiva. La IA generativa se presenta como un aliado para potenciar la productividad (creación de datasets, prompt engineering) y para el auto-aprendizaje y auto-mejora de los modelos y scripts, asegurando que el juicio humano, crítico y ético, siga siendo indispensable.
Listado de conceptos clave (por lo menos son las que considero)
Estos términos se pueden categorizar en áreas temáticas para facilitar una comprensión estructurada:
I. Paradigmas de calidad y metodologías
La conversación se centra en la evolución del rol de QA hacia un enfoque sistémico y preventivo:
• Shift Left (Chiflet): Es el arte de anticiparse a los problemas, involucrando la calidad y las pruebas desde las fases tempranas de desarrollo, idealmente en la etapa de requerimientos.
• Testing Holístico (visión holística): Implica una responsabilidad continua del equipo y una visión que abarca el ecosistema completo. Se busca superar el trabajo en silos y fomentar la colaboración.
• Roles evolutivos de QA: Se describe la progresión desde el Tester (ejecutor de checklists que ve el árbol), al QA Moderno (que ve el bosque y colabora), hasta el Quality Engineer (QE) (que ve el ecosistema, entiende el negocio y el valor).
• Metodologías ágiles y conversación: El trabajo se articula a través de ciclos iterativos incrementales y se apoya en prácticas como BDD (Behavior-Driven Development), TDD (Test-Driven Development) y ATDD (Acceptance Test-Driven Development), destacando la importancia del refinamiento y las conversaciones.
• Madurez de la función QA: La madurez se mide a través de la adopción de protocolos ISTQB, automatización, gestión e IA, utilizando modelos como el TMMI (Test Maturity Model Integration).
II. Gestión y automatización de proyectos SAP
La gestión de la calidad en entornos SAP genera términos específicos debido a sus desafíos técnicos y de infraestructura:
• Brechas de conocimiento: Se identifican como clave la brecha cultural entre Empresas de Productos Digitales y Empresas Productoras, y la brecha entre el usuario de negocio y el automatizador.
• Proyectos estratégicos: Los proyectos SAP, como las migraciones a S/4HANA/Forhana, son gigantes que requieren planificación con anticipación y una fuerte Gestión del Cambio.
• Desafíos específicos:
◦ SAP GUI (SubGI): Interfaz de escritorio que requiere entorno Windows y donde existen identificadores dinámicos.
◦ Transacciones Z: Son los flujos customizados que representan un híbrido de desarrollo web embebido en la aplicación de escritorio.
◦ Ejecución remota: Requiere configurar entornos RDP (Escritorio Remoto) para la ejecución desatendida debido a las políticas de seguridad empresarial.
◦ Mantenimiento dual (Dual Maintenance): La necesidad de seguir desarrollando y operando en el sistema antiguo mientras se migra es un desafío superdesafiante.
• Herramientas para SAP: Se mencionan Tosca, UFT y Solman (Solution Manager).
III. Pruebas No Funcionales y Observabilidad
El enfoque moderno de QA obliga a incorporar la medición y la validación de aspectos no relacionados con la funcionalidad:
• Pruebas No Funcionales: Incluyen la validación de rendimiento (performance), integración, seguridad (ciberseguridad) y accesibilidad (adaptabilidad digital).
• Performance Engineering: Se centra en el tiempo de respuesta (siendo 3 segundos un límite excesivo y 1 segundo lo ideal), el throughput y la tasa de errores (error right). Requiere probar hipótesis y revisar constantemente la arquitectura.
• Observabilidad: Es fundamental para entender el comportamiento del sistema y buscar la causa raíz del problema. Las herramientas de gestión de pruebas como Xray y Jira facilitan la trazabilidad y la cobertura.
• CI/CD: La ejecución automática de pruebas ligeras en el pipeline (Integración Continua/Despliegue Continuo) es esencial para la prevención.
IV. Inteligencia Artificial (IA) y Agentes
La integración de la IA transforma la naturaleza del software y el proceso de prueba:
• Sistemas No Deterministas: A diferencia de los sistemas tradicionales, la IA genera variabilidad de resultados (múltiples respuestas para una sola entrada).
• Desafíos de QA en IA:
◦ Sesgos: Problemas reales, como el caso de Amazon, donde los datasets están desbalanceados o incompletos, comprometiendo la equidad (Fairness).
◦ Falta de explicabilidad: Los modelos son a menudo cajas negras, dificultando entender el procesamiento de los resultados.
• Métricas para IA: Se necesita comprender métricas estadísticas como la Precisión, Recall, y el F1 Score para medir el riesgo de falsos positivos o falsos negativos.
• Agentes de IA: Son software que piensan, planifican y actúan, y pueden autoevaluarse o automejorarse. Su desarrollo utiliza patrones de diseño (como el patrón React para razonamiento y acción).
• Model Context Protocol (MCP): Es un protocolo unificado estándar que da brazos a la IA, permitiendo a los LLM (Large Language Models) interactuar con herramientas, bases de datos (resources) y ejecutar tareas, incluso automatizando la creación de código.
La charla de Israel inicia en el track 1:15:00 y finaliza en 1:48:50
