Trouver des bugs, c’est un métier, et ça s’apprend ! Bien sûr, l’expérience compte pour beaucoup, mais il existe quelques bonnes pratiques que je vous propose de détailler ici. Cela pourra vous aider si vous devez former quelqu’un à la QA, ou si vous êtes dans une trop petite structure pour accueillir un QA à temps plein.
Tester les limites du système
Globalement, je conseille de partir du principe que le PO a bien fait son travail : il a pensé à la majorité des cas évidents d’utilisation. Le boulot du QA va donc consister à chercher tous les cas à la marge, à chercher comment casser le système.
1) les champs texte
Pour tous les champs où l’utilisateur peut rentrer du texte, le cas trivial consiste à ajouter le texte attendu dans le champ (par exemple un nom de famille). Mais que se passe t il dans les cas suivants ?
- caractères non conventionnels (é, è, @, etc…)
- si le champ reste vide
- si le texte rentré est très long
- est ce que le champ doit accepter uniquement des nombres ? ou à l’inverse les refuser ?
- dans le cas des nombres, que se passe t il avec des nombres négatifs ? et le zéro ?
- etc…
2) la gestion d’un tableau
De la même manière, dès que l’utilisateur peut modifier un tableau ou une liste d’éléments (ajout/modification/retrait d’un item). Que se passe t il s’il retire le dernier élément du tableau ? combien le tableau peut il avoir d’éléments au maximum ?
3) les dates
S’il y a un système de gestion de dates, y a-t-il des situations où des changements de mois/année pourraient poser problème ? Quid des fuseaux horaires ?
Tester les états du système
Ces différents états sont autant de situations à tester, ou au moins à envisager. Ce sera ensuite votre connaissance du système qui vous permettra de savoir si chaque état doit être testé, ou si certains tests englobent plusieurs états d’un coup.
Tester les interfaces internes
Tester les interfaces externes
Tester les plateformes
Que vous travailliez sur smartphone, sur le web, ou sur tout autre système, il peut être intéressant de tester les différentes plateformes. Je vous conseille de regarder vos analytics pour savoir quelles sont les plateformes les plus utilisées par vos clients (rapprochez vous de vos PO si vous ne savez pas comment faire ça). Par exemple, si la répartition d’usage de votre application est (90% chrome / 10% Firefox), faites tous vos tests sur Chrome, mais prévoyez une journée par semaine sur Firefox.
Faire une checklist des spécificités du système
Tous les exemples donnés ci-dessus sont assez généralistes, mais votre système est unique : faites donc votre propre checklist, en vous basant sur les écueils que l’équipe a rencontrés par le passé. Pour cela, rassemblez quelques développeurs et POs présents depuis longtemps dans l’entreprise, et essayez de lister les erreurs/oublis récurrents dans les spécifications et implémentations. Une fois cette checklist faite, ne la gardez pas pour vous, partagez la avec vos POs. Ainsi, ils pourront passer en revue ces points là avant de soumettre les nouvelles features.
Ce qu’il faut retenir
- tester les cas aux limites (0, infini, négatifs, caractères exotiques…)
- tester les états du systèmes
- tester les interfaces internes et externes
- tester les différentes plateformes
- faire une checklist de points à vérifier par les PO avant soumission
Ravi de voir un nouveau blog sur le test avec des articles de qualité.
Il me vient rapidement quelques idées pour compléter le sujet.
Pour tester les limites du système, je conseille de conserver à portée de main la “test heuristic cheat sheet” d’Elisabeth Hendrickson, c’est une mine d’informations: http://testobsessed.com/2007/02/test-heuristics-cheat-sheet/
Pour “Tester les plateformes”, nous en avons parlé il y a peu sur Twitter. Voir https://twitter.com/horustest/status/1258066857547968523
Merci pour ton retour Stéphane : je ne connaissais pas le cheatsheet d’Elisabeth, mais il est super intéressant et bien fait. A garder toujours dans un coin de sa tête
Merci pour cet article.
Je rajouterai que le test exploratoire est aussi une bonne manière de gérer le risque pour un coût faible.
Une formulation utilisée deux fois me chagrine : “Le QA veut casser le système”
C’est une vision péjorative de notre métier et apporte de la défiance dans des équipes de développement. Je préfère dire “le QA veut améliorer le produit en mettant en avant ses défaillances”. Notre rôle est constructif 😁
Merci pour ton retour Benjamin !
Concernant les tests exploratoires, je suis d’accord que c’est une bonne pratique, mais il s’agit plus pour moi d’une stratégie de tests (qu’on pourrait comparer à la stratégie de “plan de tests” par exemple) : et c’est au sein de ces stratégies que nous déroulons les pistes que j’ai évoqué dans mon article.
J’ai volontairement choisi cette expression “péjorative” pour exprimer l’idée que lorsque nous cherchons des bugs, nous voulons mettre à mal le système, un peu comme un prédateur. La manière dont on remonte ensuite ces bugs au reste du monde, et donc comment on est alors perçu, est un problème assez différent. Mais c’est une bonne idée et je pourrai en parler dans un prochain article, et je serai ravi d’avoir ton retour dessus 🙂 En attendant, j’aime bcp la définition du métier que tu as indiqué