Cas de test de formulaire de recrutement à couvrir

Les cas de test de formulaire de recrutement sont la moitié visible de la qualité d’un système de recrutement, et la moitié la plus souvent écrite à partir du chemin nominal vers l’extérieur. Un formulaire qui fonctionne quand un candidat remplit correctement chaque champ n’est pas testé ; il est simplement observé une fois.

Cet article expose pourquoi les formulaires à étapes multiples cachent des défauts entre leurs étapes, quelles branches de candidat méritent chacune un cas dédié, comment les champs obligatoires évoluent à mesure que les réponses changent, et ce qui se passe quand la même personne soumet deux fois.

Pourquoi les formulaires à étapes multiples cachent-ils tant de défauts ?

Parce que chaque étape est vérifiée isolément. Un formulaire d’une seule page est habituellement testé de bout en bout, puisque toute l’interaction prend une minute. Un formulaire découpé en cinq étapes est habituellement testé une étape à la fois, par la même personne, dans la même session, en partant d’un état que l’étape précédente a commodément laissé derrière elle.

Les défauts qui survivent vivent dans les jointures. Une valeur saisie à l’étape deux et lue à l’étape quatre. Une règle de validation qui s’exécute quand on quitte une étape mais pas quand le formulaire est repris à cette étape. Un champ obligatoire dans un sens de parcours et silencieusement facultatif dans l’autre. Un bouton retour qui jette le contenu de l’étape ou, pire, conserve les anciennes valeurs et les réécrit par-dessus les nouvelles.

Deux habitudes en trouvent la plupart. Parcourez le formulaire dans un ordre inattendu, y compris à rebours, et confirmez que les valeurs survivent au trajet intactes. Et commencez chaque cas à l’étape testée avec un état construit directement, plutôt qu’en rejouant les étapes antérieures — car les rejouer signifie que les étapes antérieures font implicitement partie de chaque cas, et un défaut à cet endroit fera échouer chaque cas pour la même raison et masquera le reste.

Quelles branches de candidat méritent leur propre cas de test ?

Au moins quatre, car chacune exerce un ensemble différent de champs conditionnels.

Une cinquième branche vaut la peine d’être ajoutée dans la plupart des systèmes : le candidat qui commence, part, puis revient bien plus tard. Ce cas ne porte pas du tout sur le contenu. Il porte sur la question de savoir si l’état partiel est préservé, expiré, ou accepté et soumis comme s’il était complet.

Les quatre branches interagissent entre elles, et les interactions sont l’endroit où la couverture s’amincit silencieusement. Un long historique soumis depuis une autre région combine des entrées répétées avec un ordre de date étranger. Un candidat sans formation qui n’a pas non plus d’expérience doit pouvoir atteindre la soumission sans inventer du contenu pour y parvenir. Tester les branches séparément est nécessaire et non suffisant ; un petit nombre de cas de combinaison attrape le reste.

Comment les champs obligatoires changent-ils selon les réponses données ?

Ils changent constamment, et la règle qui les gouverne est une dépendance plutôt qu’une liste statique.

Un champ est obligatoire à cause de quelque chose répondu plus tôt, et cette dépendance court habituellement sur deux ou trois étapes plutôt qu’à l’intérieur d’une seule. Déclarer une licence rend obligatoire le numéro de licence et, avec lui, l’organisme émetteur. Sélectionner un pays change quels champs d’adresse sont obligatoires et lesquels ne sont pas du tout proposés. Choisir qu’une expérience existe rend obligatoire toute la section expérience, y compris les sous-champs précis qui la décrivent.

Trois modes de défaillance découlent des dépendances. Le premier est une règle qui n’est appliquée que dans un sens : le candidat sélectionne l’option qui rend un champ obligatoire, passe l’étape, revient en arrière et désélectionne l’option, et le champ désormais sans pertinence est toujours imposé. Le second est une règle évaluée au mauvais moment, si bien que l’exigence est contrôlée quand l’étape est affichée mais pas quand elle est soumise, ou l’inverse. Le troisième est une règle impossible à satisfaire, où le formulaire exige une valeur dans un champ qu’il vient tout juste de masquer.

Bien tester cela signifie écrire les cas comme des paires constituées d’une sélection et de sa conséquence attendue, plutôt que comme une liste de champs à remplir. La question à laquelle répond chaque cas n’est pas de savoir si un champ se valide, mais si les exigences du formulaire correspondent aux réponses données jusque-là.

Que devrait-il se passer lors d’une soumission répétée ?

La réponse honnête pour l’expérience d’un candidat est qu’une seconde soumission devrait soit être clairement reconnue comme un doublon, soit être clairement traitée comme une nouvelle candidature, et jamais produire discrètement un troisième état que personne n’a conçu.

Quatre situations sont confondues, et chacune a besoin de son propre comportement attendu. Un double clic sur envoyer alors que la première requête est encore en cours, qui devrait produire une seule candidature. Un rafraîchissement de la page de confirmation, qui ne devrait pas resoumettre. Une seconde candidature délibérée pour le même poste après une première soumission, qui est une décision produit et devrait être explicite. Et la reprise d’un brouillon déjà soumis, qui ne devrait pas être possible.

Le comportement des brouillons mérite le même traitement. Un brouillon enregistré est un dossier partiel, et les règles sur sa durée de vie, le moment de son rafraîchissement et ce qui lui arrive lorsque le candidat ne revient jamais sont toutes des décisions que l’exploitant prend plutôt que des lois. Ce qu’un test peut exiger, c’est que le comportement soit cohérent et que le candidat en soit informé.

Pour les développeurs : construire l’état du formulaire

Construisez chaque cas à partir d’un état nommé plutôt qu’à partir d’une séquence de clics. Un cas qui dit que le candidat a une section formation complétée et se trouve à l’étape expérience devrait fixer cet état directement, afin que le cas teste l’étape et rien d’autre.

Quatre pratiques rendent la suite maintenable. Nommez les cas d’après la condition qu’ils exercent, et non d’après l’étape sur laquelle ils s’exécutent, car le numéro d’étape change chaque fois que le formulaire est repensé. Gardez le contenu de remplissage manifestement synthétique — noms de substitution et employeurs clairement fabriqués — afin qu’aucun cas ne puisse être pris pour les données d’une personne réelle. Gardez la soumission minimale viable en un seul endroit, afin qu’ajouter un champ obligatoire soit un changement d’une ligne plutôt qu’une modification de chaque cas. Et gardez les messages de validation hors des assertions dans la mesure du possible, puisque la formulation change bien plus souvent que le comportement et qu’une suite qui échoue sur la copie est une suite que les gens cessent de lire.

Le contenu utilisé dans ces cas devrait être du texte de substitution du début à la fin. N’alimentez jamais un test de formulaire de recrutement avec les informations d’un vrai candidat, même dans un environnement sûr, car ces informations existent alors quelque part où elles n’auraient jamais dû aller. Les exemples de ce site sont construits exactement dans ce but.

Étapes suivantes

Prenez les quatre branches de candidat et vérifiez si chacune a un cas qui atteint la soumission. La branche qui n’en a habituellement aucun est le candidat sans formation ni expérience, et c’est celle qui a le plus de chances d’être cassée, parce que c’est celle que l’équipe ne remplit jamais à la main. La manière dont sont construits les documents analysés derrière un flux de présélection est traitée dans les fixtures d’analyse de CV, et les règles de date qu’un formulaire dépendant de la région rate habituellement sont exposées dans les chronologies d’historique professionnel. L’outil de profil de carrière est l’endroit où générer un dossier quand un cas a besoin d’un candidat plausible derrière lui.