Petite recette pour trouver de gros bugs

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

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.

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.

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 ?

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.

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.