Calidad y pruebas de software

5.1 Resumen y propósito

Este capítulo establece el marco de Calidad y Pruebas de Software (SQT) que rige cómo el Proveedor asegura la corrección funcional, la integridad del rendimiento y la fiabilidad de los datos de ProjectVIEW ERP antes de cada despliegue en el entorno de Producción del Cliente.

Ningún Release, Update o Upgrade (según se define en Capítulo 1, §1.4) podrá promoverse a Producción sin completar satisfactoriamente el ciclo de pruebas descrito en este documento.

El Proveedor opera una metodología de pruebas diferenciada y aumentada con IA que aprovecha AI Testing Agents personalizados, construidos sobre el marco de pruebas propietario del Proveedor para interactuar directamente con cada instancia de ProjectVIEW ERP del Cliente. Este enfoque permite la simulación automatizada de flujos de datos de extremo a extremo, escenarios realistas de interacción de usuario y una validación integral de la integridad de los datos, capacidades que superan con creces la QA manual convencional o basada en scripts.

Además de la prevención de defectos, el marco SQT incorpora un servicio proactivo de Asesoría de Optimización de Procesos, mediante el cual se analizan los resultados de los agentes de IA para identificar ineficiencias en los flujos de trabajo, anomalías de configuración y oportunidades de mejora del modelo de datos dentro de cada despliegue del Cliente. Estos hallazgos se entregan como recomendaciones accionables durante las Revisiones Trimestrales del Servicio (§3.9).

5.2 Alcance

El marco SQT se aplica a todos los artefactos de software desplegados en los entornos del Cliente bajo este Marco, incluidos, entre otros:

• (a) Releases/Updates (v11.xx) — cambios incrementales específicos del cliente entregados mediante sprints ágiles de 3 días (§4.7).
• (b) Upgrades (v11 → v12) — cambios de versión mayor para todo el producto entregados aproximadamente una vez al año (§4.8).
• (c) Cambios de configuración — activación de módulos, personalización de flujos de trabajo, plantillas de informes y ajustes de roles y permisos.
• (d) Artefactos de migración de datos — transformaciones de importación, scripts ETL, parches de migración de esquema.
• (e) Interfaces de integración — puntos finales de API, controladores de webhooks, adaptadores de conectores de terceros.
• (f) Cambios de infraestructura — actualizaciones del motor de base de datos, upgrades de versiones de middleware, rotaciones de certificados TLS.

El marco SQT cubre tanto las pruebas internas del Proveedor (§5.4–§5.7), realizadas antes de la UAT del Cliente, como la Prueba Universal de Aceptación de Usuario del Cliente (§5.8), que actúa como la puerta formal de preparación para Producción.

5.3 Marco de pruebas aumentado con IA

5.3.1 Resumen de la arquitectura

El Proveedor utiliza una plataforma de pruebas de IA diseñada específicamente que comprende tres capas principales:

5.3.2 AI Testing Agents

A cada instancia de ProjectVIEW ERP de un Cliente se le asigna uno o más AI Testing Agents personalizados, configurados con conocimiento específico del dominio del Cliente sobre:

• Configuración de módulos: módulos activados (por ejemplo, Project-Management, Contract-Management, Quality-Management) y sus interdependencias.
• Reglas de negocio: flujos de aprobación, matrices de escalamiento, reglas de notificación y fórmulas de cálculo específicas de los requisitos operativos del Cliente.
• Esquema de datos: campos personalizados, tablas de búsqueda, dominios de valores codificados y restricciones de integridad relacional configurados en la instancia del Cliente.
• Taxonomía de roles: roles de usuario, conjuntos de permisos y reglas de segregación de funciones aplicables a la organización del Cliente.
• Mapa de integración: sistemas de terceros conectados (contabilidad, RR. HH., gestión documental, BI) y sus contratos de intercambio de datos.

Los agentes de IA se versionan junto con la base de código de la aplicación utilizando la estrategia de branching Git del Proveedor (Master → Client → Working branches, §4.7.2), lo que garantiza que las configuraciones de prueba evolucionen en paralelo con el software que validan.

5.3.3 Integración segura de API

La capa de integración segura de API proporciona la capa de comunicación estructurada entre los AI Testing Agents y ProjectVIEW ERP, permitiendo:

• (a) Invocación de API: Los agentes invocan las APIs REST/GraphQL de ProjectVIEW para crear, leer, actualizar y eliminar registros, simulando transacciones reales de usuario sin depender de la interfaz de usuario.
• (b) Inspección de base de datos: Acceso de solo lectura a la base de datos Dev/Sandbox del Cliente para validar restricciones de integridad de datos, consistencia referencial y campos calculados después de la transacción.
• (c) Hooks de automatización de la interfaz de usuario: Cuando la lógica de negocio está estrechamente acoplada al front-end (por ejemplo, visibilidad condicional de campos, validación dinámica de formularios), la capa de integración canaliza las instrucciones del agente a través de una interfaz de navegador sin cabeza que renderiza fielmente la interfaz de usuario de ProjectVIEW.
• (d) Captura de eventos: Todas las interacciones entre el agente y el ERP se registran en una pista de auditoría inmutable, incluidos los payloads de solicitud, los códigos de respuesta, las métricas de tiempo y los resultados de las aserciones.

Las conexiones API se autentican mediante tokens de API de corta duración y con ámbito restringido que conceden solo los permisos necesarios para el conjunto de pruebas actual. Los tokens se rotan automáticamente por cada sesión de prueba y no pueden utilizarse contra entornos de Producción.

5.4 Metodología de pruebas

5.4.1 Niveles de prueba

El ciclo de pruebas del Proveedor abarca cinco niveles progresivos, cada uno con criterios de entrada, criterios de salida y responsabilidades definidos:

5.4.2 Entornos de prueba

Todas las pruebas del lado del Proveedor (L1–L4) se ejecutan exclusivamente en el entorno Dev/Sandbox dedicado del Cliente (§2.5.1). Este entorno es:

• Arquitectónicamente idéntico a Producción, con la misma versión del motor de base de datos, pila de middleware y build de la aplicación.
• Poblado con datos anonimizados equivalentes a producción, con volumen y variedad suficientes para ejercitar casos límite realistas sin exponer datos personales.
• Aislado, sin conectividad de red con Producción; con namespace DNS y realm de autenticación separados.
• Restaurable, con capacidad de snapshot/restore que permite ejecuciones repetibles de pruebas desde una línea base conocida y correcta.

Después del Go-Live, el entorno Dev/Sandbox pasa a un rol de Staging (§2.5.1), conservando todas las propiedades anteriores y sirviendo además como entorno de UAT para el Cliente.

5.5 Simulación integral de flujo de datos

5.5.1 Objetivos de la simulación

Los agentes de IA simulan flujos de datos realistas de extremo a extremo que recorren todo el ciclo de vida de una transacción de negocio dentro de ProjectVIEW ERP. Los objetivos son:

• (a) Validar que los datos creados en un módulo se propaguen, transformen y estén disponibles correctamente en todos los módulos posteriores.
• (b) Confirmar que las reglas de negocio (cadenas de aprobación, notificaciones, cálculos) se ejecutan correctamente en cada etapa.
• (c) Verificar que las acciones concurrentes de los usuarios no provoquen condiciones de carrera, interbloqueos ni corrupción de datos.
• (d) Medir la latencia y el rendimiento de las transacciones frente a los umbrales SLO definidos (§3.3).

5.5.2 Escenarios de simulación

El Proveedor mantiene una biblioteca de escenarios de simulación parametrizados, cada uno mapeado a un proceso de negocio central de ProjectVIEW. La siguiente tabla ilustra escenarios representativos; la biblioteca completa se adapta por Cliente en función de los módulos activados y su configuración:

5.5.3 Carga de datos y ejecución del escenario

Antes de cada ejecución de simulación, los agentes de IA realizan de forma autónoma:

• (a) Cargar datos previos necesarios: crear registros maestros (proyectos, proveedores, usuarios, códigos de coste) requeridos como entradas para el escenario en prueba.
• (b) Ejecutar la cadena de transacción: invocar las APIs de ProjectVIEW a través de la capa de integración segura de API para realizar cada paso del proceso de negocio en la secuencia correcta, con valores de datos y intervalos de tiempo realistas.
• (c) Asertar en cada punto de control: después de cada paso, el agente consulta la base de datos y/o la API para confirmar que se ha producido el cambio de estado esperado (registro creado/actualizado, flujo de trabajo avanzado, notificación enviada).
• (d) Capturar evidencia: cada llamada a la API, consulta a la base de datos, resultado de aserción y medición de tiempo se registra en un repositorio inmutable de evidencias de prueba vinculado al ticket de despliegue.
• (e) Limpiar: al finalizar, el agente restaura el entorno a la línea base utilizando la capacidad de snapshot/restore, garantizando que ningún artefacto de prueba contamine ejecuciones posteriores.

5.6 Simulación de interacción de usuario

5.6.1 Propósito

Mientras que las pruebas a nivel de API (§5.5) validan la lógica de backend, la Simulación de Interacción de Usuario valida que la interfaz de usuario de ProjectVIEW se comporte correctamente cuando la operan usuarios humanos. Los agentes de IA replican interacciones de usuario realistas, entre ellas:

• Cumplimentación de formularios con datos válidos, no válidos y de valor límite.
  • Navegación por flujos de trabajo de varios pasos (wizards, cadenas de aprobación, secuencias de carga de documentos).
  • Aplicación de accesos basados en roles: los agentes impersonan usuarios con distintos conjuntos de roles y permisos para confirmar que los elementos de la interfaz se muestran u ocultan, habilitan o deshabilitan correctamente.
  • Comportamiento adaptable: pruebas en tamaños de viewport de escritorio y tableta para confirmar la integridad del diseño.
  • Cumplimiento de accesibilidad: verificación de que la navegación por teclado, los atributos ARIA y las relaciones de contraste cumplen los requisitos WCAG 2.1 AA.

5.6.2 Escenarios de interacción

Las simulaciones de interacción de usuario se estructuran alrededor de scripts de prueba basados en perfiles:

5.6.3 Clasificación de defectos

Los defectos identificados durante la simulación de interacción de usuario se clasifican usando la misma taxonomía de severidad que los incidentes operativos (§4.3):

5.7 Validación de integridad de datos

5.7.1 Alcance

La integridad de los datos se valida en tres niveles después de cada ejecución de prueba y antes de cualquier promoción del despliegue:

5.7.2 Aserciones de integridad

El AI Testing Agent ejecuta las siguientes aserciones de integridad al cierre de cada escenario de simulación:

(a) Cero huérfanos: las consultas SELECT en todas las tablas puente e hijas confirman que ningún registro hace referencia a registros padre inexistentes. (b) Verificación de balances: para los módulos financieros, el total de débitos es igual al total de créditos dentro de cada centro de costes; presupuesto comprometido + real + remanente = presupuesto total. (c) Integridad de secuencia: las secuencias con numeración automática (números de documento, IDs de transacción) no contienen saltos ni duplicados. (d) Seguridad de concurrencia: los hilos paralelos de agentes que ejecutan actualizaciones en conflicto producen resultados deterministas y correctos con las respuestas de bloqueo optimista apropiadas. (e) Cifrado en reposo: los campos sensibles (PII, datos financieros) se almacenan cifrados en la base de datos; el texto plano solo está disponible a través de la capa de descifrado de la aplicación.

5.7.3 Informe de integridad de datos

Cada ciclo de prueba genera un Informe de Integridad de Datos automatizado que contiene:

• Total de aserciones ejecutadas y recuento de aprobados/suspensos.
  • Registros detallados de fallos con tabla, columna, ID de registro, valor esperado y valor real.
  • Análisis de tendencias comparando las puntuaciones de integridad de los últimos diez ciclos de prueba para identificar patrones de degradación.
  • Acciones de remediación adoptadas, corregidas automáticamente frente a escaladas al desarrollo.

Los Informes de Integridad de Datos se adjuntan al ticket de despliegue y se incluyen en el paquete de evidencias de UAT proporcionado al Cliente.

5.8 Pruebas universales de aceptación de usuario (UAT)

5.8.1 Requisitos previos de UAT

El Proveedor no invitará al Cliente a iniciar la UAT hasta que se cumplan los siguientes requisitos previos:

• (a) Todos los niveles de prueba L1–L4 se han completado sin defectos P1/P2 pendientes.
• (b) El Informe de Integridad de Datos (§5.7.3) muestra una tasa de aprobación de aserciones del 100%.
• (c) El entorno Staging del Cliente se ha refrescado con el build candidato.
• (d) Las plantillas de casos de prueba, los datos de prueba y las credenciales de usuario se han preparado y comunicado al responsable de UAT designado por el Cliente.

5.8.2 Ejecución de UAT

La UAT es ejecutada por los representantes designados del Cliente utilizando el entorno Staging. El Proveedor deberá:

• Proporcionar plantillas estructuradas de casos de prueba alineadas con los procesos de negocio del Cliente.
  • Preparar datos de prueba realistas que reflejen escenarios de producción sin exponer datos personales.
  • Poner el Service Desk a disposición para el registro de defectos, triage y resolución durante la ventana de UAT.
  • Asignar un recurso dedicado de QA del Proveedor como enlace de UAT, disponible para soporte en tiempo real a través del grupo compartido de WhatsApp Business (§4.4) y el Sistema de Ticketing Integrado (§4.1).

5.8.3 Aprobación de UAT

No se procederá con ningún despliegue a Producción sin una aprobación escrita de UAT del representante autorizado del Cliente. El documento de aprobación deberá confirmar que el Cliente ha validado la liberación frente a sus criterios de aceptación y autoriza su promoción a Producción.

Si el Cliente no proporciona la aprobación o el rechazo dentro de los diez (10) Días Hábiles posteriores a la fecha de inicio de la UAT, el Proveedor emitirá un recordatorio por escrito. Si no se recibe respuesta dentro de cinco (5) Días Hábiles adicionales, se considerará que la liberación ha sido aceptada por el Cliente.

5.8.4 Gestión de defectos de UAT

Los defectos identificados durante la UAT se gestionan a través del Sistema de Ticketing Integrado (§4.1) y se clasifican según la taxonomía de severidad del §5.6.3. Se aplican las siguientes reglas:

• Defectos P1/P2: Bloquean la conformidad de UAT. El Proveedor deberá subsanar y volver a presentar la funcionalidad afectada dentro del ciclo de sprint en curso.
  • Defectos P3: No bloquean la aprobación. El Proveedor los remediará en el sprint siguiente y confirmará la resolución al Cliente.
  • Defectos P4: Se registran en el backlog. La remediación se programa en función de la capacidad disponible y del aporte de prioridad del Cliente.

5.9 Asesoría de optimización de procesos

5.9.1 Resumen

Una capacidad exclusiva habilitada por el marco de pruebas potenciado con IA del Proveedor es la posibilidad de generar información práctica para la optimización de procesos derivada del análisis de los datos de ejecución de pruebas. Este servicio transforma las pruebas, de un mero control defensivo de calidad, en una actividad proactiva de creación de valor para el Cliente.

5.9.2 Generación de insights

Durante la ejecución de pruebas, los agentes de IA capturan y analizan continuamente:

• (a) Patrones de latencia de las transacciones: Identificación de pasos del flujo de trabajo que consumen de forma constante un tiempo de procesamiento desproporcionado, lo que indica posibles cuellos de botella en las reglas de negocio o en los patrones de acceso a datos.
• (b) Frecuencias de excepciones: Catalogación de fallos de validación, rechazos por reglas de negocio y denegaciones de aprobación para poner de relieve puntos de fricción del proceso que pueden indicar reglas mal configuradas o una guía de usuario poco clara.
• (c) Anomalías de calidad de datos: Detección de patrones de registros incompletos, uso excesivo de valores predeterminados o errores sistemáticos de captura de datos que sugieren rediseño de formularios o ajustes de campos obligatorios.
• (d) Conflictos de permisos: Identificación de combinaciones de rol y permisos que generan cuellos de botella innecesarios en las aprobaciones o, por el contrario, brechas en la segregación de funciones.
• (e) Funcionalidades infrautilizadas: Señalización de módulos o funcionalidades activados que están configurados pero no se ejercitan en escenarios de prueba realistas, lo que indica posibles carencias de formación o costes de licencia innecesarios.

5.9.3 Entrega de recomendaciones

Las recomendaciones de optimización de procesos son:

• Compilado: En un Process Optimisation Report estructurado tras cada gran ciclo de pruebas (Sprint Release o Upgrade).
  • Clasificadas: Por impacto (alto/medio/bajo), esfuerzo (cambio de configuración, desarrollo menor, desarrollo mayor) y riesgo (sin riesgo, bajo riesgo, requiere UAT).
  • Presentadas: Al Cliente durante la Quarterly Service Review (3.9) por el Service Delivery Manager.
  • Registradas: Como acciones en el registro de Continuous Service Improvement (CSI) (4.10), con plazos y responsables acordados.

5.9.4 Limitaciones del alcance

El Process Optimisation Advisory se proporciona con carácter informativo. La implementación de cualquier recomendación constituye un cambio de configuración o una solicitud de desarrollo regida por los procesos aplicables de gestión de cambios y planificación de sprints (4.6, 4.7). El Proveedor no implementará cambios de optimización sin la aprobación del Cliente y, cuando corresponda, sin una formal Scope Change Request (2.7).

5.10 Gobernanza e informes de pruebas

5.10.1 Repositorio de evidencias de prueba

El Proveedor mantendrá un repositorio centralizado e inmutable de evidencias de prueba para cada Cliente, que contendrá:

• Planes de prueba y especificaciones de casos de prueba para cada despliegue.
• Registros de ejecución de los agentes de IA (trazas completas de interacción con la API, marcas de tiempo y resultados de las aserciones).
• Informes de integridad de datos (5.7.3).
• Informes de optimización de procesos (5.9.3).
• Paquetes de evidencias de UAT (resultados de casos de prueba, registros de defectos, documentos de conformidad).
• Historial de evolución de la suite de regresión (casos de prueba añadidos, modificados o retirados de forma obsoleta).

Las evidencias de prueba se conservarán durante la vigencia del Framework más doce (12) meses, o durante el plazo exigido por la normativa aplicable de protección de datos (GDPR Art. 5(1)(e); UAE PDPL Art. 5), lo que sea más largo.

5.10.2 Métricas de calidad

El Proveedor hará seguimiento e informará de las siguientes métricas de calidad, incluidas en la Quarterly Service Review (3.9):

5.10.3 Mejora continua

El framework SQT está sujeto a mejora continua de acuerdo con el ciclo de Deming (Plan-Do-Check-Act):

• (a) Planificar: La estrategia de pruebas y las configuraciones de los agentes de IA se revisan y actualizan al inicio de cada trimestre en función de las tendencias de las métricas de calidad y de los comentarios del Cliente.
• (b) Hacer: Las suites de prueba actualizadas y las configuraciones de los agentes se despliegan en el entorno Staging del Cliente.
• (c) Comprobar: Las métricas de calidad (5.10.2) se evalúan frente a los objetivos; se realiza un análisis de causa raíz en cualquier incumplimiento.
• (d) Actuar: Las acciones correctivas y preventivas se registran en el CSI register (4.10) y se ejecutan en los ciclos de sprint posteriores.

5.11 Seguridad y cumplimiento

5.11.1 Protección de los datos de prueba

Todos los datos de prueba utilizados en el proceso SQT están sujetos a las obligaciones de protección de datos de este Framework (Capítulo [Protección de datos — referencia futura de capítulo]). En particular:

• Los datos de producción deberán anonimizarse o pseudonimizarse antes de utilizarse en entornos no productivos, de conformidad con el GDPR Art. 89(1) y el UAE PDPL Art. 5.
• Los agentes de IA no almacenan datos del Cliente más allá de la sesión de prueba. Todos los datos procesados por AI Testing Agents son efímeros y se purgan al finalizar la sesión.
• Los tokens de API se limitan al mínimo de permisos necesarios, tienen vigencia temporal y se revocan automáticamente al final de la sesión.
• Los registros de evidencias de prueba se cifran en reposo (AES-256) y en tránsito (TLS 1.3).

5.11.2 Gobernanza de agentes

El uso de agentes de IA por parte del Proveedor en el framework SQT se rige por:

• EU AI Act Compliance: Los agentes de IA utilizados para pruebas de software se clasifican como de riesgo mínimo conforme al EU AI Act (Regulation (EU) 2024/1689), ya que operan sobre datos no productivos en un entorno controlado y no toman decisiones autónomas que afecten a personas físicas.
• NIST AI RMF: La metodología de pruebas con IA del Proveedor se ajusta a los principios de validez, fiabilidad y rendición de cuentas del NIST AI Risk Management Framework (AI RMF 1.0).
• Human Oversight: Los agentes de IA operan bajo supervisión humana. Todos los resultados de las pruebas, las recomendaciones de optimización y las decisiones de despliegue requieren revisión y aprobación humana antes de actuar.
• Transparency: El Proveedor deberá, a solicitud del Cliente, proporcionar documentación de las configuraciones de los agentes de IA, la lógica de decisión y los registros de interacción de cualquier ciclo de prueba.

EU AI Act — Regulation (EU) 2024/1689 NIST AI Risk Management Framework 1.0

5.12 Registro de procesos

5.12.1 Registro de procesos

5.12.2 Matriz RACI

R = Responsible | A = Accountable | C = Consulted | I = Informed

5.12.3 Flujo del proceso — ciclo de vida de la calidad de software y las pruebas