Guía completa de
Test Data Management
La gestión integral de datos de prueba con icaria TDM.
Basada en el ciclo de Masterclasses de icaria Technology.
Índice de contenidos
- 01 Introducción al Test Data Management
- 02 TDM moderno: datos de prueba como producto
- 03 Los cuatro flujos fundamentales de TDM
- 04 Antipatrones y señales de alerta
- 05 Arquitectura mínima viable de TDM
- 06 Mecanismos de TDM
- 6.1 Data masking (enmascaramiento de datos)
- 6.2 Subsetting (segmentación de datos)
- 6.3 Buscador de datos y arquetipos
- 6.4 Autoservicio
- 6.5 Diseño del dato en el caso de prueba
- 07 Modelo de madurez TDM
- 08 Integración con CI/CD
- 09 Beneficios y ROI
- 10 icaria TDM: la plataforma de gestión de datos de prueba
Introducción al Test Data Management
Comprender qué es el TDM, por qué es crítico y cuáles son los retos reales que enfrentan los equipos de QA hoy.
1.1 ¿Qué es el Test Data Management?
El Test Data Management (TDM) es el conjunto de mecanismos y procesos que garantizan que los datos de prueba sean realistas, seguros, representativos, coherentes y disponibles. No se trata simplemente de copiar bases de datos de producción, sino de diseñar un sistema coordinado que haga las pruebas repetibles y seguras.
El TDM va más allá de tener datos enmascarados en copias de producción. Consiste en preparar y gestionar datasets realistas, validarlos y provisionarlos bajo demanda, manteniendo coherencia funcional y técnica entre entornos. El enmascarado protege; el TDM orquesta para que los equipos prueben con datos seguros y consistentes, tantas veces como haga falta, sin cuellos de botella y con resultados confiables.
1.2 El problema actual
El coste de contar con malos datos de prueba es alto e impacta directamente en la calidad del software. Los indicadores son contundentes:
1.3 Los retos de los equipos de QA
Los equipos de QA enfrentan múltiples obstáculos en su día a día:
- Pasan muchísimo tiempo preparando o esperando datos y aun así no es suficiente
- Los datos se crean de forma manual a través del aplicativo
- Dependen de equipos de base de datos, scripts, hojas de Excel, etc.
- Las APIs de negocio solo dan datos del "camino feliz" — datos muy sencillos
- Los ciclos de vida son cada vez más cortos (entregas en una o dos semanas)
- Entornos no productivos incompletos, desalineados y con datos de prueba inválidos
- Falta de casuísticas extremas o poco recurrentes que sí aparecen en producción
- Casos irrepetibles imposibles de generar en entornos no productivos
- Cobertura muy limitada de casos de prueba y de ejecución de pruebas
TDM moderno: datos de prueba como producto
Un cambio de paradigma: tratar los datos de prueba con la misma disciplina con la que se gestiona un producto de software.
2.1 El cambio de paradigma
El TDM moderno propone tratar los datos de prueba con la misma disciplina con la que se gestiona un producto de software: con clientes claros, con propiedad, métricas, un roadmap y una experiencia de consumo cuidada.
El objetivo es que los datos de prueba dejen de ser algo que alguien copia y pasen a ser un servicio estable, observable y con un valor medible.
Si hoy dependes de un experto en SQL para entregar datos o para que te creen datos, no tienes un producto: lo que tienes es un favor recurrente con alto riesgo.
2.2 Definiendo el producto
2.2.1 ¿Quién es el Cliente?
2.2.2 ¿Cuál es la Oferta?
El producto son Datasets de prueba listos para usar que cada uno de estos clientes puede pedir bajo demanda. El catálogo incluye:
- Datasets por dominio: clientes, pedidos, suscripciones, pólizas, pacientes
- Descripción funcional: qué casos de negocio cubren
- Autoservicio: cómo se solicita y dónde se entrega
- Políticas integradas: enmascaramiento by design
2.2.3 ¿Qué Medimos?
2.3 Cumplimiento by design
El cumplimiento by design significa que la privacidad y la regulación se incorporan al propio pipeline de datos de prueba. No como controles manuales al final, sino como pasos automáticos, medibles y auditables.
El resultado son datasets útiles para QA, sin datos reales expuestos, repetibles y con evidencia de que hacemos las cosas bien.
La coherencia no es copiar producción, no es clonar todo. Es equivalencia controlada para que una prueba que pasa en QA tenga el mismo significado en UAT (User Acceptance Testing) y en producción.
Los cuatro flujos fundamentales de TDM
Un sistema de TDM moderno se apoya en cuatro flujos que juntos garantizan datos fiables y visibles.
Es lo que hace posible que un equipo de QA o un pipeline CI/CD obtenga un conjunto de datos listo para probar.
En lugar de levantar entornos enteros o pedir favores al DBA (Database Administrator), se solicita un dataset ya preparado, enmascarado y coherente que el sistema TDM entrega.
Permite repetir pruebas con los mismos datos o volver atrás si una nueva versión rompe algo.
Cada vez que se genera o se entrega un dataset, el sistema debe dejar huella: logs, métricas, auditoría completa.
Protege los datos desde su origen, asegurando que la privacidad está incorporada en cada paso del ciclo. No es un parche posterior.
Las reglas de enmascarado se aplican automáticamente cuando los datos se extraen o se generan.
Significa poder ver, medir y auditar lo que pasa con tus datos de prueba.
Cada dataset lleva logs, métricas, estadísticas de uso y trazabilidad completa.
Si necesito 200 clientes activos con pedidos válidos, el sistema TDM me los entrega directamente, sin parar entornos y sin peticiones a terceros. La provisión bajo demanda convierte los datos de prueba en un servicio, no en una tarea manual.
Antipatrones y señales de alerta
Los hábitos que mantenemos sin darnos cuenta y que impiden avanzar hacia un sistema de datos de prueba serio. Superarlos es el primer paso para madurar en TDM.
4.1 Antipatrones comunes
Suena eficiente pero genera riesgos legales y de cumplimiento. No hay que confundir el realismo con reutilizar datos reales. Muchas veces no se dispone de la infraestructura necesaria o la seguridad de los entornos previos para hacer esa copia.
Alternativas:
- Usar subsets representativos, no la copia completa
- Aplicar enmascarado antes de mover datos
- Combinar datos reales disociados con datos sintéticos para nuevos casos
Esto te deja atado a una o dos personas que conocen el modelo y te paralizas si no están.
- Acumulan conocimiento pero no documentado
- No hay versionado ni catálogo
- Los scripts se modifican ad-hoc, añadiendo nuevos criterios
- Nada asegura que dos peticiones del mismo dataset devuelvan el mismo conjunto
- Cada iteración requiere coordinación manual
- Si hay que obtener datos de diferentes tecnologías, se vuelve imposible
Te hace perder días cada vez que el entorno se resetea. Si cada refresco de datos borra tus pruebas, es que los datos no son tuyos. Con TDM, el refresco de datos deja de ser un susto y pasa a ser un botón de aprovisionar.
Nadie sabe quién es responsable de los datos de prueba. ¿Es QA? ¿Es DBA? ¿Es Seguridad? ¿Es Infraestructura? El resultado es que todos los tocan pero nadie los gobierna. Se generan conflictos de prioridad porque QA pide más datos, Seguridad bloquea e Infraestructura se queja del tamaño.
4.2 Señales de alerta en tu organización
Pruebas que a veces pasan y a veces fallan con el mismo código porque el dato cambia, no cumple las precondiciones o es inconsistente. Si un test pasa o falla según cómo se levanta el entorno, no es un test fiable.
Solución: Entregar datos coherentes con integridad y añadiendo trazabilidad.
El equipo depende de una o dos personas que saben tocar la base de datos y preparar datos con scripts propios. Es conocimiento tácito en vez de documentado. No podemos estar días para obtener un dato para pruebas.
Solución: Un sistema de búsqueda por arquetipos y de autoservicio que permite que el equipo de QA pueda pedir datos con garantías.
Montar un entorno o preparar datos que requiera días o semanas significa que pierdes el sprint esperando que todo esté listo. Si tardas días en tener datos, tu cuello de botella no es el testing, son los datos.
Se usan datos de producción en entornos de test sin control. Razones frecuentes:
- Se confunde el realismo con el uso de datos reales
- No existen reglas de enmascarado
- Presión por ir rápido y usar una copia directa
Arquitectura mínima viable de TDM
El conjunto más pequeño de componentes que necesitas para demostrar valor real en la gestión de datos de prueba. Igual que en desarrollo hacemos un MVP para validar una idea, en TDM también podemos hacer una arquitectura mínima para validar el modelo.
5.1 Los cuatro pilares
- Clientes y pedidos
- Clientes, pólizas y recibos
- Pacientes y tratamientos
5.2 Beneficios de la arquitectura mínima viable
- Aprendizaje real: Identifica cuellos de botella antes de escalar
- Confianza: Validas que los mecanismos funcionan en tu contexto
- Base de crecimiento: Puedes duplicar el modelo a otro dominio
Esta arquitectura no se concibe como un piloto que se tira. Es el primer escalón de un sistema que crece por evidencia. Es un sistema reproducible y medible en miniatura, pero que ya demuestra los beneficios de TDM.
Mecanismos de TDM
Los datos de prueba no solo se gestionan, se diseñan. Y diseñarlos bien convierte las pruebas en conocimiento fiable. Los mecanismos del TDM trabajan juntos para hacer esto posible.
6.1 Data masking (enmascaramiento de datos)
6.1.1 Definición y objetivo
El Data Masking es la transformación de datos sensibles a través de reglas controladas que permiten mantener el valor técnico de los datos para poder utilizarlos. Es la base del cumplimiento by design.
Consiste en transformar o sustituir los valores sensibles (nombres, DNIs, teléfonos, temas de salud) por otros que mantienen el formato y la lógica, pero no permiten identificar a personas reales.
6.1.2 Tipos de enmascaramiento
A) Anonimización completa (100%)
Realiza el cambio de información de valores una única vez y al finalizar el proceso, borra cualquier evidencia de esta anonimización. Siempre usa algoritmos no deterministas para que no se puedan revertir los valores e identificar a los individuos.
Es más común para entornos efímeros o cuando es necesario entregar datos a terceros, donde se anonimiza hoy y se rompe cualquier vínculo con la información original, siendo imposible volver atrás.
B) Seudonimización
Guarda una trazabilidad protegida. Ejecuta el proceso de enmascaramiento y almacena de forma totalmente protegida que el DNI 1 se cambió por el 5, que la cuenta bancaria X se cambió por la Y, etc. (datos individuales que no pueden asociarse a un individuo particular).
- Si hacemos un primer ciclo de anonimización y los equipos buscan los datos que les sirven, en el siguiente proceso los mismos datos van a seguir sirviendo porque se cambiaron de forma igual
- Simplifica el paso de búsqueda y selección de datos para las pruebas
- Si tenemos diferentes aplicaciones que no podemos procesar al mismo tiempo pero tienen relación entre sus datos, podemos enmascarar una hoy y la otra en una semana/mes y obtener el mismo resultado
6.1.3 El proceso de data masking
Descubrimiento de datos sensibles
Escanear la base de datos — todas las tablas, todos los campos, el contenido — para identificar dónde se encuentran los datos sensibles. Se realiza mediante inspectores que analizan:
- Análisis estático: Nombre del campo, tipo y longitud. Si buscamos un nombre y el campo es numérico, se descarta
- Análisis dinámico: Lee el contenido de la tabla para cada campo y aplica diferentes métodos para descubrir el tipo de dato (algoritmos de validación, formato, longitud)
El resultado es un mapa con temperaturas (muy alta, media, alta) indicando la probabilidad de que cada campo sea de un tipo determinado de información sensible.
Configuración de la política de disociación
Sincronizar el metamodelo de las tablas en la aplicación y asignar algoritmos de tratamiento específicos para cada campo:
- Este campo se tiene que anonimizar con el algoritmo de DNI
- Este campo con el algoritmo de nombre de persona
- Este campo con el algoritmo de cuenta bancaria
Ejecución del proceso de disociación
Seleccionar el entorno objetivo (pruebas, desarrollo, integración, pre) y ejecutar el proceso. Los pasos se ejecutan en un orden específico de forma paralela:
- Descarga de datos de forma encriptada y serializada
- Validación de privilegios
- Deshabilitación temporal de índices y foreign keys para optimizar
- Aplicación de algoritmos de disociación
- Actualización de datos en base de datos
- Rehabilitación de índices y constraints
Automatización
El proceso puede automatizarse mediante un orquestador (ej: durante el fin de semana se copia la base de datos de producción y el siguiente paso es ejecutar la disociación masiva). icaria TDM provee un muro de servicios REST para estas ejecuciones.
6.1.4 Coherencia multi-sistema
Un proceso de disociación puede atacar a bases de datos de distintas tecnologías simultáneamente. Si el entorno está compuesto de una base de datos Postgres, un Oracle y un DB2, se puede atacar ese conjunto de conexiones al mismo tiempo, en el mismo proceso, sin problema.
Todos los procesos de icaria TDM pueden ejecutarse de forma simultánea en varias aplicaciones y entornos, de forma totalmente agnóstica a la tecnología de base de datos.
6.1.5 Garantía de calidad del dato
¿Cómo aseguramos que el data masking no degrada la calidad ni la utilidad del dataset de pruebas?
- Los datos modificados mantienen el formato y comportamiento original
- Para emails: se usa dominio @example.com para evitar envíos accidentales pero manteniendo formato de correo
- Si encontramos un DNI que no cumple su validación en producción, lo disociamos haciendo que el resultado tampoco cumpla la validación, porque ese dato de mala calidad es la casuística que encontraremos en producción
6.1.6 Capacidad de procesamiento
de registros anonimizados acumulados por nuestros clientes. icaria TDM tiene capacidad de paralelizar mientras haya recursos de CPU y memoria disponibles.
6.2 Subsetting (segmentación de datos)
6.2.1 Definición y objetivo
El Subsetting extrae un subconjunto coherente de información de producción o de un entorno de pruebas, y es capaz de hacer esa copia y entregar los datos en otro entorno, manteniendo toda la integridad referencial y todas las relaciones entre tablas.
En lugar de copiar bases de datos enteras, el subsetting extrae un conjunto representativo seleccionando solo las entidades necesarias.
de reducción del volumen de la base de datos con subsetting inteligente.
6.2.2 Problemas que resuelve
6.2.3 Caso de uso: incidencia en producción
Hay una incidencia en producción con un cliente concreto y queremos reproducirla.
Con disociación masiva tradicional: Tal vez el dato lo tenemos porque hicimos la copia la semana pasada, pero ya tiene un retraso. El desarrollador valida, ve que se reproduce el bug... y ahora el dato está inconsistente, no puede reprobar.
Con subsetting: En el mismo instante en que se detecta el fallo, tomamos el dato del entorno original (producción) y lo entregamos en otro entorno, garantizando la disociación. Tenemos el dato como se necesita en el momento que se necesita. Es repetible y dura segundos.
6.2.4 Características clave
- No bloquea el entorno: Entregar un dato no afecta al resto de equipos
- Operaciones ligeras: Al acceder solo a los registros impactados, sin impacto real incluso durante horas pico
- Multi-tecnología: Entrega simultánea en aplicaciones con diferentes tecnologías (ej: MySQL + Postgres)
- Integridad referencial garantizada: Todas las tablas relacionadas se entregan coherentemente
6.2.5 Repositorios internos
Los repositorios permiten guardar una copia de un cliente (o tantas como se necesiten) con distintas versiones, abstrayéndose de lo que pueda ocurrir en el entorno original.
- Si el dato puede cambiar en producción, guardamos una copia en el repositorio para reprobar siempre con las mismas características
- Para features nuevas que requieren datos que no existen en producción: crear el dato una vez, guardarlo en el repositorio, y entregarlo tantas veces como sea necesario
- Promoción entre entornos: el dato está en el repositorio y se puede entregar en cualquier entorno
6.3 Buscador de datos y arquetipos
6.3.1 El problema de encontrar datos
Incluso con datos "infinitos" (copia completa de producción), surge la pregunta: ¿cómo encuentro en este mar de datos exactamente los que necesito? De millones de clientes, ¿cómo doy con los que realmente satisfacen mis pruebas?
"Mi prueba necesita un cliente recién creado". Pero ¿qué condiciones marcan ese "recién creado"?
- ¿Cuando relleno todos los formularios?
- ¿Cuando después de rellenarlos me espero un tiempo para que el cliente quede activo?
- ¿Cuando el cliente sube documentación a la banca online?
- Para desarrollo puede significar una cosa, para testing otra completamente distinta
6.3.2 El problema de las queries
Gestionar datos mediante queries tiene múltiples desafíos:
- ¿Quién prepara las queries? ¿Con qué expertise?
- ¿Quién puede ejecutarlas?
- ¿Qué ocurre si la query bloquea toda la base de datos?
- No hay criterio común, las queries hay que ir actualizándolas
- No hay repositorio: "yo me guardé una copia pero mi equipo la actualizó"
- ¿Cómo entremezclamos condiciones entre DB2 y Oracle?
- Problema de privacidad: ¿quién tiene acceso al entorno?
- Condiciones base que se repiten en todas las queries (10, 15, 20 condiciones) hacen cada query muy compleja
6.3.3 La solución: arquetipos de datos
Los arquetipos (o perfiles de datos) son definiciones estándar comunes a las que todo el mundo llega. Son categorizaciones de perfiles de datos donde hay un conjunto de condiciones que definen el dato y donde todo el mundo tiene esa opinión estandarizada.
- Unificación de criterios entre negocio, desarrollo y testing
- Si mañana hay que sumar una condición al arquetipo, todos los que lo usen ya estarán actualizados
- Definidos en lenguaje más sencillo, parecido a expresiones de Excel
- Las condiciones son reutilizables entre diferentes arquetipos
6.3.4 Pool de datos auto-aprovisionado
Con los arquetipos se crea un pool de datos que se autoaprovisiona: se buscan datos disponibles en los distintos entornos de prueba según la definición del arquetipo.
- Los datos se validan automáticamente (en cuestión de segundos)
- Sistema de reserva de datos: una vez reservado, el resto de equipos entiende que el dato ya no está disponible
- Se puede ver quién hizo la reserva y gestionar los datos sin pisarse unos con otros
6.3.5 Peticiones de búsqueda personalizadas
Si los arquetipos definidos no satisfacen lo que necesito, puedo crear una petición de búsqueda desde cero:
- Partir de un arquetipo, una plantilla o en blanco
- Seleccionar la estructura de datos (ej: clientes)
- Seleccionar el entorno donde buscar (producción, pruebas, etc.)
- Indicar cuántos ítems localizar (1, 5, 1000...)
- Seleccionar el juego de condiciones que van a cubrir el requisito
6.3.6 Ejecución de peticiones en lotes
Las peticiones se atienden en lotes para gestionar correctamente los accesos a base de datos. Las organizaciones automatizan la ejecución en franjas determinadas que no impacten en los entornos.
6.4 Autoservicio
6.4.1 Concepto
El autoservicio completa el proceso y permite solicitar la provisión del dataset directamente en el entorno en el que se necesita, sin abrir tickets ni esperar a terceros.
QA y DevOps ganan autonomía real y el flujo de pruebas se acelera de forma exponencial. Se rompe la dependencia de personas o equipos específicos y convierte los datos de prueba en un servicio disponible bajo demanda.
6.4.2 Nivel de autonomía
de autonomía. Con las formaciones necesarias, los equipos pueden gestionar todo el ciclo.
- Descubrir datos sensibles en sus bases de datos
- Configurar los disociadores
- Automatizar mediante llamadas a servicios REST del proceso de data masking
- Solicitar y recibir datos sin dependencia de otros equipos
6.4.3 Proceso de autoservicio para subsetting
Desde la perspectiva del usuario de autoservicio:
Solicitar la entrega
Entrar a icaria y solicitar la entrega del dato
Seleccionar la estructura
Elegir la estructura de datos (ej: clientes)
Elegir el destino
Seleccionar el entorno destino (pruebas, desarrollo, repositorio)
Indicar motivo
Registrar el motivo para auditoría (puede incluir número de ticket o identificador de caso de prueba)
Marcar criterio de búsqueda
Seleccionar qué semilla/criterio de búsqueda usar
Guardar y esperar
El proceso de buzón en background procesa las peticiones pendientes
6.5 Diseño del dato en el caso de prueba
6.5.1 El concepto fundamental
Este es el quinto mecanismo y cierra el ciclo. Aquí el concepto cambia: ya no es el tester quien busca o decide qué datos usar, sino que el dato ya viene diseñado dentro del propio caso de prueba. Es el punto de partida para construir y ejecutar las pruebas automatizadas.
Cada test lleva asociado un dataset que cumple las condiciones exactas que necesita (usuarios, clientes, pedidos, estados, fechas), y el sistema provisiona automáticamente antes de la ejecución.
6.5.2 Los 3 ingredientes de una prueba
Generalmente, la gestión de estos datos no se considera dentro del plan, no es parte de la definición de la prueba ni de la automatización. Por eso comenzamos bien automatizando (scripts de Selenium son simples de hacer) pero terminamos mal cuando la prueba se complica.
6.5.3 El diseño completo del caso de prueba
Desde la perspectiva de datos, el diseño incluye:
6.5.4 El flujo de ejecución
Buscar
Buscar el dato en producción que cumple las condiciones necesarias
Proteger
Mover el dato a la base de datos interna y protegida para que nadie lo modifique
Entregar
A petición de la prueba, entregar el dato en el entorno correspondiente
Restaurar
Una vez quemado el dato, restaurarlo a su estado inicial para reutilización
Validar
Ejecutar la prueba y validar el resultado desde la perspectiva del dato
6.5.5 Reglas de validación
Las reglas de validación definen qué resultados se esperan desde la perspectiva del dato:
- Que un valor debe coincidir con un valor de salida específico
- Que una fecha debe ser la de la ejecución
- Que se debe crear o eliminar un registro
- Que simplemente el valor debe cambiar (ej: actualización de email o teléfono)
6.5.6 Reglas de inyección
Las reglas de inyección aseguran la calidad del dato antes de entregarlo.
Si necesitamos que el usuario sea menor de 18 años: icaria TDM ve la fecha, calcula la edad que tendría la persona al momento de la entrega, y planifica la modificación para que cumpla la condición necesaria. La fecha de nacimiento entregada será hoy menos 17 años, asegurando que siempre que entregamos el dato, la persona tiene 17 años.
6.5.7 Estructura de segmentación (dominio de datos)
Para entregar datos coherentes se define un dominio de datos: qué queremos entregar (ej: un partner completo con al menos una cotización en estado borrador en ambas aplicaciones).
La estructura de segmentación tiene una entidad cabecera (ej: partner) con todas sus entidades relacionadas necesarias para completar el dominio en todas las aplicaciones involucradas.
Modelo de madurez TDM
La madurez en TDM es un camino, no es un salto. icaria TDM ha identificado cinco niveles, desde lo reactivo hasta la mejora continua.
Este modelo no pretende que todo el mundo llegue al nivel máximo. Su objetivo es ayudar a la organización a identificar dónde está, qué nivel de madurez tiene cada proceso y cuál es el siguiente paso lógico en su evolución.
| Nivel | Características | Indicadores |
|---|---|---|
| 1 — Inicial | Datos de prueba se gestionan de forma reactiva, manual, ad-hoc. Copias directas de producción sin control. | Sin catálogo, sin enmascarado, dependencia de "héroes locales" |
| 2 — Repetible | Existen algunos procesos básicos de enmascarado. Se han identificado datos sensibles en los sistemas principales. | Primer mapa de datos sensibles, reglas de enmascarado básicas |
| 3 — Definido | Se ha implementado una Arquitectura Mínima Viable. Hay provisión automatizada para al menos un dominio de datos. | Pipeline automatizada, subsetting funcional, arquetipos definidos |
| 4 — Gestionado | TDM integrado en CI/CD. Autoservicio operativo. Métricas de uso y lead time visibles. | Datos como servicio, trazabilidad completa, múltiples dominios |
| 5 — Optimizado | Mejora continua basada en métricas. Datos de prueba diseñados dentro del caso de prueba. Cumplimiento by design en todos los entornos. | 100% cobertura, ROI medido, cero datos reales en no-producción |
7.1 Cómo empezar
El objetivo no es hacerlo todo a la vez, sino demostrar valor rápido, aprender y después escalar. Las dos palancas que mueven esto son:
Integración con CI/CD
Al incorporar icaria TDM al ecosistema de pruebas, se completa el pipeline de testing continuo.
8.1 El ecosistema de pruebas
Es normal que los equipos de pruebas utilicen herramientas como:
- TestLink o Jira para gestión de casos de prueba
- Jenkins para orquestación
- Playwright, Robot Framework o Selenium para ejecución de pruebas
Sin embargo, pocas veces se habla de las herramientas de data management. Al incorporar icaria TDM, se completa el ecosistema.
8.2 El ciclo de ejecución integrado
(Orquestador)
(Inyección)
Ejecución
(Validación)
Resultado
Consulta
El orquestador (ej: Jenkins) pregunta al gestor de casos de prueba qué prueba ejecutar y en qué entorno
Inyección de datos
El orquestador llama a icaria TDM para que haga la inyección del dato en el entorno correspondiente
Ejecución de la prueba
Cuando icaria TDM termina, el orquestador solicita a la herramienta de ejecución que ejecute la prueba
Validación del dato
Al finalizar, el orquestador solicita a icaria TDM la comprobación de resultados desde la perspectiva del dato
Informe
Con esta información se emite el informe y queda guardado el resultado con información de todas las herramientas
8.3 Automatización completa
Cuando se lanza el caso de prueba, el propio sistema:
- Inyecta los datos adecuados en el entorno
- Ejecuta la prueba
- Valida el resultado desde la perspectiva del dato
Esto elimina cuellos de botella típicos de las fases de preparación y sincronización de datos, y permite ejecutar pruebas en paralelo sin conflictos ni dependencias. Es el paso final hacia el testing continuo, donde los datos y las pruebas avanzan al mismo ritmo que el desarrollo.
Beneficios y ROI
El impacto medible del TDM en velocidad, cobertura, costes, riesgo y satisfacción del equipo.
9.1 Beneficios principales
- El dato está disponible antes de comenzar la prueba
- Recuperación rápida: restaurar y volver a entregar
- Entornos que tardaban semanas, listos en minutos
- Datos antiguos, nuevos, complejos disponibles
- 100% de cobertura realista
- Datos del camino feliz y del no tan feliz
- Datos de aspecto real pero no reales
- Cumplimiento normativo (GDPR, DORA)
- Sin datos reales en entornos no productivos
- ROI superior al 300%
- Reducción de costes de infra (hasta 90%)
- Equipos más autónomos y eficaces
9.2 Beneficios operativos adicionales
- Cada caso de prueba es independiente (no depende de la salida del anterior)
- Dato disponible para múltiples usuarios y entornos simultáneamente
- Entrega en entornos activos (sin parar entornos, sin restaurar copias, sin perder trabajo de compañeros)
- Verificación del resultado desde la perspectiva del dato
- Personas con menor experiencia pueden aportar valor rápidamente
9.3 Beneficios para el equipo
Mejora de comunicación dentro del equipo y entre equipos:
- Las definiciones del dato y condiciones están centralizadas
- El conocimiento está accesible y visible para todos
- Equipos más contentos porque dedican tiempo a tareas más interesantes
- El equipo puede participar en definición de producto, analizar requerimientos, plantear estrategias, diseñar escenarios, impulsar mejoras
Sin icaria (TDM) no podríamos vivir
icaria TDM: la plataforma de gestión de datos de prueba
Especialistas en gestión de datos. Ayudamos a que los datos sean gobernados, sean seguros y sean utilizables.
10.1 Sobre icaria Technology
icaria Technology es una empresa especialista en gestión de datos. Ayuda a las organizaciones a diseñar y operacionalizar sus datos: desde el gobierno del dato, la protección de entornos productivos mediante la ejecución automatizada de derechos de privacidad (como el derecho de supresión), hasta la provisión reproducible de datos para pruebas.
10.2 Reconocimiento de Gartner
icaria TDM es reconocida por Gartner como Sample Vendor en su informe de 2025 sobre los tres pasos para optimizar la gestión de datos de prueba.
La adopción del TDM, según Gartner, está todavía en escenarios muy incipientes en muchas organizaciones. La mayoría de empresas, incluso las grandes, todavía trabajan con procesos manuales. Pero la tecnología TDM ya ha madurado: lo que ofrecen las herramientas es lo que esperan los usuarios.
10.3 Acerca de icaria TDM
icaria TDM es la plataforma de Test Data Management diseñada para aplicaciones críticas y entornos OSS/BSS. Ofrece datos realistas, seguros, correctos y coherentes, exactamente cuando y cuantas veces se necesiten — asegurando que los resultados de cada prueba sean efectivos y confiables.
Con icaria TDM, testers y desarrolladores reducen drásticamente las horas dedicadas a la producción y gestión de datos, pudiendo enfocarse en tareas de mayor valor. Las principales empresas de banca, seguros y telecomunicaciones ya confían en icaria TDM para transformar sus procesos de prueba.
Tres soluciones, una suite completa
Seguridad y cumplimiento sin compromisos. Aplica técnicas avanzadas de anonimización y pseudoanonimización para garantizar que los datos sean representativos sin exponer información sensible. Cumple con GDPR y otras normativas manteniendo la coherencia en múltiples entornos.
Datos listos para pruebas manuales. Los testers ganan autonomía al obtener subconjuntos optimizados según demanda, encontrar los datos exactos para cada caso de prueba gracias al buscador, y extraer datasets conservando su integridad y relaciones.
Datos automatizados para pruebas continuas. Automatiza el aprovisionamiento de datos en pipelines CI/CD, eliminando cuellos de botella. Cada ejecución de pruebas tiene los datos correctos y actualizados, sin intervención manual.
Compatible con las principales plataformas del mercado — Oracle, SAP, Salesforce, IBM, Hadoop y muchas otras fuentes de datos —, icaria TDM se integra en cualquier ecosistema tecnológico ofreciendo una solución robusta y escalable. Los equipos de QA prueban más, prueban mejor y prueban más rápido.
10.4 Capacidades de icaria TDM
- Oracle, Postgres, MySQL, SQL Server, DB2
- Ficheros de longitud fija, ficheros CSV
- Otras fuentes no relacionales
- Prospección estática y dinámica
- Identificación de relaciones entre aplicaciones
- Algoritmos estándar para cada tipo de dato
- Extensibles y personalizables con Java
- Configuración masiva
- Muro de servicios REST
- Integración con orquestadores (Jenkins, etc.)
Instalación
Se instala en la infraestructura del cliente (cloud u on-premise). icaria TDM es consciente de la privacidad y necesidad de privacidad de los datos: son los datos del cliente y se respeta que permanezcan en su infraestructura.
10.5 Proyecto de implantación
Para poner en marcha un proyecto de TDM se requiere:
- Obtención de conexiones a bases de datos
- Instalación del software en la infraestructura del cliente
- Identificación de requisitos y mayores puntos de dolor
- Creación de estructuras de datos
- Mapa de datos sensibles con reglas de disociación
El proyecto lleva unos meses, pero el retorno de la inversión se ve muy rápido: incluso durante el proyecto de implantación ya se constatan problemas de calidad de datos y beneficios en la entrega de datos más reducidos.
10.6 Clientes y referencias
Grandes organizaciones con estructuras complejas, necesidades de cumplimiento normativo exigente y volúmenes de datos muy grandes confían en icaria TDM: bancos, empresas de telecomunicaciones, aseguradoras. La plataforma se adapta desde equipos más pequeños con cientos de tablas hasta organizaciones donde hay miles de tablas, varias tecnologías y distintos equipos.
¿Listo para transformar tu gestión de datos de prueba?
Descubre cómo icaria TDM puede ayudar a tu organización a reducir costes, aumentar la cobertura de pruebas y cumplir con la normativa — todo desde el primer día.
Solicita una Demoicaria Technology — Especialistas en Gestión de Datos
© 2026 icaria Technology. Todos los derechos reservados.