Un avis ? Un commentaire ?
Cet espace est pour vous.
« TMMi ». Que vous a évoqué cet acronyme la première fois que vous l’avez lu ? Probablement un standard très strict, applicable uniquement aux très grosses organisations, et peut-être trop rigide pour suivre le rythme effréné des changements que vit constamment le monde de l’informatique, surtout à l’ère de l’agilité… et surtout à l’ère de l’IA.
Est-ce mérité ? On ne va pas faire durer le suspense : non. Dans cet article, nous allons voir pourquoi TMMi reste un référentiel tout à fait pertinent, à condition de comprendre comment il fonctionne réellement. Car bien souvent, ce qu’on reproche à TMMi, c’est en réalité une idée qu’on s’en fait sans l’avoir vraiment étudié !
TMMi (Test Maturity Model integration) est un modèle de maturité dédié au processus de test. Il permet de situer son organisation sur une échelle de 1 (très faible maturité, niveau « initial ») à 5 (très forte maturité, niveau « En optimisation »). Cela peut évoquer de lourdes démarches d’audit, d’épais classeurs qui prennent la poussière, des certifications accrochées au mur et dont la moitié de l’entreprise ignore même la signification, et qui ne servent à rien d’autre que se faire un peu mousser…
Mais si on regarde de plus près la mécanique du modèle, on comprend que l’idée n’est pas de coller une étiquette et de poser des jalons artificiels. Il s’agit plutôt de dessiner une perspective et d’insuffler des dynamiques vivantes, au plus près des objectifs réels de l’organisation.
TMMi structure la maturité du test en 5 niveaux. Le niveau 1, c’est la case départ : même une entreprise qui ne ferait aucun test pourrait « prétendre » à ce niveau. Ainsi, chaque niveau sauf le premier contient ce qu’on appelle des « domaines de processus », qui représentent des grands axes de travail. Au total, on compte 16 domaines de processus.
À leur tour, chacun des domaines de processus contient des objectifs… qui eux-mêmes contiennent des pratiques… qui elles-mêmes peuvent être détaillées en sous-pratiques et exemples de produits d’activité (autrement dit, des documents ou artefacts qui retracent cette activité). Un peu partout, on peut aussi trouver des notes, des exemples, des références.
Trop de jargon ?
C’est ici en effet que beaucoup de gens décrochent. Tout ça commence à ressembler à une énorme montagne de cases à cocher, et on peut avoir peur de se perdre dans les branches de cette arborescence.
Mais qu’il faut s’accrocher parce qu’il y a une subtilité qui fait tout basculer !
Embarquons-nous dans la métaphore la plus hasardeuse de l’histoire de ce blog, avec nos excuses par avance aux personnes qui en savent plus que nous sur les pizzas.
Le modèle TMMi, nous venons de le voir, dispose d’une structure où les éléments s’emboîtent les uns dans les autres. Les niveaux de maturités contiennent des domaines de processus, qui contiennent des objectifs, qui contiennent des pratiques, qui contiennent des sous-pratiques et des exemples de produits d’activité.
C’est la même chose pour les pizzas : la pâte soutient la base (base crème ou base tomate), et la base soutient les différents ingrédients.
Et les éléments de TMMi, comme les ingrédients de la pizza, ont différents statuts.
Les domaines de processus sont requis pour atteindre un niveau de maturité. Et pour qu’un domaine de processus soit validé, il faut que ses objectifs soient remplis ; ces objectifs sont également requis.
On imagine difficilement une pizza sans pâte.
Exemple TMMi : le niveau 2 de TMMi contient 5 domaines de processus, dont « Politique et stratégie de test ». Ce domaine de processus présente 3 objectifs : « Établir une politique de test », « Établir une stratégie de test » et « Établir des indicateurs de performance du test ». Tout ça, c’est requis.
Sous les objectifs requis, on trouve les pratiques, et c’est ici qu’arrive la nuance la plus importante. Les pratiques ne sont pas des composants requis, mais attendus.
Citons le modèle :
Les composants attendus décrivent ce qu’une organisation doit généralement mettre en œuvre pour satisfaire à un composant requis. Les composants attendus guident ceux qui mettent en œuvre des améliorations ou effectuent des évaluations. […] Les pratiques décrites ou des alternatives acceptables à ces pratiques doivent être présentes dans les processus planifiés et mis en œuvre de l’organisation, avant que les objectifs puissent être considérés comme atteints.
~Le modèle TMMi, p. 14. Le gras et le soulignement sont de notre initiative.
Relisez bien : ou des alternatives acceptables. Autrement dit, TMMi ne dit jamais « Faites exactement ceci, de cette façon ». Il dit « Voici une pratique attendue, et si vous faites autrement tout en respectant l’esprit de la démarche, c’est recevable ». TMMi est souple par nature. Juste assez souple pour que les intentions du modèle restent au cœur de la démarche, et non les détails du « comment », qui restent à la discrétion des organisations.
Ainsi, toute pizza qui se respecte a une base, mais ça peut être une base tomate ou une base crème. Ce qui est attendu, c’est que la pâte soit recouverte d’une couche uniforme et goûteuse ; c’est à vous de voir laquelle est la meilleure pour votre contexte.
Exemple TMMi : une des pratiques de l’objectif « Établir une politique de test » est « Définir la politique de test ». Le texte qui l’accompagne est le suivant :
Une politique de test, alignée avec la politique de l’entreprise (qualité), est définie en fonction des objectifs de test et approuvée par les parties prenantes.
~Le modèle TMMi, p. 27
Il est tout à fait possible ici d’accepter des alternatives. Si votre entreprise n’a pas de politique de test à part entière, mais dispose d’un document dont certains passages sont conformes à ce qu’on attend d’une politique de test, alors la pratique peut être validée.
Tous les autres composants que nous avons cités sont informatifs. Ceux-là ne sont jamais obligatoires lors d’une évaluation. Ils existent dans le modèle TMMi pour illustrer, donner des pistes concrètes, montrer ce que d’autres organisations ont mis en place. Il faut comprendre ça comme « il arrive que les équipes procèdent ainsi », et non comme une consigne. Les modalités d’application étant infinies, TMMi se garde bien de les imposer.
Et tout ça rappelle le nombre extrêmement varié de choix d’ingrédients et d’assaisonnements qu’on peut répandre sur notre pizza.
Exemple TMMi : parmi les sous-pratiques de la pratique « Définir la politique de test », on trouve « Clairement séparer le test du débogage dans la politique de test ». C’est une simple option, à prendre seulement si ça vous paraît pertinent.
TMMi se compose donc de trois étages : ce qui est requis (les domaines de processus et les objectifs, intouchables), ce qui est attendu (les pratiques, avec leurs alternatives possibles) et ce qui est informatif (les éléments purement indicatifs).
Ce qu’on reproche à TMMi — la lourdeur, la rigidité, l’inadaptation au terrain repose donc sur une lecture bien superficielle.
La Fondation TMMi apporte d’ailleurs un parfait exemple de cette souplesse, avec son document TMMi dans le monde agile. Il ne faut surtout pas lire ce document comme un erratum, une mise à jour ou encore une reculade par rapport à tout ce qui est dit dans le modèle TMMi. C’est bien au contraire une éclatante illustration de la souplesse du modèle.
Si cet article vous a donné envie d’aller plus loin que les idées reçues sur TMMi, nous avons développé une plateforme de e-learning entièrement dédiée à TMMi, pour s’approprier le modèle pas à pas, sans s’y perdre. Laissez-nous un commentaire si vous souhaitez en savoir plus !
Cet espace est pour vous.