Imagina un equipo cuya misión es la de crear los entornos de pruebas para una organización y debe utilizar datos reales en entornos preproductivos.
¿Lo tienes visualizado en tu mente?
Bien, porque a partir de aquí encontrarás algunos de los principales problemas generados por los datos reales en entornos preproductivos a los que te puedes enfrentar y cómo solucionarlos.
¿Quieres saber más?
¡Continúa leyendo!
Lo primero de todo, ese equipo del que te hablábamos antes comenzará a valorar qué sistemas son los que necesitará en dicho entorno, presupuestar su puesta en marcha, espacio de almacenamiento para las bases de datos, máquinas para dichos procesos, etc.
Posiblemente, desde el inicio, puedan llegar a pensar en rellenar dichas bases de datos con los datos exactos que necesiten.
Llegados a ese punto, habrán escogido el uso de una disociación masiva o bien el completar las bases de datos a partir de procesos de segmentación.
Suponiendo la selección de un proceso de segmentación o subsetting, los propietarios de los aplicativos a tratar en un momento dado seguramente alerten de que la instalación desde cero requiere de ciertos datos básicos en las bases de datos.
Estos, que no serán segmentados en su mayor parte, normalmente se completarán en base a la información de producción.
Una vez completados esos datos básicos entonces sí se plantearán mover los principales dominios de datos de manera segmentada.
Estos procesos de inicialización pueden completarse en icaria mediante los planes de segmentación.
En ellos se configuran una serie de tablas de transferencia completa, sobre las que además se permite aplicar filtros y modalidades de inserción para mejorar la eficiencia del movimiento.
Finalmente, se permite incluir también sendas de transferencia para aplicar en el mismo movimiento algunos datos adicionales, por ejemplo, de usuarios de la aplicación o, si se desea, de estructuras como clientes o cuentas.
Hasta aquí el mundo ideal.
Este camino feliz o happy path, ocurre en una minoría de las instalaciones.
Pero la realidad es otra muy distinta.
Los motivos que lo impiden son diversos.
Algunos son un vago conocimiento de las tablas básicas para el entorno frente a la que almacenan información propia de las instancias de clientes o servicios.
Otros la existencia de registros de ambos tipos de datos en una misma tabla, sin un criterio claro para filtrarlos. Por ejemplo, las tablas de “personas”, que pueden existir bien a través de un cliente, bien a través de un empleado o usuario, la dificultad para filtrar todas ellas cuando el número de tablas es alto, el empeño necesario para realizar este filtrado; etc.
Por tanto, son muchas las ocasiones en las que se plantea inicializar el entorno directamente haciendo un clonado de la base de datos, una disociación masiva y, tras ello, ahí sí, se comienzan a entregar datos selectivamente.
No obstante, incluso esto, que parece una mala solución, no es la peor.
A día de hoy, a pesar de las regulaciones en materia de protección de datos como la antigua LOPD o la actual GDPR, son muchas las bases de datos de entornos no productivos que se mantienen con datos sin anonimizar.
En ocasiones, mezclados entre tanto dato creado a base de pruebas que se hace difícil sino imposible distinguir qué queda de real y qué es generado en dicho entorno.
Sin embargo, ¿qué ocurre en dichos entornos cuando se comienza a utilizar la segmentación para entregar una gran cantidad de datos?
En este punto es cuando comienzan a aflorar esos datos originales, de diversas maneras.
Algunos problemas que hemos experimentado por esta causa son los siguientes:
Bien sea mediante índices únicos, claves primarias, restricciones de la propia base de datos o, incluso, restricciones lógicas que provocan mal funcionamiento en los aplicativos que usan los datos.
Existen datos que el probador esperaría que fuesen únicos, por ejemplo, el nombre de un dispositivo o un NIF. Sin embargo, cuando se entrega en un entorno enormemente poblado se pueden producir duplicados con mayor probabilidad. Por ejemplo, por haber generado aleatoriamente un dato que ya existe en el entorno.
Generalmente, los índices únicos se solventan mediante la disociación de datos. Sin embargo, aquellos datos que no se modifican mediante algoritmos de disociación pueden provocar este tipo de problemas de duplicidad.
Además, las duplicidades no son el único problema.
¿Qué ocurre si, por ejemplo, movemos una estructura equivalente a una de destino?
Veamos un ejemplo.
Supongamos que estamos moviendo desde producción un cliente junto con sus servicios.
El entorno de destino partió de una copia de producción por lo que, si este cliente tiene la antigüedad suficiente, sus datos, tanto personales como de los servicios contratados en el momento de la copia, se encontrarán allí.
Parece sencillo, ¿no?
Disociamos los datos, los entregamos y esperamos que los servicios anteriores hayan desaparecido y aparezcan los nuevos.
Pero, la realidad es que no suele ser tan fácil.
Sin un adecuado manejo de las secuencias, en determinados escenarios, nos encontraremos con problemas entre las estructuras.
No siempre la estructura lógica consigue eliminar los datos del entorno de destino.
Por tanto, hay que entender que la gestión de datos de destino, cuando se realiza el movimiento de una estructura que ya existe parcialmente en dicho entorno, no es una tarea sencilla.
Vistos algunos puntos conflictivos en relación a la compatibilidad entre datos preexistentes y la entrega de datos segmentados, ¿qué se propone desde el equipo de icaria Technology para abordarlos?
Es seguro que no existe una misma solución para todos los problemas de este tipo que nos encontramos, sin embargo, icaria TDM cuenta con numerosas soluciones que facilitan y mitigan estos incómodos problemas.
Con respecto al problema de la duplicidad de datos proponemos lo siguiente:
Al igual que lo hacen los aplicativos que crean datos sobre dichos repositorios. Este proceso se conoce como Traducción de códigos dentro de la herramienta y, aunque es muy potente, también conlleva algunas desventajas, las veremos en alguna publicación dedicada más adelante.
Revisando, durante el proceso de generación, si el valor ya fue se encuentra en él. Como la solución anterior, tampoco es infalible. Si hablamos de un dato trazable, y compartimos la trazabilidad entre varios entornos de destino, tendremos que revisar no solo en dicho entorno sino también en el resto. Además, también podría obligar a revisar en numerosas tablas y sistemas en función del dato.
Cuando no existe una secuencia ni ningún criterio de generación, una solución que habitualmente funciona es la modificación de los datos a entregar para evitar esta incidencia.
En el caso de icaria esto lo conseguimos mediante la modalidad de entrega, que permite, entre otras cosas, manipular la información de los índices únicos y de las claves primarias.
Eso sí, requiere la constante comprobación de los datos que se transfieran hacia campos con restricción de unicidad por lo que el tiempo de ejecución se puede ver lastrado.
Con respecto a esta opción las acciones son muy diferentes.
Habitualmente, la solución más limpia y efectiva, es añadir nuevas ramas a la estructura de segmentación, adicionales al camino lógico del dato, que busquen esos conflictos y, gracias a la gestión de comparación de estructuras de icaria TDM se encarguen de borrar los datos sobrantes.
Además, estas ramas pueden ser configuradas de tal forma que solo permitan el borrado de datos, evitando así que interfieran en aquellos casos en los que este problema no se muestre.
Otra solución que también se ofrece con el producto es la de ejecutar acciones específicas sobre los datos de destino en el momento del movimiento, de este modo, durante el movimiento se evalúa si se va a generar algún conflicto.
Por ejemplo, mediante personalización del código de icaria TDM en la instalación del cliente se ejecutan acciones que cambien el estado de los datos en destino a desactivado, bloqueado o algún estado similar que consiga que los aplicativos que traten la información de inmediato lo descarten.
Como se ha podido evidenciar a lo largo del artículo, la existencia de datos reales genera numerosos conflictos en la entrega mediante segmentación.
Además, expone a la organización a un problema de ámbito legal en relación a GDPR.
Las recomendaciones del equipo de icaria Technology para evitar estos conflictos son las siguientes:
Antes de poner en marcha la segmentación, bien a través del borrado completo de tablas, bien haciendo uso de la funcionalidad de borrado mediante segmentación de icaria TDM.
Para, al menos, cubrir el aspecto legal y reducir la probabilidad de conflicto.
Tratando de evitar estas duplicidades, por ejemplo, desactivando de manera masiva los clientes, cuentas, etc. que existan en dicho entorno.
Lo cual, además, puede ser un excelente complemento al punto anterior.
Como ya se ha puesto de manifiesto a lo largo de este artículo, y lo habrás vivido en primera persona si te has enfrentado a un proceso de subsetting en el que se mueve gran cantidad de datos, la entrega sobre entornos con datos reales no es sencilla.
En muchas ocasiones evidencia problemas de los aplicativos que usan dichos datos que hasta ese momento se reproducían con relativa poca frecuencia.
La incorrecta gestión de datos duplicados, el variar las claves de búsqueda para la misma información en función de la ventana o botón desde el que se busque o un problema de manejo de secuencias en las inserciones de datos son algunos de ellos.
Sin embargo, lograr que, llegados a este punto, los aplicativos del cliente sean modificados no es tarea sencilla.
Por ello, se exige que la herramienta de segmentación tenga capacidad de respuesta, adaptación y una buena gestión de errores que faciliten discernir en qué condiciones se ha entregado la estructura.
¿Quieres mejorar la seguridad de la información y la protección de datos en tus pruebas de software? Contacta ahora con icaria Technology y comienza a mejorar la calidad de tu software de gestión de datos de prueba.
También te puede interesar:
Ley de datos personales y GDPR, ¿cómo gestionar el proceso de cancelación de los datos?
¿Cómo realizar la automatización de pruebas para software de gestión empresarial?
¿Por qué la protección de datos en los entornos de prueba no debería ser una preocupación?"
