Un generatore di dati di curriculum costruisce un’intera storia di carriera — una persona, una sequenza di ruoli con date di inizio e fine, una storia formativa, un elenco di competenze, un insieme di certificazioni e un’aspettativa salariale — assemblata in modo che le parti abbiano senso insieme. Alimentare un parser un campo alla volta non testa quasi nulla; alimentarlo con una cronologia coerente è ciò che espone i difetti che i team spediscono davvero.
Questa guida copre cosa si aspetta un sistema di selezione da un record di candidato, quali regole sulla cronologia un generatore deve rispettare, perché titoli di lavoro e competenze devono provenire da una tassonomia consapevole del paese e dove si colloca il confine della privacy quando il record assomiglia a una persona. Alla fine dovreste sapere quali asserzioni appartengono a un test di un modulo di assunzione e quali proprietà di un curriculum sono più difficili di quanto appaiano.
Cosa fa un sistema di selezione con un record di candidato?
Un sistema di tracciamento dei candidati riceve un documento, lo analizza in campi strutturati, lo deduplica rispetto ai candidati esistenti, lo valuta, lo instrada a un revisore e lo memorizza per un periodo di conservazione. Ognuno di questi passaggi può essere testato solo se l’input assomiglia a una carriera reale anziché a un elenco di parole chiave.
L’analisi è il passaggio in cui i dati generati guadagnano il loro posto. Un parser deve trovare il datore di lavoro, il titolo, le date e la località dentro testo libero, e le sue modalità di fallimento sono specifiche: un titolo letto come datore di lavoro, un mese e un anno letti come un intervallo, una località assorbita nel titolo di lavoro, un documento di due pagine concatenato in modo errato. Quei difetti appaiono solo quando l’input ha la forma di un documento reale. Gli errori si raggruppano anche attorno alla gestione dei file anziché al testo: un documento con una tabella al posto di un elenco, un’intestazione che si ripete su ogni pagina, un nome contenente un accento che arriva con la codifica sbagliata o un layout a due colonne letto da sinistra a destra attraverso entrambe. I record generati rendono quelle varianti economiche da produrre ed economiche da conservare come fixture.
L’abbinamento è il secondo passaggio e dipende dal fatto che i campi concordino. Un candidato il cui ruolo più recente è in un paese e il cui indirizzo è in un altro non è insolito in pratica, ma un candidato le cui date di formazione seguono le sue date di impiego lo è. Un generatore che rispetta la cronologia vi dà record che esercitano onestamente la logica di abbinamento. La deduplicazione è un test correlato, perché dipende da quasi-corrispondenze anziché da corrispondenze esatte: la stessa persona due volte con un cognome con trattino, un cognome da nubile, un indirizzo email diverso o un nome di azienda abbreviato diversamente. Produrre quelle varianti di proposito è l’unico modo affidabile per scoprire se il passaggio di fusione conserva il record giusto. L’articolo dati del profilo di carriera di test copre l’insieme di campi più ampio, e l’articolo fixture di test per l’analisi dei curriculum mostra come trasformare i record generati in documenti su cui eseguire un parser.
Quali regole sulla cronologia devono valere
La prima regola è che un ruolo termina dopo che inizia. Sembra banale ed è costantemente violato dalle fixture costruite a mano, perché le due date vengono inserite in posti separati e nulla impone il rapporto tra loro. Qualsiasi record in cui la fine precede l’inizio fallirà un validatore di cronologia e, se la suite di test non ha un simile validatore, verrà memorizzato e in seguito romperà un report.
La seconda regola riguarda lacune e sovrapposizioni. Una carriera può contenere una lacuna tra i ruoli, e le lacune sono legittime e comuni. Le sovrapposizioni sono possibili anche quando qualcuno ha ricoperto due posizioni contemporaneamente, ma sono abbastanza rare perché un generatore debba trattarle come un caso deliberato anziché predefinito. Ciò che conta è che la scelta sia esplicita: un set di dati che non produce mai lacune non testerà mai il percorso di gestione delle lacune, e uno che non produce mai sovrapposizioni non testerà mai l’avviso di sovrapposizione.
La terza regola è che la formazione precede o accompagna il primo impiego. Un candidato può lavorare mentre studia, quindi i due possono sovrapporsi, ma un titolo di studio conseguito prima che la persona fosse abbastanza grande per lavorare è un difetto. È qui che una data di nascita generata e una cronologia formativa generata devono derivare l’una dall’altra anziché essere estratte in modo indipendente.
La quarta regola riguarda il presente. Esattamente un ruolo può essere quello attuale, e non dovrebbe avere data di fine. Un set di dati in cui diversi ruoli sono contrassegnati come attuali, o in cui il ruolo più recente è terminato anni fa mentre il candidato è descritto come attivamente in cerca, produce segnali incoerenti che una vera pipeline di selezione segnalerebbe.
Perché titoli di lavoro e settori hanno bisogno di una tassonomia?
Un titolo di lavoro non è testo libero con un significato chiaro. Lo stesso lavoro si chiama in modo diverso in aziende, settori e paesi diversi, e il livello implicato da un titolo varia con tutti e tre. Un generatore che concatena una parola casuale di seniority con un sostantivo casuale produce titoli che nessun sistema raggrupperà correttamente.
L’approccio utile è una tassonomia in cui ogni titolo appartiene a una funzione e a un livello, e ogni funzione appartiene a un insieme di settori in cui appare plausibilmente. Un titolo del settore sbagliato è un record che un algoritmo di abbinamento valuterà in modo insensato, e un livello che contraddice gli anni di esperienza nel record è un record di cui un revisore diffiderebbe immediatamente. L’articolo titoli di lavoro per settore spiega come vengono costruite le raggruppazioni.
Le competenze seguono la stessa logica. Un elenco di competenze dovrebbe essere plausibile per il ruolo, e un ruolo senior dovrebbe portare una combinazione diversa da uno junior. I livelli di competenza sono di solito espressi su una scala, e un record che dichiara il livello massimo per ogni competenza è tanto poco informativo quanto uno che non dichiara nulla. L’articolo tassonomia e livelli delle competenze copre come sono definite le scale e perché conta il numero di gradini.
Certificazioni e licenze aggiungono una terza dimensione, perché alcuni ruoli le richiedono e altri no, e una licenza di solito è legata a una giurisdizione. Un record che dichiara una licenza emessa da un paese mentre la storia lavorativa è in un altro è un difetto di coerenza che vale la pena generare deliberatamente come caso di test negativo. L’articolo dati su licenze e certificazioni descrive gli schemi.
Come dovrebbero essere gestiti stipendio e valuta
Lo stipendio è il campo che più probabilmente viene memorizzato in una forma che non può rispondere a domande in seguito. Un numero senza una valuta e un periodo non è uno stipendio; è un numero. Trentamila significa cose diverse come cifra annua in una valuta e come cifra mensile in un’altra, e un set di dati che omette entrambi i campi produrrà report che nessuno riesce a riconciliare.
Il modello utile memorizza un importo, un codice valuta e un periodo come annuo o mensile, e tratta tutti e tre come obbligatori insieme. Dove la valuta differisce dal paese del ruolo, il record dovrebbe dirlo deliberatamente anziché per caso, perché la retribuzione transfrontaliera è un caso reale che una suite di test dovrebbe includere. L’articolo valuta e periodo dello stipendio esamina le combinazioni.
La formattazione della valuta introduce una seconda classe di difetti. Separatori delle migliaia, separatori decimali, posizionamento del simbolo di valuta e importi negativi dipendono tutti dalla località, e un parser che presuppone una convenzione leggerà male i valori di un’altra. I record generati vi danno un modo economico per far passare diverse convenzioni attraverso lo stesso percorso di codice, compresa l’inversione che trasforma una virgola decimale in un separatore delle migliaia. Mantenere il codice valuta accanto all’importo, anziché dedurlo dal paese, è ciò che rende stabili quelle asserzioni quando lo stesso record viene letto sotto una località diversa.
Gli intervalli valgono la pena di essere testati separatamente. Molti moduli accettano un minimo e un massimo, e il rapporto tra loro è lo stesso tipo di vincolo delle date di impiego: il minimo non deve superare il massimo. Valori negativi e zero valgono anch’essi la pena di essere inclusi, perché una pipeline che li memorizza allegramente finirà per produrre un annuncio senza senso.
La conservazione merita un test a sé. Un record di candidato porta una data di eliminazione o un orizzonte di politica, e il flusso che anonimizza o rimuove un record quando quell’orizzonte passa è facile da sbagliare e viene raramente esercitato con un orologio controllato. Usare record generati con date che potete spostare rende quel flusso testabile senza attendere che passi il tempo reale, che è l’unico modo in cui la maggior parte dei team lo testa mai.
Cosa dovrebbero verificare i test dei moduli di assunzione
Testate l’analisi, non solo l’inserimento. Inviate un documento generato e verificate che i campi analizzati corrispondano al record che lo ha prodotto, nome per nome e data per data. Questo singolo test è il più prezioso della suite perché copre l’intero percorso di estrazione anziché solo il modulo.
Testate i validatori di cronologia con record deliberatamente rotti: una data di fine prima di una data di inizio, due ruoli attuali, una voce di formazione che inizia prima della data di nascita. Ciascuno dovrebbe produrre un rifiuto specifico anziché un errore generico, e la specificità è essa stessa una proprietà che vale la pena verificare.
Testate il percorso di conservazione ed eliminazione. Un record di candidato porta un periodo di conservazione, e un sistema che conserva i record a tempo indefinito è un problema di conformità anziché funzionale, il che lo rende facile da trascurare in una suite funzionale. L’articolo conservazione dei dati HR spiega a cosa servono i periodi e perché variano per giurisdizione.
Testate i campi ai loro confini. Un elenco di competenze con zero voci, una storia di carriera con un solo ruolo, un nome contenente un apostrofo o un segno diacritico, un nome di datore di lavoro al limite di lunghezza del campo. L’articolo casi di test per il modulo di assunzione li raccoglie in un file riutilizzabile, e il generatore di dati di carriera su questo sito produce record che soddisfano già le regole di coerenza, così che i casi limite siano l’unica cosa rimasta da variare.
Cos’è e cosa non è un curriculum sintetico
Un curriculum generato non descrive nessuno. Il nome è inventato, i datori di lavoro sono inventati, le date sono inventate e i risultati sono inventati. Nulla nel record corrisponde alla storia di una persona reale, e nessun datore di lavoro nominato in un record generato ha mai impiegato qualcuno.
È esattamente per questo che il record è sicuro da usare nei test. Poiché non viene descritto alcun candidato reale, una fixture non può far trapelare i dati di un candidato, e uno screenshot di un ambiente di staging non può divulgare la storia lavorativa di nessuno. L’articolo dati sintetici versus anonimizzati spiega perché i record inventati e i record de-identificati sono cose diverse, e perché solo i primi sono privi di rischio di re-identificazione.
Il confine conta anche per la conservazione. Un record sintetico non ha un soggetto con diritti su di esso, ma può trovarsi nello stesso sistema dei record reali, e un set di dati che mescola i due è uno in cui le richieste di cancellazione diventano difficili da soddisfare. Mantenete i record generati identificabili come generati e teneteli fuori da qualsiasi archivio che contenga dati reali di candidati.
Ogni record prodotto in questo modo è un dato di test sintetico solo per il test del software. Non deve essere inviato come candidatura di qualcuno, usato per impersonare un candidato o un datore di lavoro, usato per ottenere un lavoro o una credenziale, o usato per testare un sistema che non gestite voi.