Gestión y generación de datos para pruebas

Porque la base de producción contiene datos personales de gente real —nombres, correos, direcciones y a veces información de pago o de salud— que están protegidos por normativas de privacidad como el RGPD, las cuales limitan para qué y dónde pueden usarse. Los entornos de pruebas suelen estar bastante menos protegidos que producción, así que copiar esos datos ahí los expone: cualquier filtración desde el entorno de pruebas se convierte en una filtración de datos reales, con consecuencias legales, económicas y de reputación. No es un tecnicismo burocrático, es exponer a personas que confiaron su información. Si de verdad se necesita la variedad de los datos reales, hay que anonimizarlos de forma irreversible antes de llevarlos a pruebas; pero para la mayoría de los casos, los datos sintéticos generados a propósito son la opción más segura y suficiente.

Son datos inventados a propósito para las pruebas, que parecen reales pero no corresponden a ninguna persona. Se consiguen de dos maneras. Una es mediante bibliotecas generadoras, conocidas genéricamente como generadores de datos falsos, que producen nombres, correos, direcciones, teléfonos y fechas verosímiles pero ficticios, ideales para llenar un entorno con volumen y variedad. La otra es construir a mano los pocos registros que un caso concreto necesita, por ejemplo un cliente con un cupón vencido o un pedido con un monto inválido, cuando se quiere control total sobre el dato. La gran ventaja de los datos sintéticos es doble: no involucran a ninguna persona real, con lo que evitan todos los riesgos de privacidad, y permiten fabricar exactamente los casos que se quieren probar, incluidos los raros e inválidos donde suelen esconderse los defectos.

Significa que antes de cada prueba el entorno tiene exactamente los datos que el caso necesita, ni más ni menos, de modo que la prueba parta siempre del mismo punto y su resultado sea reproducible. El patrón tiene tres momentos: preparar, ejecutar y limpiar. En la preparación se crean los datos que el caso requiere, como el usuario, el pedido o el cupón concretos, sin suponer que ya estarán ahí. Luego la prueba se ejecuta sobre ese estado controlado. Y al terminar, la limpieza deshace los cambios y borra lo creado, para que el entorno quede como estaba y la siguiente prueba también parta limpia. Estos datos preparados de antemano suelen llamarse fixtures o precondiciones, y la clave es que cada prueba crea lo que necesita y limpia lo que ensució, en lugar de depender del estado que dejó otra.

Es el proceso de reemplazar de forma irreversible los datos personales de un conjunto por valores falsos, de modo que ya no se pueda identificar a las personas a las que pertenecían, conservando la forma y el volumen de los datos originales. Sirve para el caso en que de verdad se necesita la variedad y la escala de los datos reales de producción pero no se puede exponer la información de las personas: se toma una copia, se enmascaran los campos personales antes de llevarla al entorno de pruebas, y así se obtiene un conjunto realista pero seguro. Es importante que la transformación sea irreversible, es decir, que no se pueda revertir para recuperar los datos originales, porque de lo contrario el riesgo persiste. Aun con anonimización, conviene tratar esos datos con cuidado; para la mayoría de los casos, los datos sintéticos siguen siendo la opción por defecto más segura.

Casi siempre por datos compartidos que se pisan entre pruebas, que es una de las causas más comunes de inestabilidad y una de las más difíciles de rastrear porque el defecto aparente está en un lugar distinto de la causa. Ocurre de dos formas. Una es la dependencia de orden: una prueba solo pasa si otra corrió antes y dejó cierto dato, así que cambiar el orden de ejecución o correrla aislada la rompe. La otra es la interferencia: una prueba modifica un registro que otra esperaba intacto, y la segunda falla por culpa de la primera, aunque su lógica sea correcta. La solución es el aislamiento: que cada prueba use sus propios datos, creados en su preparación y borrados en su limpieza, sin depender del estado que dejó ninguna otra. Buena parte de la inestabilidad que se atribuye a la red o al timing es, en realidad, este problema de datos.

Los suficientes para cubrir los casos que querés probar, que no es lo mismo que muchos. Un error frecuente es confundir volumen con cobertura: tener miles de registros no sirve de nada si entre todos ellos falta justamente el caso raro o inválido que el defecto necesita para manifestarse. Lo que importa es que el conjunto de datos incluya representantes de cada situación relevante, especialmente los bordes y los casos inválidos, que es donde más fallan los sistemas. Para pruebas de volumen o rendimiento sí hacen falta grandes cantidades, y ahí las bibliotecas generadoras son muy útiles. Pero para las pruebas funcionales, lo valioso es la variedad controlada: pocos datos bien elegidos que cubran cada condición del requisito valen más que una montaña de datos que solo repiten el caso feliz.