happy path

C’est quoi le parcours heureux et quelles sont ses alternatives ?

11 Septembre 2020

Dans les tests logiciels, le parcours heureux, traduit en Anglais par le Happy path, est un type de test logiciel qui utilise une entrée connue et produit une sortie attendue. Également appelée test du chemin d'or, l'approche du Happy path est étroitement scénarisée. Le Happy path ne reproduit pas les conditions du monde réel et vérifie uniquement que la fonctionnalité requise est en place et fonctionne correctement. Si des alternatives valides existent, le Happy path est alors identifié comme le scénario par défaut ou l'alternative positive la plus probable sans conditions exceptionnelles ou d'erreur.

Si vous avez besoin d'un exemple, les scénarios de Happy path qui couvrent la connexion des utilisateurs ignoreront les entrées non valides, les problèmes de connexion ou les erreurs de serveur possibles.

Happy path vs. Unhappy path

Happy path vs. Unhappy path !

Les partisans des tests happy-path pensent qu'il est possible pour les développeurs de se concentrer sur un chemin optimal et de créer les fonctionnalités requises tout en laissant la place aux bugs en production. Cependant, d'autres ne sont pas du tout d'accord. Les critiques des tests happy-path affirment que, étant donné que les scénarios happy-path excluent les exceptions et les erreurs humaines, il est possible de laisser des espaces pour les valeurs nulles, les valeurs incorrectes et diverses erreurs de validation. L'argument le plus fort contre les tests happy-path est que tester uniquement des scénarios UX bien définis peut fournir une illusion de sécurité qui n'existe pas dans la vie réelle.

Happy path exemple

Il n'y a pas de nom convenu pour l'opposé des chemins heureux : ils peuvent être connus sous le nom de chemins tristes, de mauvais chemins ou de chemins d'exception. Le terme « chemin malheureux » ou unhappy path gagne en popularité car il suggère un complètement opposé au « Happy path » et conserve le même contexte.

Or, généralement il n'y a pas de « unhappy path » dans le vrai sens du terme, car le Happy path atteint la fin totale, mais un unhappy path est plus court. Il se termine bien avant la fin souhaitée. Et contrairement à un seul Happy path, il existe de nombreuses façons différentes où les choses peuvent mal tourner. Il n'y a donc pas de critère unique pour déterminer « le chemin malheureux ». Les chemins heureux et malheureux peuvent être utiles à la fois dans le développement piloté par le comportement (BDD) et le développement piloté par les tests (TDD). En général, les tests BDD garantissent que le logiciel se comporte comme l'attend un utilisateur et doit être accessible aux parties prenantes. Les tests TDD s'assurent eux que le logiciel fonctionne à un niveau technique.

En d'autres termes, vous pouvez utiliser BDD pour vous assurer que les chemins malheureux créent des messages d'erreur utiles ou des rappels de flux de travail et utiliser TDD pour détecter les anomalies que l'application pourrait générer.

Doit-on se contenter de tester le happy path uniquement ?

Happy path exemple

Tout comme la zone de confort proverbial, le Happy path vous donne une illusion de sécurité. Cette illusion se brise rapidement si vous ne testez que des scénarios UX bien définis.

Pour revenir à notre exemple de connexion, vous souhaiterez étendre votre suite de tests avec des séquences alternatives d'actions utilisateur. Disons que l'utilisateur appuie accidentellement sur Entrée après avoir tapé le login, déclenchant un avertissement concernant le mot de passe manquant. Voyant l'avertissement, l'utilisateur fournira l'entrée manquante et appuyez sur Entrée pour soumettre.

Ce scénario UX implique un chemin alternatif où les utilisateurs utiliseront les mêmes actions et atteindront le même objectif, mais dans des conditions différentes et avec des étapes supplémentaires. En outre, il existe des chemins d'exception qui entraînent des scénarios UX en échec :

  • identifiant, mot de passe ou les deux invalides,
  • le serveur est surchargé ou il y a un timeout de passerelle,
  • l’utilisateur entre des informations d'identification non valides, appuie sur Soumettre, puis répète la même procédure 100 fois, chaque fois avec un nouveau login et mot de passe invalides.

Idéalement, votre suite de tests de régression de l'interface utilisateur doit gérer tous ces cas, car chaque cas traite de nouveaux états d'interface utilisateur. Que faire si l’avertissement concernant le mot de passe n’est pas présent ou si les pages d’erreur 500 et 504 présentent des mises en page défectueuses ? Ou pire, que se passe-t-il si votre page de connexion n'affiche pas de captcha pour exclure une attaque de bot?

Ce que tout cela nous dit, c'est que le Happy path n'est qu'un point de départ. Fondamentalement, vous devez commencer par des cas de test qui automatisent le Happy path, puis étendre votre suite avec des chemins alternatifs et des flux d'exceptions.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *