Il y a une remarque qui revient fréquemment dans les missions sur lesquelles je travaille et sur laquelle j’aimerai m’attarder.
Cette remarque, généralement faite par le management, est la suivante :
« Je ne comprends pas. Les tests coûtent cher, les développeurs font des tests, les testeurs font des tests, le support fait des tests… Mais il y a toujours des bugs et la qualité n’est pas au niveau souhaité »
Analyse de(s) problématique(s):
Cette remarque analysée « à la va vite ». On pourrait en effet penser que le seul problème serait que les tests ne soient pas assez efficaces, maintenus ou encore pas assez automatisés…
Mais ces solutions résolvent-elles la racine du problème ? Existe-t-il une raison, plus profonde, qui serait la source de ces problèmes ?
Lors de mes entretiens je pose également d’autres questions comme :
· Les tests sont-ils partagés entre les testeurs et les autres équipes ?
· Y-a-t-il une batterie de tests vitaux communes sur lesquels les développeurs peuvent s’appuyer ?
· Qui fait quels tests ?
Les réponses à ces questions sont souvent :
· Non, les tests ne sont pas partagés, chaque équipe a les siens et cela fonctionne comme une boite noire.
· Non (lorsque c’est Oui, ces tests ne sont pas mis en communs), généralement les testeurs font quelques tests exploratoires avant de lancer toute la campagne.
· Je ne sais pas, chaque équipe fait ses propres tests.
Suite à ce type de réponses ma première remarque est que le problème semble bien plus profond que juste un manque d’automatisation ou de qualité des tests.
Ici le problème relève en fait plus de la communication inter- équipes et de la coordination de l’effort de test.
Il est bon de noter qu’encore une fois une communication défaillante est une raison majeure des problèmes de qualité sur une application.
Si personne ne sait qui fait quel test, que personne ne sait quels sont les tests effectué, on est alors confronté à plusieurs problèmes :
· La couverture peut être trop faible avec des « trous dans la raquette ». Personne n’est en mesure de dire si l’ensemble des tests nécessaires sont exécutés car personne ne sait quel est cet ensemble de test exécuté ni quand ils sont exécutés.
· Trop de travail sur certains points avec des équipes faisant plusieurs fois les mêmes tests. Chaque équipe peut considérer que des tests sont vitaux et les faire. Si toutes les équipes sélectionnent les mêmes tests alors ils sont exécutés plusieurs fois alors qu’une unique fois devrait suffire.
· Trop de maintenances inutiles. En effet si un test est présent au niveau des développeurs, des testeurs et du support, que chacune des équipes met à jour ses propres tests, alors le temps de maintenance de ce test est 3 fois supérieur à la normal car il est mis à jour 3 fois.
La mauvaise couverture explique pourquoi « la qualité pas au niveau souhaité ». En effet, une couverture insuffisante ne permet pas d’avoir la visibilité souhaitée sur la qualité de l’application.
Les mêmes tests exécutés et maintenus plusieurs fois expliquent quant à eux pourquoi « Les tests coûtent cher » car un même travail est effectué plusieurs fois.
Solution pour résoudre ces problématiques :
La meilleure chose à faire est donc de travailler sur:
· L’amélioration de la couverture de l’ensemble des tests
· La diminution du travail effectué en double voire triple (limiter le gâchis, c’est un peu du lean)
Afin de répondre le plus efficacement à l’ensemble de ces problématiques il faut coordonner les efforts de tests des différentes équipes. Cette solution peut être mise en place en avec un ensemble d’actions qui peuvent être :
· Avoir un outil commun dans lequel tous les tests (de toutes les équipes) sont centralisés afin de pouvoir travailler sur la couverture, l’améliorer et l’optimiser (au moyen d’une matrice de couverture)
· Avoir une campagne de tests vitaux commune, cette campagne devant être exécutée en ayant 100% des tests en succès avant de poursuivre le processus de développement (par exemple avant d’arriver chez les testeurs pour validation)
· Définir une stratégie de test précise notamment en écrivant des plans de test et en les validant par l’ensemble des membres du projet
· Définir une matrice RACI (qui fait quoi) peut également être une bonne solution mais elle est généralement faite avec le plan de test maitre.
· Mettre en place des processus de communication par rapport aux tests à effectuer (validation, partage en amont…) entre les différentes entités (Développeurs, testeurs, AMOA et support).
· Avoir des rapports de tests communiqués à l’ensemble des membres du projet. Je fais ma campagne, je communique les résultats de ma campagne à travers un bilan.
Bien évidemment les solutions que je propose sont des pistes, il est possible d’en trouver d’autres mieux adaptées au contexte. Le principal étant, comme d’habitude, d’avoir une bonne communication entre les différents acteurs du projet. Je parle dans cet article de coordination des efforts de test, cela est évidemment applicable sur l’ensemble des activités du projet.
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
