10 minutes dans la peau d’un QA
Faites le premier pas et exercez-vous pour devenir un QA.
La théorie c’est bien, un peu de pratique c’est mieux !
C’est quoi un QA ?
Le QA (Quality Assurance) c’est le garant de la qualité d’un produit à livrer. En creusant un peu plus, le métier de QA figure parmi les plus vieux métiers du monde, qui est tout simplement « TESTEUR ».
Prenons un exemple parmi tant d’autres pour illustrer mes propos.
Dans l’ancien temps, les rois et reines étaient les cibles d’empoisonnement. Vous savez quoi ? Ils avaient des TESTEURS avant de manger chaque repas. Et oui, il en fallait beaucoup de testeurs car 1 fois sur 2, il fallait les remplacer ;-(
C’est peut-être de là que vient l’expression : « Le client est Roi » ? 😉
Quel que soit l’objet ou le logiciel à tester, un QA a pour rôle de se mettre à la place du client final. Son objectif est d’anticiper le maximum de scénarios (du plus simple au plus tordu) possibles dans le but d’assurer la qualité et ainsi livrer un meilleur produit pour satisfaire le client.
Comment feriez-vous pour tester un MUG ?
Il faut se mettre à la place d’un utilisateur final et effectuer toutes les actions (volontaires ou non) qu’il pourrait être amené à faire dessus.
Comment fait-on pour tester un mug ? Le premier réflexe est de se dire : « On vérifie qu’on puisse mettre du thé ou du café dedans »
OUI mais quoi encore ?
Réfléchissez un peu à d’autres scénarios avant de lire la suite, sinon, ce n’est pas drôle !
Voici donc quelques scénarios non exhaustifs qu’on peut faire pour ce produit :
- En cas nominal, vérifier qu’on puisse y verser de l’eau (chaude ou froide) sans qu’il se déforme ou se casse.
- Vérifier qu’il est bien stable quand on le pose car on va y mettre de l’eau bouillante (sécurité minimum)
- Vérifier qu’il tient aussi dans le frigo avec du fondant au chocolat s’il en reste 😀
- Vérifier que c’est ergonomique et qu’on puisse le tenir facilement (mains d’enfant et d’adulte)
- Vérifier qu’il puisse aller dans le micro-onde (pas de résidu ou imprimé métallique par exemple)
- Vérifier qu’il puisse aller dans le lave-vaisselle (les imprimés ne doivent pas se décoller)
- Vérifier sa solidité quand on va mélanger le sucre avec une cuillère en métal
- Vérifier que quand il se casse, il n’y ait pas trop de risque de se couper comme pour du verre
- Vérifier la durabilité dans le temps, au bout de combien de lavages, l’imprimé disparaît par exemple
- etc ….
Et si on essayait le test avec un stylo ?
La personne qui m’a fait faire cet exercice lors d’un entretien se reconnaîtra en passant par ici.
Même chose, pensez aux utilisateurs finaux d’un stylo et pensez à des scénarios de tests que vous pourriez faire afin d’en garantir la qualité.
Comme précédemment, voici les scénarios, toujours non exhaustifs, pour vous donner des idées de ce qui se passe dans la tête d’un QA :
- Première chose, vérifier que le stylo écrit bien
- Vérifier que les caractéristiques attendues sont présentes : bille, encre, capuche…
- Vérifier qu’il écrit avec la bonne couleur
- Vérifier qu’il ne laisse pas de trace quand on écrit
- Vérifier qu’on puisse l’effacer (ou pas) en fonction des spécifications du produit
- Vérifier que l’encre ne se renverse pas facilement en le mettant à l’envers
- Vérifier qu’il ne fond pas dès qu’il fait chaud
- Vérifier que s’il tombe dans l’eau, il puisse remarcher rapidement
- etc …
Passons aux choses sérieuses…
Après avoir compris le raisonnement de base d’un QA, voyons comment transposer nos illustrations sur un logiciel.
NB : Ce que je vous propose ci-dessous peut servir de référence afin de comprendre le fonctionnement d’un test mais ne remplace aucunement une bonne formation.
Les logiciels peuvent être très variés et exister sur des plateformes différentes : sur un navigateur, sur mobile, à installer sur un OS (Windows, Mac, Linux)…
Focalisons-nous, dans cette illustration, sur des logiciels orientés web.
Dans cette partie, je vais vous donner quelques cas pratiques sur une fonctionnalité que vous allez trouver sur n’importe quelle application de n’importe quel éditeur de logiciel : Le LOGIN.
Tester une page de login
À mon avis, c’est un exemple simple et qui peut être compréhensible à la grande majorité. Cette fonctionnalité peut, à elle seule, regrouper la plupart des cas de tests basiques qu’on peut faire dans une application quelconque.
Maintenant que vous visualisez la page, voici des exemples de tests génériques qu’on peut aussi extrapoler dans d’autres situations :
- Test positif : que doit faire cette page ? Permettre de se connecter avec un bon username et un bon password et avoir accès à l’application.
Bravo !!! Vous avez votre premier cas de test basé sur son comportement principal attendu. - Test négatif : Utiliser un bon username et un password aléatoire doit bloquer la connexion et afficher un message d’erreur
- Test de sécurité : Vérifier la déconnexion automatique au bout d’un certain temps
- Test de valeur limite : Mettre un mot de passe très court, ou un mot de passe très long
- Test d’intégration : Cliquer sur « forget your password? » ou « Sign up », puis vérifier qu’on est bien redirigé vers la bonne page associée.
- Test visuel : Vérifier que les composants (username ou password) sont bien placés (pas de superpositions de textes, pas de fautes)
- Test des composants : Tester les composants (input, checkbox, lien de redirection, bouton).
Bien sûr, on peut encore élargir les tests à faire sur cette page. En voici quelques exemples non exhaustifs :
- Vérifier que le message d’erreur n’est pas trop explicite (ex : « mauvais mot de passe » peut signifier à un hacker que le username existe bien dans la base de données et qu’il n’a plus qu’à chercher le mot de passe)
- Vérifier qu’au bout d’un certain nombre d’échecs de connexion, le compte est bloqué
- Vérifier la combinaison des champs : mettre un username mais pas de password et vérifier les messages d’erreurs quand on valide, essayer l’inverse, etc…
- Vérifier la validité des caractères spéciaux dans les champs
- Vérifier que le password est bien crypté
- Vérifier qu’il y ait un message d’erreur si les champs obligatoires ne sont pas remplis
- Vérifier les erreurs dans la console du navigateur
- Vérifier que le contenu est intuitif, informatif, compréhensible, structuré et lié logiquement selon vous (implicitement pour le client final aussi)
- Vérifier si la charte graphique est en conformité avec le guide d’accessibilité du contenu web (WCAG) : couleur, police…
- Vérifier que la page est compatible avec plusieurs navigateurs
- Vérifier que la page est Responsive : c’est-à-dire quel que soit la taille de l’écran utilisateur, la page de login s’adapte en conséquence
- etc …
Allez plus loin…
Rappelez-vous que vous êtes le représentant d’un utilisateur final. La valeur ajoutée ne se limite pas seulement à faire des cas simples qu’on lui demande de tester ou remonter des bugs. Le but est surtout de pousser le raisonnement et l’imagination plus loin afin de proposer des améliorations si besoin.
En voici des exemples d’améliorations à proposer dans le backlog produit :
- Proposer la double authentification
- Proposer la possibilité d’authentification avec empreinte digitale ou reconnaissance vocale ou faciale
- Proposer la mise en place d’un captcha
- Proposer des améliorations de police
- Proposer une version mobile de la page
Conclusion
Comme vous l’avez vu, sur une seule page et un seul exemple, on a pu parcourir la plupart des types de tests et proposer des dizaines de cas de tests à faire.
Maintenant c’est votre tour ! Amusez-vous à regarder autour de vous et à imaginer des scénarios de tests de plus en plus complexes mais surtout, n’oubliez pas qu’il faut toujours se mettre à la place du client final.
La rédaction de blog ou d’article n’est pas mon point fort, mais en tant que QA, je voulais TESTER. Je voulais surtout partager avec vous mon retour d’expérience. 😉
Si vous avez aimé cet article, n’hésitez pas à le partager !
Cet article a été publié à l’origine sur Medium.
Envie d’échanger sur la qualité logicielle et l’automatisation des tests ? Contactez-moi