Petite recette pour trouver de gros bugs

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

Les logiciels actuels prévoient souvent plusieurs états, ou encore plusieurs niveaux de complétion. Par exemple, un utilisateur peut n’avoir payé que pour accéder à une partie du logiciel, ou encore il peut n’avoir rempli que certains champs et non la totalité, etc… 
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

Nos logiciels sont constitués de plusieurs couches (souvent, le front, l’API, et le back). Chaque strate est testée de manière isolée grâce aux tests unitaires faits par les développeurs, mais de nombreux bugs se cachent souvent au niveau du raccordement entre ces couches. Ces bugs sont souvent dûs à une mauvaise communication entre les personnes de l’équipe : par exemple, le dev API change un endpoint mais oublie de transmettre cette information aux consommateurs de cet endpoint.

Tester les interfaces externes

Aujourd’hui, nos outils sont souvent interconnectés, et on peut appeler un autre logiciel depuis notre système (pensez aux réseaux sociaux). Le “happy path” consiste à avoir toutes ces connexions correctement branchées. La QA va donc tester tous les autres moyens d’interagir avec le logiciel. Par exemple, dans le cas d’une application mobile, comment réagit-elle si on clique sur “partager sur Twitter” mais que Twitter n’est pas installé ? De même, l’application sait-elle bien gérer le cas du mode avion, ou de ne pas avoir accès à internet ? Que se passe-t-il si on reçoit un appel téléphonique pendant qu’on utilise l’application ?

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.

https://www.monkeyuser.com/2018/happy-flow/
https://www.monkeyuser.com/2018/happy-flow/

Ce qu’il faut retenir

Le QA veut casser le système. Pour cela, il veut :
  • 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

4 comments

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

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

  2. 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 😁

    1. 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é

Leave a Reply

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