En tant que testeurs de logiciels et ingénieurs en automatisation, nous pensons souvent au « chemin heureux » : le parcours que l'utilisateur empruntera le plus probablement lors de l'utilisation de notre application. Lorsque nous écrivons nos tests automatisés de l'interface utilisateur, nous voulons nous assurer d'automatiser ces chemins heureux, et lorsque nous rédigeons des automatisations d’API, nous voulons vérifier que chaque endpoint renvoie une réponse “200 OK” ou une réponse réussie similaire.
Mais il est important de penser aux tests négatifs dans nos tests manuels et automatisés. Voici quelques raisons à cela.
Nos tests automatisés peuvent réussir pour de mauvaises raisons
Lorsque j’ai commencé à écrire des tests UI automatisés en JavaScript, je ne comprenais pas le concept de promesse. Je supposais simplement que lorsque je faisais une requête pour localiser un élément, elle ne renverrait cet élément que lorsqu'il serait effectivement localisé. J'étais tellement ravi de voir mes tests revenir avec le résultat vert “Réussi” jusqu’à ce qu’un collègue me suggère d’essayer de faire échouer le test en vérifiant une autre valeur. Il a de nouveau réussi, car il validait en fait la promesse existante, qui renvoyait toujours “Vrai”. Cela m’a appris une leçon précieuse : ne supposez jamais que vos tests automatisés fonctionnent correctement simplement parce qu’ils réussissent. Veillez à exécuter certains scénarios où vos tests doivent échouer, et assurez-vous qu’ils échouent réellement. Ainsi, vous pouvez être sûr de tester ce que vous pensez tester.
Les tests négatifs peuvent révéler des erreurs mal gérées qui pourraient impacter un utilisateur
Lors des tests d’API, toute erreur liée au client doit aboutir à une réponse de type 400 plutôt qu’à une erreur serveur de type 500. Si, lors de tests négatifs, vous découvrez qu’une réponse 403 revient maintenant sous forme de 500, cela peut signifier que le code ne prend plus en charge ce cas d’utilisation correctement. Une réponse 500 du serveur peut empêcher l’utilisateur d’obtenir les informations nécessaires à la correction de son erreur, ou pire encore, faire planter l’application.
Les tests négatifs peuvent révéler des failles de sécurité
Aussi important qu’il soit de s’assurer qu’un utilisateur puisse se connecter à une application, il est tout aussi crucial de s’assurer qu’un utilisateur ne puisse pas s’y connecter lorsqu’il n’est pas censé le faire. Si vous ne lancez un test de connexion qu’avec un nom d’utilisateur et un mot de passe valides, vous passez à côté d’un aspect essentiel ! J’ai déjà vu des situations où un utilisateur pouvait se connecter avec n’importe quel mot de passe, avec un mot de passe vide, ou encore avec un nom d’utilisateur et mot de passe incorrects.
Il est également crucial de vérifier que certains utilisateurs n’ont pas accès à certaines parties d’une application. Une page d’administration parfaitement testée et fonctionnelle ne sert pas à grand-chose s’il s’avère que n’importe quel utilisateur lambda peut y accéder.
Les tests négatifs maintiennent votre base de données propre
Comme je l’ai mentionné au chapitre 12, disposer de données bonnes et valides dans votre base de données contribuera à la bonne santé de votre application. Des données qui ne respectent pas les attentes peuvent entraîner le crash des pages web, leur dysfonctionnement ou une mauvaise présentation de l’information. Plus vous effectuez de tests négatifs sur vos saisies, plus vous pouvez garantir que seules de bonnes données seront conservées.
Pour chaque champ de saisie dont j’ai la charge, j’aime savoir exactement quels caractères sont autorisés. Je peux ensuite exécuter toute une série de tests négatifs pour m’assurer que les saisies contenant des caractères interdits sont bien refusées.
Parfois, les utilisateurs empruntent la voie négative
Il est très facile, surtout lorsqu’une nouvelle fonctionnalité est développée rapidement pour respecter une échéance, d’oublier de tester les parcours utilisateurs où ils cliquent sur les boutons Annuler ou Supprimer. Mais les utilisateurs font cela tout le temps ; pensez simplement au nombre de fois où vous avez envisagé un achat en ligne puis décidé de retirer un article du panier. Imaginez votre frustration si vous n’étiez pas en mesure de supprimer quelque chose de votre panier, ou si un bouton Annuler ne vidait pas un formulaire pour vous permettre de recommencer. L’expérience utilisateur dans ce domaine est tout aussi cruciale que le parcours heureux.
Le test logiciel consiste à rechercher les comportements inattendus pour pouvoir les corriger avant que l’utilisateur ne les rencontre. Lorsque les tests négatifs sont combinés aux tests du parcours heureux, nous pouvons garantir que nos utilisateurs n’auront pas de mauvaises surprises.
Si vous souhaitez encore optimiser vos processus de tests, pensez à intégrer un outil de gestion de base de données de premier plan pour gérer vos besoins complexes en données.
Le livre "The Complete Software Tester"
Lorsque j’ai découvert ma passion pour le test logiciel en 2009, je voulais apprendre tout ce que je pouvais sur le sujet, mais j’ai trouvé très peu d’ouvrages capables de m’instruire. J’ai donc appris par essais et erreurs, en lisant des articles de blog et en discutant avec mes collègues. Aujourd’hui, il existe d’excellents livres sur certains aspects du test logiciel, comme le test exploratoire, le test agile ou l’automatisation des tests, mais à ma connaissance il n’existe pas de livre qui se veuille une référence complète sur le sujet.
J’ai écrit The Complete Software Tester parce que je voulais offrir aux nouveaux et aux testeurs expérimentés les idées et les outils nécessaires pour être aussi efficaces que possible. Pour obtenir rapidement des astuces QA et d’autres recommandations de livres, abonnez-vous à la newsletter The QA Lead.
Lecture connexe : QU'EST-CE QUE ZEPHYR SCALE ?
Liste d'outils associés :
- LOGICIELS DE TEST DE PERFORMANCE POUR LES ÉQUIPES QA
- OUTILS D’AUTOMATISATION DE TESTS ETL POUR LES ÉQUIPES QA
À consulter également :
