Interpréter un rapport de test de codage

Guide pour interpréter les résultats d’un test de codage.

Les tests de codage sont des tests techniques destinés à évaluer les compétences en codage d’un·e candidat·e. En plus de fournir un score en pourcentage, nous vous donnons la possibilité de voir comment les candidat·e·s se sont réellement comporté·e·s pendant le test. Cet article explique comment lire et comprendre le rapport. Les tests de codage sont disponibles pour tous les forfaits.

Durée de lecture : 4 minutes environ

Dans cet article

  1. Résultat global
  2. Rapport de test de codage
  3. Cas de test et cas de validation
  4. Messages d’erreur
  5. Questions fréquentes

Résultat global

Le résultat global se trouve dans la section Test de la page des résultats des candidat·e·s :

Vous pouvez voir ici le score obtenu par les candidat·e·s, ainsi que le temps pris.

Cliquez sur le lien (Rapport) pour afficher le rapport de test détaillé.

 

Rapport de test de codage

Le rapport du test de codage apparaît dans un nouvel onglet de votre navigateur.

En haut de la page, vous pouvez envoyer ce rapport par e-mail à votre collègue. Le rapport sera à sa disposition pendant 14 jours.

Conseil : Votre collègue ne doit pas nécessairement être un utilisateur de TestGorilla pour voir le rapport. Il lui suffit de suivre le lien contenu dans l’e-mail pour le consulter, pas besoin de se connecter !

Score du test. Le score du test représente le pourcentage des cas de test de validation qui sont validés. Le score du test se décompose en un score d’exactitude et un score de performance, bien que la plupart des tests de codage ne comportent qu’un score d’exactitude.

Score d’exactitude. Le score d’exactitude englobe tous les cas de test de validation qui déterminent si une saisie donnée renvoie le résultat requis.

Question. La question de codage que les candidat·e·s ont reçue. Chaque test de codage de notre bibliothèque dispose d’une base de données de questions de codage possibles. Une seule d’entre elles est posée à la personne candidate lors de l’épreuve. La question donne généralement un certain contexte, précise les exigences et fournit quelques exemples pour illustrer comment le code doit fonctionner.

Frise chronologique. Vous pouvez lire le code du début à la fin en utilisant la frise chronologique. Cela vous permet de voir comment tout s’est déroulé. Sur la frise chronologique, nous indiquons quand les candidat·e·s ont copié et collé des éléments du code. Les éléments collés sont surlignés en jaune dans l’éditeur.

Solution. Cette fenêtre est dynamique : les informations affichées dépendent de la position sur la barre de la frise chronologique. Au début de la frise chronologique, cette fenêtre sera en grande partie vide. À la fin de la frise chronologique, vous pourrez voir la saisie finale des candidat·e·s avant de remettre leur solution.

Résultats de l’utilisateur·rice et résultat validé. Ici, vous pouvez voir les réponses des candidat·e·s à chaque cas de test ainsi que les résultats proposés. En cliquant sur chaque cas de test, le résultat attendu s’affiche ainsi que le résultat de l’utilisateur·rice basé sur le code des candidat·e·s. Le résultat validé est le résultat de la présentation finale des candidat·e·s pour l’exercice, et il détermine s’ils ou elles réussissent ou échouent.

 

Cas de test et cas de validation

Un cas de test est un scénario fictif dans lequel le code des candidat·e·s est testé lorsqu’ils ou elles choisissent d’exécuter le code pendant le test. L’objectif est pour elles et eux de s’assurer que le code fonctionne. Ces cas de test permettent de vérifier si une saisie donnée dans leur code renvoie le résultat requis. Essentiellement, les candidat·e·s utilisent des cas de test pour voir s’ils ou elles sont sur la bonne voie. Les résultats des cas de test n’ont aucune influence sur le score du test.

Un cas de validation est l’exercice de codage réel qu’un·e candidat·e doit résoudre et qui détermine le score du test. Après avoir remis son code final, celui-ci est entièrement validé et vérifié pour s’assurer qu’il produit le résultat escompté. Un échec au cas de validation signifie échouer l’exercice. Pendant le test, les candidat·e·s ne peuvent pas voir si leur code est correct dans les cas de validation.

En théorie, il est possible d’échouer dans les cas de test, mais de réussir dans le cas de validation. Il est également possible de réussir dans les cas de test, puis d’échouer dans le cas de validation. 

 

Messages d’erreur

Dans le cas où les candidat·e·s échouent aux cas de test ou de validation, nous leur présentons un message d’erreur. Voici quelques-uns des messages d’erreur types qui peuvent s’afficher :

  • La tâche a rencontré des erreurs. Une exception s’est produite pendant l’exécution d’au moins un cas de test. Dans ce cas, le score est de 0 %, même si certains cas de test ont été un succès, car aucun des cas de validation n’a été terminé avec succès.
  • La tâche a atteint un statut inconnu. Le code n’a pas pu être compilé. Cela peut se produire, par exemple, si les candidat·e·s ont modifié la signature de la fonction. Dans ce cas, aucun des cas de test n’est un succès, et le score du test est de 0 %.
  • La tâche a expiré. Le code n’a pas pu être exécuté dans la limite de temps d’exécution donnée. Cela entraîne un score de 0 % au test.
  • Type d’opération non pris en charge. Cela indique que les candidat·e·s ont utilisé une opération qui n’est pas prise en charge par la bibliothèque de code particulière utilisée pour ce scénario de test. Par exemple, utiliser une commande mySQL au lieu d’une commande SQLite.

 

Questions fréquentes

Un score de 0 % signifie-t-il que le ou la développeur·euse est mauvais·e et que je ne devrais pas l’engager ?

Pas nécessairement. Vous vous souvenez de votre professeur de mathématiques qui vous encourageait toujours à rendre vos devoirs ? C’est parce que si vous ne le faisiez pas, vous ne pouviez pas obtenir de crédit partiel.

Malheureusement, un système informatique ne peut pas vraiment accorder de crédit partiel : soit le code fonctionne, soit il ne fonctionne pas. C’est exactement la raison pour laquelle nous partageons le rapport de codage. Il permet à n’importe quel·le développeur·se interne d’examiner la solution des candidat·e·s et de prendre une décision plus éclairée.

Le code aurait pu être parfait, à l’exception d’une petite coquille que le ou la candidat·e n’a pas eu le temps de corriger, d’où un score de 0 %. Vous pourriez passer à côté d’un·e excellent·e candidat·e si vous ne demandiez pas à un·e développeur·se d’examiner le code. 

À qui puis-je communiquer le rapport de codage ?

Le rapport peut être partagé avec n’importe qui, qu’il s’agisse d’un·e utilisateur·rice enregistré·e de TestGorilla ou non. Il vous suffit de saisir l’adresse e-mail de la personne souhaitée et nous lui envoyons un lien direct vers le rapport. Il n’est pas nécessaire de se connecter à l’application pour le consulter.

Si vous n’êtes pas développeur·se, ou si vous avez des connaissances limitées en codage, nous vous recommandons de demander à une personne qualifiée d’examiner le rapport pour vous. Cette personne sera en mesure d’apporter un éclairage supplémentaire sur les performances et la présentation des candidat·e·s.

Qu’est-ce qu’un score de performance ?

Les cas de test de performance constituent le score de performance. Ces cas de test exigent non seulement un résultat correct, mais aussi que ce résultat soit renvoyé dans un délai donné (en millisecondes).

Les cas de test de performance ne sont utilisés que s’il existe une exigence d’efficacité dans le code. Le score de performance sera affiché sous le score d’exactitude, le cas échéant.



Cet article vous a-t-il été utile ?
Utilisateurs qui ont trouvé cela utile : 13 sur 22

Articles dans cette section