Un dato de identidad de prueba es un registro inventado que ocupa el lugar de una persona en un sistema que todavía se está construyendo. Sirve para que un formulario tenga algo que validar, para que una base de datos de desarrollo tenga filas y para que una demostración no enseñe campos vacíos delante de un cliente. Esta guía repasa cuándo conviene usar este material, por qué copiar datos reales no es una alternativa aceptable y cómo se organiza un conjunto que siga siendo útil dentro de un año.
Qué compone un registro de identidad de prueba
En su forma más completa, un registro de este tipo reúne los mismos campos que un alta real: nombre y apellidos, fecha de nacimiento, número de documento, dirección postal, teléfono, correo electrónico y, según el sistema, profesión, estudios o perfil en línea. Lo que convierte ese conjunto en material de prueba no es que los valores sean extraños, sino que no pertenecen a nadie. Se construyen respetando las convenciones del país elegido —la longitud del documento, el orden del nombre, la forma del código postal— para que el software los trate igual que trataría una entrada auténtica.
Conviene separar dos ideas que se mezclan a menudo. Una es el formato: que un campo acepte la forma correcta de un documento. La otra es la identidad: que ese documento corresponda a una persona inscrita en algún registro público. El material de prueba cubre lo primero y nunca lo segundo, y esa diferencia es la que explica por qué no puede utilizarse para acreditar nada ante un tercero.
¿Cuándo hacen falta identidades de prueba?
Las situaciones en las que este material ahorra trabajo son bastante predecibles. Casi todas tienen en común que se necesita un volumen de datos con aspecto verosímil antes de que exista ningún usuario real.
- Validación de formularios: comprobar campos obligatorios, longitudes máximas, caracteres admitidos y reglas que dependen del valor de otro campo.
- Pruebas automatizadas: disponer de un conjunto fijo que la integración continua pueda usar una y otra vez sin que los valores cambien entre ejecuciones.
- Demostraciones y prototipos: pantallas que deben verse llenas durante una presentación, una captura o una revisión de diseño.
- Volumen: listados con muchas filas, paginación, búsquedas, ordenaciones y exportaciones que solo se comportan de forma realista cuando hay cantidad.
- Reproducción de errores: un informe de fallo que cita un registro concreto y que otra persona debe poder reconstruir sin acceso a los datos del cliente.
La razón de fondo es siempre la misma: el sistema que se prueba tiene que recibir entradas parecidas a las que recibirá en producción, pero sin que esas entradas correspondan a nadie.
Por qué los datos de personas reales no deberían usarse aquí
La tentación es evidente, porque copiar una base de datos que ya existe ahorra mucho trabajo. También es la vía más corta a un problema. Un entorno de pruebas suele estar peor protegido que el de producción, lo comparten más personas, se replica en portátiles y acaba fotografiado en capturas que circulan por mensajería interna. Cada uno de esos movimientos amplía el número de lugares donde viven datos personales que nadie autorizó a trasladar.
Desde el punto de vista de la protección de datos, un nombre, un documento, una fecha de nacimiento, una dirección o un teléfono son datos personales con independencia de dónde estén guardados. Que el sistema sea de desarrollo no cambia su naturaleza ni reduce las obligaciones de quien los trata. Por eso la práctica recomendada es que los entornos que no son de producción se llenen con material sintético, y que el traslado directo desde producción se considere una excepción que hay que justificar caso por caso en lugar del camino por defecto.
¿Qué diferencia hay entre datos sintéticos y datos anonimizados?
Sintético significa construido desde cero por un procedimiento que no parte de ninguna persona concreta. Anonimizado significa que se ha partido de datos reales y se ha intentado romper el vínculo con su titular. Son caminos distintos, y el segundo es más frágil de lo que sugiere su nombre: borrar el nombre de un registro no impide que la combinación de fecha de nacimiento, código postal y profesión señale a una sola persona. En la práctica, buena parte de lo que se etiqueta como anonimizado es en realidad pseudonimizado, es decir, datos que siguen siendo personales aunque su titular no aparezca escrito.
Para un entorno de pruebas la conclusión es sencilla: si el material se genera y no se deriva de nadie, desaparece la discusión sobre qué se hizo con los datos originales. La comparación detallada entre ambos enfoques está en la guía sobre datos sintéticos y datos anonimizados.
Cómo llenar un entorno de pruebas con identidades verosímiles
En el generador de datos de identidad de este sitio se elige un país y una división administrativa y se obtiene un registro completo: nombre, dirección, número de documento, teléfono y perfil en línea tomados de la misma región, de modo que los campos no se contradicen entre sí. Cada registro lleva su propia clave de identidad, y esa clave es lo que permite volver a obtener exactamente el mismo valor cuando hay que repetir una prueba.
Cuando el sistema que se está probando trabaja con datos de un país concreto, conviene revisar antes qué formatos aparecen allí. La página de Estados Unidos resume, por ejemplo, la estructura de sus direcciones y de sus identificadores, y ayuda a decidir qué campos hay que declarar obligatorios y cuáles opcionales.
Notas para quien programa
Al trasladar estas ideas al diseño de un sistema, hay varios puntos que se repiten en casi todos los proyectos.
- Una identidad no es una lista de campos independientes. La fecha de nacimiento determina la edad, el país determina la forma del documento y del teléfono, y el código postal tiene que ser coherente con la dirección. Si el generador produce los campos por separado, esas relaciones se rompen.
- Decide qué es obligatorio y qué no. Si el material de prueba trae siempre todos los campos rellenos, el código que trata un apellido ausente o un segundo nombre vacío nunca se ejecuta y los fallos aparecen en producción.
- Distingue la muestra fija de la generación al azar. Una prueba que debe repetirse sin cambios necesita valores estables; una exploración que busca casos raros necesita variedad. Mezclar las dos cosas produce fallos que no se pueden reproducir.
- Marca los registros como sintéticos. Un prefijo reconocible, una etiqueta en el registro o una nota en el archivo evitan que dentro de seis meses alguien confunda el material con un dato de cliente.
- No uses estos registros para probar verificación de identidad real. Simular ese trámite con datos inventados solo ejercita el camino feliz y da una falsa sensación de seguridad. La guía sobre identidades en ficheros de prueba desarrolla este punto.
Siguientes pasos
Antes de generar nada, anota qué país, qué campos y qué cantidad de registros necesita el sistema que vas a probar; con esa lista, el generador de datos de identidad devuelve el material en unos segundos. Después guarda la clave de identidad de la muestra que hayas elegido: es lo que permitirá reconstruirla cuando alguien pregunte con qué dato se reprodujo el fallo.
Recuerda el límite que sostiene todo lo anterior: los datos de identidad que se generan aquí son solo para pruebas de software, no corresponden a ninguna persona real y no sirven para hacerse pasar por otra persona ni para superar una verificación de identidad.