Personas sintéticas para pruebas y demos
El software necesita registros con forma de persona antes de tener usuarios reales: formularios, importaciones, sandboxes de CRM y capturas de demostración. La familia People genera datos personales de muestra y los exporta en formatos comunes para que las fixtures sean reproducibles y no contengan datos personales reales.
Empiece por el generador de personas si necesita nombres, direcciones y campos de contacto para una prueba manual; para una herramienta que espera archivo, elija después la exportación estructurada adecuada.
Por qué importan los datos sintéticos
Reutilizar nombres, correos y teléfonos de producción en tickets, capturas o repositorios públicos crea riesgos de privacidad y cumplimiento. Los registros ficticios permiten probar validación, ordenación y serialización sin copiar personas vivas. Siguen pareciendo personas: correos con aspecto único, direcciones plausibles y campos parecidos a esquemas de producción. Son siempre ficción. No los presente como clientes reales ni use generadores para fraude, suplantación o abuso de cuentas.
Generador y exportadores
- Generador crea registros para pruebas interactivas.
- JSON produce arrays para APIs, scripts Node y mocks de frontend.
- XML sirve para integraciones antiguas y fixtures de estilo SOAP.
- CSV crea filas para hojas de cálculo y ensayos de importación.
- YAML resulta cómodo para ejemplos de configuración y GitOps.
Elija el formato que ya entiende el consumidor; convertirlo a mano introduce errores. Los campos habituales incluyen nombre, apellido, correo, teléfono y partes de dirección. En pruebas conviene afirmar estructura, tipos y cadenas no vacías, no fijar un nombre aleatorio que puede cambiar. Para CI determinista use semillas o archivos golden versionados; el generador del navegador es mejor para QA exploratoria.
Notas de formato y límites
JSON estricto no admite comas finales. Las hojas de cálculo pueden reinterpretar codificación, ceros iniciales y fórmulas que comienzan por =; abra CSV como texto cuando importe. XML requiere nombres, anidación y escape compatibles con el parser. YAML depende de la indentación; JSON es más seguro si hay ambigüedad entre YAML 1.1 y 1.2.
Estos datos no verifican identidad, no son pruebas KYC y no son PII de producción. El realismo de nombres y direcciones varía por región, y las herramientas del navegador son para lotes modestos, no millones de filas de carga. Etiquete archivos como sample- o fixture-, no los mezcle sin aviso con extractos reales y diversifique los datos para una QA inclusiva. Su finalidad es calidad de software, no afirmar identidades del mundo real.