Casi di test dei moduli di assunzione da coprire

I casi di test dei moduli di assunzione sono la metà visibile della qualità di un sistema di selezione, e la metà più spesso scritta partendo dal percorso felice e andando verso l’esterno. Un modulo che funziona quando un candidato compila correttamente ogni campo non è testato; viene soltanto osservato una volta.

Questo articolo espone perché i moduli a più passaggi nascondono difetti tra i loro passaggi, quali rami di candidato meritano un caso dedicato ciascuno, come i campi obbligatori si spostano al cambiare delle risposte e cosa succede quando la stessa persona invia due volte.

Perché i moduli a più passaggi nascondono così tanti difetti?

Perché ogni passaggio viene controllato da solo. Un modulo a pagina singola di solito viene testato dall’inizio alla fine, poiché l’intera interazione richiede un minuto. Un modulo diviso in cinque passaggi viene di solito testato un passaggio alla volta, dalla stessa persona, nella stessa sessione, partendo da uno stato che il passaggio precedente ha comodamente lasciato dietro di sé.

I difetti che sopravvivono vivono nelle cuciture. Un valore inserito al passaggio due e letto al passaggio quattro. Una regola di validazione che scatta quando si lascia un passaggio ma non quando il modulo viene ripreso in quel passaggio. Un campo obbligatorio in una direzione di marcia e silenziosamente opzionale nell’altra. Un pulsante indietro che scarta il contenuto del passaggio o, peggio, conserva i vecchi valori e li riscrive sopra quelli nuovi.

Due abitudini ne trovano la maggior parte. Percorri il modulo in un ordine inatteso, incluso all’indietro, e conferma che i valori sopravvivano al viaggio intatti. E inizia ogni caso al passaggio in esame con uno stato costruito direttamente, invece che ripetendo i passaggi precedenti — perché ripeterli significa che i passaggi precedenti fanno implicitamente parte di ogni caso, e un difetto lì farà fallire ogni caso per la stessa ragione e nasconderà il resto.

Quali rami di candidato meritano un proprio caso di test?

Almeno quattro, perché ciascuno esercita un insieme diverso di campi condizionali.

Un quinto ramo vale la pena di essere aggiunto nella maggior parte dei sistemi: il candidato che inizia, se ne va e torna molto più tardi. Quel caso non riguarda affatto il contenuto. Riguarda se lo stato parziale venga conservato, fatto scadere oppure accettato e inviato come se fosse completo.

I quattro rami interagiscono tra loro, e le interazioni sono dove la copertura si assottiglia silenziosamente. Una storia lunga inviata da un’altra regione combina voci ripetute con un ordinamento delle date straniero. A un candidato senza formazione che non ha neanche esperienza deve essere permesso di arrivare all’invio senza inventare contenuti per arrivarci. Testare i rami separatamente è necessario e non sufficiente; un piccolo numero di casi di combinazione cattura il resto.

Come cambiano i campi obbligatori con le risposte date?

Cambiano continuamente, e la regola che li governa è una dipendenza più che un elenco statico.

Un campo è obbligatorio a causa di qualcosa risposto prima, e quella dipendenza di solito attraversa due o tre passaggi invece che uno solo. Dichiarare un’abilitazione rende obbligatorio il numero dell’abilitazione e obbligatorio l’ente che l’ha rilasciata con esso. Selezionare un Paese cambia quali campi dell’indirizzo siano obbligatori e quali non vengano affatto offerti. Scegliere che l’esperienza esista rende obbligatoria l’intera sezione dell’esperienza, inclusi i sottocampi specifici che la descrivono.

Da queste dipendenze derivano tre modalità di fallimento. La prima è una regola applicata solo in avanti: il candidato seleziona l’opzione che rende obbligatorio un campo, lo supera, torna indietro e deseleziona l’opzione, e il campo ormai irrilevante viene ancora imposto. La seconda è una regola valutata nel momento sbagliato, così il requisito viene controllato quando il passaggio è mostrato ma non quando viene inviato, o viceversa. La terza è una regola che non può essere soddisfatta affatto, dove il modulo esige un valore in un campo che ha appena nascosto.

Testarle adeguatamente significa scrivere i casi come coppie di una selezione e della sua conseguenza attesa, invece che come un elenco di campi da compilare. La domanda a cui ogni caso risponde non è se un campo si validi ma se i requisiti del modulo corrispondano alle risposte date finora.

Cosa dovrebbe succedere con un invio ripetuto?

La risposta onesta per l’esperienza di un candidato è che un secondo invio dovrebbe essere o chiaramente riconosciuto come duplicato o chiaramente trattato come una nuova candidatura, e mai produrre silenziosamente un terzo stato che nessuno ha progettato.

Quattro situazioni vengono confuse, e ognuna ha bisogno di un proprio comportamento atteso. Un doppio clic su invia mentre la prima richiesta è ancora in corso, che dovrebbe produrre una sola candidatura. Un aggiornamento della pagina di conferma, che non dovrebbe reinviare. Una seconda candidatura deliberata per lo stesso ruolo dopo che ne è stata inviata una prima, che è una decisione di prodotto e dovrebbe essere esplicita. E la ripresa di una bozza già inviata, che non dovrebbe essere possibile.

Il comportamento delle bozze merita lo stesso trattamento. Una bozza salvata è un record parziale, e le regole su quanto vive, quando viene aggiornata e cosa ne accade quando il candidato non torna mai sono tutte decisioni dell’operatore più che leggi. Ciò su cui un test può insistere è che il comportamento sia coerente e che il candidato ne sia informato.

Per gli sviluppatori: costruire lo stato del modulo

Costruisci ogni caso da uno stato nominato invece che da una sequenza di clic. Un caso che dice che il candidato ha una sezione formativa completata ed è al passaggio dell’esperienza dovrebbe impostare quello stato direttamente, così il caso testa il passaggio e nulla più.

Quattro pratiche rendono la suite manutenibile. Nomina i casi secondo la condizione che esercitano, non secondo il passaggio su cui girano, perché il numero del passaggio cambia ogni volta che il modulo viene ridisegnato. Mantieni il contenuto riempitivo ovviamente sintetico — nomi segnaposto e datori di lavoro chiaramente fabbricati — così che nessun caso possa essere scambiato per i dati di una persona reale. Mantieni l’invio minimo valido in un unico posto, così che aggiungere un campo obbligatorio sia un cambiamento di una riga invece che una modifica a ogni caso. E tieni i messaggi di validazione fuori dalle asserzioni dove possibile, poiché la formulazione cambia molto più spesso del comportamento e una suite che fallisce sul testo è una suite che la gente smette di leggere.

Il contenuto usato in questi casi dovrebbe essere testo segnaposto in ogni sua parte. Non popolare mai un test di un modulo di assunzione con le informazioni di un candidato reale, neanche in un ambiente sicuro, perché quelle informazioni esistono poi da qualche parte dove non sarebbero mai dovute andare. Gli esempi su questo sito sono costruiti esattamente per questo scopo.

Prossimi passi

Prendi i quattro rami di candidato e controlla se ciascuno abbia un caso che arriva all’invio. Il ramo che di solito non ne ha nessuno è il candidato senza formazione e senza esperienza, ed è quello più probabilmente rotto, perché è quello che il team non compila mai a mano. Come vengono costruiti i documenti analizzati dietro un flusso di preselezione è trattato nelle fixture di parsing dei CV, e le regole sulle date che un modulo modellato sulla regione di solito sbaglia sono esposte nelle cronologie dell’esperienza lavorativa. Lo strumento per i profili professionali è dove generare un record quando un caso ha bisogno di un candidato plausibile dietro di sé.