10 minutes dans la peau d’un QA

Rédigé par William

William est un passionné de tests et qualités logiciels. Sa spécialité, c'est de mettre en place des stratégies d’automatisation des tests. Cela implique à la fois l’audit de l’existant, la proposition de stratégie, la mise en place, l’intégration continue et aussi la construction ou le renforcement de l'équipe QA. Ses outils de prédilections sont Cypress.io et Postman. Il connait également d'autres outils et d'autres technos notamment Selenium, Appium, Java, Python, SoapUI, etc...

3 janvier 2022

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

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 cry

C’est peut être de là que vient l’expression: “Le client est Roi” ? 😉

Quel que soit l’objet ou le logiciel à tester, un des rôle d’un QA est de se mettre à la place du client final.

Son objectif est d’anticiper le maximum de scenarios (du plus simple au plus tordu) possibles. Ceci 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 amener à 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 lavage, l’imprimé disparait 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 reconnaitra en passant par ici.

Même chose, pensez aux utilisateurs finaux d’un stylo et pensez à des scenarios de tests que vous pourriez faire afin d’en garantir la qualité.

Comme précédemment, voici les scenarios, 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 les caractéristiques attendus sont présents: bille, encre, capuche…
  • Vérifier qu’il écrit avec la bonne couleur
  • Vérifier que 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 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

Une page de login est souvent constitué de ces éléments sur l’image.

A 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.

Exemples de tests génériques

  • 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 bloqué 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 biens 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.

    Exemples supplémentaires 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ée et qu’il n’a plus qu’à chercher le mot de passe)
    • Vérifier qu’au bout d’un certain nombre d’échec 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 en anglais): couleur, police…
    • Vérifier que la page est compatible avec plusieurs navigateurs
    • Vérifier que la page est Responsive: ie 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élioration à 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 scenarios 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. 😉

    Que pensez-vous de cet article ?

    Si vous avez aimé cet article, merci de le commenter et de le partager !

    À bientôt 😊

    Vous pourriez également aimer...

    1 Commentaire

    1. נערות ליווי

      The next time I read a blog, Hopefully it doesnt fail me just as much as this one. I mean, Yes, it was my choice to read through, but I actually thought you would have something useful to say. All I hear is a bunch of moaning about something that you could fix if you werent too busy searching for attention.

      Réponse

    Soumettre un commentaire

    Votre adresse e-mail ne sera pas publiée.