Los datos ficticios de empresa resuelven un problema cotidiano: cómo probar un formulario que pide el nombre, el domicilio, el número de registro y el número de VAT de una sociedad, cuando no puedes usar los datos de una sociedad real. La respuesta habitual es inventarlos, y ahí empieza el problema, porque un dato inventado puede parecer inofensivo y acabar en una factura, en un informe o en una base de producción. Este artículo delimita para qué sirven, qué límites conviene respetar y cómo tratarlos para que no se escapen del entorno donde debían quedarse.
¿Para qué sirven los datos ficticios de empresa?
Sirven para tres cosas concretas, y solo para esas tres.
La primera es probar formularios y validaciones. Necesitas nombres con acentos, con sufijos largos, con caracteres de otros alfabetos, y necesitas identificadores con la forma correcta para cada país. Sin ejemplos, no hay forma de comprobar que el campo acepta lo que debe aceptar.
La segunda es demostrar un producto. Una demostración con datos reales de un cliente es un problema de confidencialidad; una demostración con fichas sintéticas evita ese problema por completo.
La tercera es cargar un entorno de desarrollo o de pruebas. Un entorno vacío no permite ver si una lista ordena bien, si una paginación funciona o si una búsqueda devuelve resultados razonables.
Fuera de esos tres usos, el dato ficticio pierde su sentido. En particular, no sirve para emitir documentos con efectos, no sirve para cumplir un requisito de identificación ante un tercero y no sirve para acreditar nada ante una administración.
¿Qué límites no conviene cruzar?
Los límites se pueden ordenar por el daño que produce cruzarlos.
| Límite | Por qué importa |
|---|---|
| No usar datos de una empresa real | Suplantar la identidad de un sujeto existente es un problema, no un atajo |
| No usar datos de una persona real | Ni nombres, ni correos, ni teléfonos que pertenezcan a alguien |
| No usar identificadores auténticos | Un identificador real en un entorno de pruebas circula y confunde |
| No generar documentos con apariencia oficial | Un justificante verosímil puede acabar usándose como si lo fuera |
| No mezclar entornos | El dato de prueba no debe poder llegar a producción por accidente |
| No presentarlo como verificado | Un dato sintético no acredita existencia ni situación |
Conviene añadir un matiz sobre los identificadores. Un identificador inventado que por casualidad coincide con uno real no es un dato inocente: está señalando a una sociedad que no tiene nada que ver con tu prueba. Por eso lo razonable es no construirlos copiando la forma de un número que hayas visto, sino generarlos con las reglas de forma del país y con un origen claramente artificial.
Y otro sobre los dominios y las direcciones. Los nombres y direcciones de ejemplo deben reconocerse como tales a simple vista. Un nombre que parezca perfectamente real acabará en una captura de pantalla que se comparte fuera del equipo, y entonces ya no hay forma de explicar el contexto.
¿Cómo se distinguen de los datos reales?
De la misma manera que se distingue cualquier material de prueba: por el entorno, por las marcas que lleva encima y por el canal por el que circula.
La separación por entorno es la más eficaz. Los datos sintéticos deben vivir en su propia base de datos, con su propio juego de credenciales, y no debe existir ningún proceso automático que los copie hacia producción. Si el producto permite importar datos, esa importación debe estar deshabilitada o limitada en el entorno de pruebas.
Las marcas visibles son la segunda barrera. Un nombre construido con palabras que gritan «ejemplo», una etiqueta en la interfaz que indique que el entorno es de pruebas, un distintivo en los documentos generados. Todo eso reduce la probabilidad de que alguien confunda una captura con un caso real.
La tercera barrera es el proceso. Los datos de prueba no deberían viajar por los mismos circuitos que los reales: no se envían al cliente, no se adjuntan a un informe de negocio, no se comparten en un documento sin contexto.
Hay una cuarta medida que a veces se pasa por alto: la documentación. Si el equipo sabe por escrito qué datos son sintéticos y de dónde salen, deja de haber discusiones sobre si una ficha concreta es real o inventada.
¿Qué se puede automatizar y qué no?
Se puede automatizar la generación. Es lo que hace un generador de datos: produce fichas coherentes por país, con la forma jurídica correcta, el domicilio, el teléfono y los identificadores con el formato del territorio elegido.
También se puede automatizar la carga de esos datos en el entorno de pruebas, y la limpieza posterior. Un proceso que repuebla la base de pruebas a partir de un generador es más seguro que uno que arrastra una copia de datos antiguos.
Lo que no conviene automatizar es la decisión sobre qué aspecto se está probando. Generar cien fichas al azar no sustituye a elegir los casos que representan una frontera del sistema. La automatización sirve para producir volumen y variedad; el criterio sobre qué casos importan sigue siendo humano.
Y hay una cosa que nunca debe automatizarse: el traslado de datos sintéticos a un documento con apariencia oficial. Un generador de datos es una herramienta de desarrollo; un justificante no lo es.
En el generador de este sitio
El generador de datos de empresa para pruebas de este sitio produce fichas de empresa a partir de un país y una clave de identidad: nombre, forma jurídica, sector, domicilio social, teléfono y los números de registro y de VAT con la forma de ese territorio. Cada clave devuelve la misma ficha, lo que permite usarla en pruebas repetibles y en enlaces compartidos dentro del equipo.
Todo lo que genera es sintético, está pensado para pruebas de software, demostraciones y desarrollo, y no corresponde a ninguna empresa real. No debe usarse para acreditar la existencia de un negocio, para emitir facturas reales ni para ningún trámite ante un tercero o una administración.
Para quien programa
Trabajar con datos ficticios es fácil hasta que el producto crece. Seis decisiones que evitan que se mezclen:
- Entornos aislados de verdad. Bases de datos distintas y credenciales distintas. Una columna que marque «es de prueba» dentro de la misma tabla no es aislamiento.
- Generación reproducible. Una clave que devuelve siempre la misma ficha permite repetir una prueba y comparar resultados. El azar puro dificulta la depuración.
- Nombres reconocibles. Que el dato se identifique como ejemplo sin necesidad de consultar nada. Es la última barrera cuando ya ha salido de su entorno.
- Ningún dato sintético en migraciones ni en copias de producción. Las herramientas de copia son la vía más común por la que un dato de prueba acaba donde no debe.
- Documentación del origen. Deja escrito de dónde salen los datos de prueba y cómo se regeneran. Ahorra discusiones y auditorías.
- Revisión antes de compartir. Cualquier captura, informe o demostración que salga del equipo debería pasar por una comprobación rápida de que no lleva datos reales.
Una última consideración de diseño: si tu producto permite crear registros de prueba desde la interfaz, deja claro en la pantalla qué son y cómo se eliminan. Los registros de prueba que nadie sabe borrar acaban conviviendo con los reales durante años.
Siguientes pasos
Si necesitas fichas sintéticas para tus pruebas, el generador de datos de empresa las produce por país con la clave que elijas. Para entender qué se puede comprobar de cada identificador y qué no, las guías del número de registro de empresa y de validación del número de identificación fiscal marcan esa frontera. Y si estás montando el flujo que recibe a un cliente empresarial, la lista de comprobación de KYB ordena las verificaciones que sí exigen datos reales.