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

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.

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

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.

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 …