Un proceso de análisis currículum convierte un documento en campos estructurados, y probarlo bien exige algo distinto de lo que suele hacerse. El obstáculo no es que exista un formato de referencia mal implementado, sino que no hay ninguno acordado: cada herramienta genera documentos con maquetaciones distintas, y el analizador tiene que recuperar la información de todas ellas. Esta guía explica cómo se organiza un conjunto de documentos de prueba para que siga siendo útil, por qué conviene nombrarlos por escenario y no por número y cómo detectar cuándo han dejado de servir.
¿Por qué no existe un formato único de currículum?
Porque nunca hubo una autoridad que lo fijara. Un currículum es un documento que cada persona redacta como quiere, con la ayuda de la herramienta que tenga a mano, y esas herramientas no comparten convenciones. Unas organizan el contenido en dos columnas, otras usan tablas invisibles para colocar los bloques, otras prefieren una única columna con secciones separadas por líneas.
A eso se suma la variación de idioma y de cultura. La sección de formación puede ir antes o después de la experiencia, los datos de contacto ocupan posiciones distintas y los apartados cambian de nombre según la región. Hay incluso documentos donde la trayectoria se escribe como un párrafo corrido, sin ninguna estructura reconocible a primera vista.
La consecuencia para las pruebas es importante. Un analizador no se evalúa comprobando si respeta un estándar, porque no hay estándar que respetar. Se evalúa midiendo cuánta información recupera correctamente en cada una de las formas en que el documento puede presentarse.
¿Qué variantes de maquetación hay que cubrir?
Lo que importa no es acumular documentos, sino cubrir las decisiones de diseño que cambian el trabajo del analizador. Una lista razonable de variantes incluye las siguientes.
- Una sola columna. La forma más sencilla, útil como caso base y como referencia de regresión.
- Dos columnas. El texto se lee en un orden que la posición visual no siempre respeta, y ahí es donde suelen aparecer las mezclas de secciones.
- Bloques en tabla. La información se coloca en celdas y el orden de extracción depende de cómo esté construida la tabla.
- Secciones separadas por líneas o colores. El énfasis es visual y no textual, de modo que un analizador que solo mira el texto pierde la jerarquía.
- Trayectoria en prosa. El contenido está ahí, pero no dividido en campos; hay que inferir dónde termina un puesto y empieza el siguiente.
- Lista de capacidades como etiquetas. Las habilidades aparecen agrupadas y separadas por signos, sin una estructura de pares.
- Encabezados con nombres distintos. La misma sección lleva otro título según la persona, la región o la herramienta.
- Documentos largos. Varias páginas con mucha experiencia acumulada, donde lo importante puede quedar fuera de la primera página.
Una buena forma de organizarlo es pensar en cada variante como una pregunta concreta sobre el comportamiento del analizador y no como un archivo más que hay que tener.
¿Escenarios o números de expediente?
La tentación de numerar los documentos es fuerte, porque ordena la carpeta y hace que la lista parezca completa. Pero un número no comunica nada a quien lee el resultado de una prueba fallida. Un informe que dice que el caso número siete no recuperó el campo de formación obliga a abrir el archivo para entender de qué se trataba.
Nombrar por escenario resuelve ese problema de raíz. Un nombre que describe la situación —documento con dos columnas, trayectoria escrita en un párrafo, capacidades agrupadas como etiquetas— hace que el fallo se entienda sin abrir nada y, sobre todo, permite decidir de inmediato si el caso es importante o periférico.
El nombre también sirve para detectar huecos. Cuando la colección se organiza por escenarios, es fácil ver qué situaciones no están cubiertas; cuando se organiza por números, la ausencia de un caso no se nota hasta que aparece el fallo en producción.
Conviene además que cada documento tenga asociado un conjunto de campos esperados. Sin esa expectativa explícita, el resultado del analizador no se puede evaluar de forma automática y la prueba se convierte en una inspección manual que nadie repite.
Por qué generar al azar hace que los fallos no se puedan repetir
Un analizador alimentado con documentos distintos en cada ejecución se comporta de manera distinta en cada ejecución. Cuando aparece un fallo, nadie puede saber si se debe a un cambio en el código o a un documento que antes no había salido. Investigar en esas condiciones consume un tiempo enorme y, con frecuencia, el fallo deja de reproducirse antes de que se encuentre la causa.
Esto no significa que la generación aleatoria no sirva. Sirve para explorar y para descubrir casos raros en grandes volúmenes. Lo que no puede hacer es sostener la prueba de regresión, que necesita un conjunto estable cuyos resultados se puedan comparar entre versiones.
La forma de combinar ambos usos es separarlos con claridad. Una colección fija garantiza que lo que funcionaba sigue funcionando; una generación variable busca lo que todavía no se ha cubierto. Cuando la segunda encuentra algo interesante, ese caso se incorpora a la colección fija, y a partir de ese momento pasa a formar parte de la red de seguridad.
Cómo se estropea un conjunto con el tiempo
Los conjuntos de documentos de prueba envejecen, y lo hacen de forma silenciosa. Los cambios más habituales son los siguientes.
| Forma de envejecer | Qué provoca |
|---|---|
| Nuevas versiones de las herramientas de origen | La maquetación por defecto cambia y los documentos antiguos dejan de representar lo que llega hoy |
| Aparición de idiomas nuevos | Los casos de cada idioma se quedan sin cubrir aunque la colección parezca amplia |
| Cambios en el modelo de datos | Los campos esperados ya no corresponden a lo que el sistema extrae |
| Acumulación sin revisión | Se añaden casos y no se retira ninguno, y nadie sabe cuáles siguen aportando |
| Expectativas obsoletas | El valor esperado se copió del resultado del propio analizador y ya no comprueba nada |
La última fila merece una advertencia aparte. Un conjunto cuyos valores esperados se generaron a partir de la salida del sistema no verifica nada: certifica que el sistema sigue haciendo lo mismo, aunque lo que haga sea incorrecto. Las expectativas tienen que provenir del documento, no del resultado.
En el generador de este sitio
El generador de currículums y datos de empleo falsos permite obtener perfiles completos y coherentes que después se pueden volcar a distintos formatos de documento para alimentar un analizador. Como las fichas se construyen a partir de una misma clave, el contenido es estable y dos ejecuciones con la misma clave producen la misma información, algo imprescindible para comparar resultados entre versiones.
Todo el material es sintético y está pensado para pruebas de software, demostraciones y carga de entornos. Ningún perfil corresponde a una persona real.
Si tu interés está en las reglas que debe respetar el contenido del propio documento, la guía sobre casos de prueba de formularios de selección cubre la otra mitad del proceso. Y para la estructura general del perfil, el artículo sobre datos de currículum para pruebas describe qué campos forman una ficha completa.
Para quien programa
- Separa la entrada de la expectativa. El documento que se analiza y los campos que se esperan obtener son dos artefactos distintos, con ciclos de vida distintos. Mezclarlos hace imposible saber si un fallo está en el analizador o en la expectativa.
- Haz que la colección sea reproducible. Un conjunto que cambia sin control convierte cualquier comparación entre versiones en una adivinanza. Si parte del material se genera, fija las claves o las semillas que lo reproducen.
- Escribe un nombre descriptivo en cada caso. El nombre es lo que aparece en el informe de fallo y lo que permite decidir si el caso es prioritario. Un identificador numérico obliga a abrir el archivo cada vez.
- Mide por campo, no por documento. Un documento puede recuperarse bien en conjunto y fallar en la fecha de un puesto concreto. El resultado útil es el detalle por campo, con el tipo de error claramente identificado.
- Fija una fecha de revisión. Los conjuntos de documentos de prueba se estropean sin avisar. Un repaso periódico, con la lista de herramientas de origen actualizada, evita que la red de seguridad se convierta en un conjunto de casos que ya nadie representa.
Un detalle de proceso que ahorra disgustos: cuando un caso falla y se decide aceptar el nuevo resultado como correcto, anótalo. Un conjunto de expectativas que se actualiza en silencio deja de distinguir entre una mejora y una regresión.
Siguientes pasos
Empieza por inventariar las maquetaciones que realmente llegan a tu sistema y comprueba cuáles de ellas tienen un caso asociado. Casi siempre aparecen dos o tres variantes que nadie había probado. Con el generador de perfiles profesionales puedes producir el contenido de esos casos de forma estable y repetible.
Para ver el mismo problema desde otra perspectiva, el artículo sobre los desajustes entre direcciones y códigos postales describe cómo se comportan los sistemas cuando un campo se interpreta mal por el contexto en que aparece, que es exactamente lo que ocurre al analizar un documento con columnas.
Y para cerrar, el alcance de lo anterior: los documentos y campos esperados que se usan en estas pruebas son muestras construidas. Son datos sintéticos para pruebas de software y demostraciones, no el contenido de currículums reales.