Où l’on constate que le “tout tester” est encore présent dans les esprits, même dans un contexte agile !
Parfois, ce qui signifie souvent souvent !, le projet a l’impression que les testeurs (QA) se noient dans leur activités de test, ou pendant les rétrospectives l’équipe constate que tout n’a pas été testé, ou le management montre du doigt la QA comme un goulot d’étranglement.
Alors, la QA fait des heures supplémentaires au cours de la dernière semaine d’un sprint pour s’assurer que “the definition of done”, soit en français, la complétude des critères d’acceptation sera atteinte et ainsi rassurer le reste de l’équipe.
Faire des heures sup’ en vue de tout tester n’est pas la bonne solution.
Alors comment faire ?
Les tests basés sur le risque est une bonne approche
Cela commence par la prise de conscience que justement vous ne pouvez pas tout tester, jamais ! Nous en sommes tous convaincus.
Pour rappel, le 2ème principe sur les tests de l’ISTQB Fondation : “Les tests exhaustifs sont impossibles”.
Appliquer une approche basée sur les risques et soyez transparent vis-à-vis de l’équipe en indiquant ce que vous allez tester et ce que vous ne testerez pas; et justifiez-le.
3 approches basées sur les risques sont proposées ici, pour identifier et confirmer avec toute l’équipe ce qui sera réellement testé, de la classique stratégie de test basée sur les risques, au modèle de Pareto ou au test combinatoire.
1- Le juste test
L’élaboration d’une stratégie de test basée sur les risques pour définir le juste nécessaire à tester est une excellente pratique, qui peut être aussi simple à utiliser qu’une feuille de calcul Excel.
Vous qualifiez toutes les user stories du sprint concerné. Ensuite, vous discutez du facteur de risque pour chaque US entre amigos (cf. les 3 amigos). Enfin et sur la base de ces facteurs de risque, vous priorisez et testez les composants à hauts risques au regard des composants à risques plus faibles; ce qui est communément dénommé un parcours de test en profondeur.
2- Le test selon Pareto
Le principe de Pareto (également connu sous le nom de règle des 80/20, la loi des rares, ou principe de la dispersion des facteurs) stipule que pour de nombreux événements, environ 80% des effets proviennent de 20% les causes
Cela est vrai pour la plupart des applications logicielles, où 80% des utilisateurs n’utilisent que 20% de l’application, ou où 80% des défauts se produisent dans le même 20% du code.
En utilisant cette règle, vous hiérarchisez les composants à plus hauts risques de détection de défaillances et ne testez pas les composants peu ou non utilisées.
Cette méthode est préconisée par l’ISTQB et peut être complétée par une taxonomie des défauts (un autre principe de l’ISTQB) et une analyse des défauts des versions précédentes pour en déduire les 80 ou 20 % à cibler.
A contrario du parcours de test en profondeur décrit précédemment, c’est l’illustration d’un parcours en largeur.
3- Une approche de test combinatoire
Toutes les paires (all-pairs), ou deux à deux (pair Wise), est une méthode combinatoire du test logiciel.
Pour chaque paire de paramètres d’entrée d’un système la technique, il est souvent demander de tester toutes les combinaisons possibles de ces paramètres.
Est-ce pertinent ? Est-ce faisable ?
Le principe du test combinatoire est d’utiliser justement toutes les combinaisons préalablement identifiées pour aider à réduire les combinaisons de tests possibles à un ensemble logique et pertinent qui pourra être complété dans les délais impartis (des techniques et outils existent, nous pourrons en discuter ultérieurement).
Appliquer tout de suite une approche basée sur les risques ET automatisez plus tard
Il est souvent reproché au QA de créer des goulots d’étranglements ou d’avoir un comportement de type “scrummerfall” (des mini cycles séquentiels intégrés dans une approche agile) dans ses activités : j’attends une base de test solide avant de concevoir les tests puis de les exécuter, de suivre les anomalies, d’automatiser en vue de la non régression et cætera et cætera
Cela risque de générer un doute au sein de l’équipe sur la capacité du testeur en matière de qualité logicielle ?
En tant que consultant qualification logicielle vous devriez revoir régulièrement et en continu votre processus de test (analyse, conception, exécution, gestion des anomalies, reporting) associé à votre charge et planning, afin d’éviter les trop fameux goulots d’étranglement dans votre processus; si vous participer à l’estimation des charges (planning poker ou autre) tant mieux, sinon ? Faites-vous invitez. Sinon, appelez-moi …
En conclusion
Au bout du compte, c’est toute l’équipe et pas seulement vous en tant que QA qui est impliquée sur la qualité à délivrer.
Alors, faites le nécessaire pour implémenter ces techniques basées sur les risques, ou faites en la promotion au sein de l’équipe si elles ne sont pas pratiquées, et ne vous focalisez pas trop précipitamment sur l’automatisation des tests comme il vous ai souvent demandé.