C’est de la stratégie de test dont il est question. Elle doit être élaborée et rédigée par un professionnel du test (test manager, responsable QA …) qui trop souvent est confronté à ce manque, cette incompréhension ou à une incapacité des organisations à y attribuer du budget ou à savoir comment s’y prendre pour le mettre en œuvre. Je propose ainsi de rappeler l’extrême importance, le bien fondé de produire ce livrable dans le cadre de nos projets IT : Réhabilitons la stratégie de Test de nos projets IT.
Cette rubrique est dédiée à un LIVRABLE du test – voir aussi l’article sur le sujet des livrables projet – qui fait trop souvent défaut aux projets IT, voire même en voie de disparition.
Stratégie de test ! Où es tu ?
Pourquoi ce manque de préparation, d’anticipation ou encore de coordination, voire d’imagination, pour cadrer les activités de test en les inscrivant suffisamment tôt dans le cycle de vie du projet IT. Parce que ce livrable n’existe pas ? Parce que le test n’en a pas besoin ? Tester ne serait encore considéré par certains qu’en mode “monkey test” ? Parce que les acteurs des projets IT ne savent pas s’y prendre ? Parce qu’il n’existe pas de méthodes, de référentiels pour guider à sa rédaction ?
Alors, tester sans stratégie de test serait comme : une ratatouille sans légumes ! Des médias traditionnels sans émissions politiciennes ! Paris sans vélib’ ! Un pastis sans soleil ! Une mer sans huitres !
Sans stratégie de test dans un projet IT, quelles preuves de la qualité du produit pourront être apportées ? Quelle assurance pourra être donnée aux commanditaires du projet que leurs exigences seront satisfaites ? Quels moyens seraient donnés au test, tout simplement ?
Le test logiciel serait donc orphelin d’un livrable qui décrirait ses objectifs et sa gouvernance et présenterait les moyens de son prochain déroulement ? Tiens ! “Objectifs” et “Moyens“, on en reparle…
Est-ce qu’un projet IT est démarré par une direction générale sans étude préalable ?
Est-ce qu’un projet de construction est démarré sans devis, sans plan d’urbanisme, sans permis de construire ?
Est-ce qu’une croisière ou une course transatlantique se fait sans plan de navigation ?
Bien sûr, ce n’est pas parce qu’on a préparé au mieux son projet, quel qu’il fusse, qu’on le mènera à bien ou qu’il se fera dans les temps ou que le budget ne sera pas dépassé. Certes !
Mais spécifier ce qu’on veut réaliser et quels moyens on peut ou on veut se donner, c’est quand même le minimum.
Alors pourquoi le projet de test est-il délaissé de cette étape essentielle ?
Je ne présenterai pas ici les possibles explications de ce constat – sans doute avez-vous aussi votre point de vue ? et ce malgré de nombreux retours d’expériences de missions et de projets et d’échanges avec les confrères.
Je préfère axer cette chronique sur les pistes de la mise en œuvre d’une stratégie de test, à quel moment l’initier ? Comment la reconnecter au projet informatique ? Quel(s) rôle(s) pour la spécifier et pour la déployer ?
Mes propos sont légitimés par des référentiels traitant du test : l’ISTQB – eh oui ! ce n’est pas seulement un tampon qui valide un examen, il y a aussi du contenu, surtout dans les syllabi avancés, TMAP © – même si TMAP base sa vision du test principalement sur la gestion des risques et TMMI – qui fait la promotion des livrables de test dans sa matrice de maturité.
Je vous propose les postulats phare – celui du Grand Jardin par exemple (un moment d’évasion pour les voileux habitués de la bais de St Malo) – suivants qui assisteront le récit :
- La stratégie de test en 2 mots clés,
- La stratégie de test est dédiée au contexte de projet IT,
- Le positionnement de la stratégie de test dans l’organisation du projet IT.
2 mots clés : “OBJECTIFS” et “MOYENS”
Ces 2 inputs sont littéralement la base à toute spécification d’un concept ou d’un projet pour ensuite servir à la rédaction du document qui communiquera sur ces points de vue.
Nous parlons de test ? Alors traitons dans la stratégie de test des objectifs de test du projet informatique et des moyens à donner au test, à tout le test.
Trop simple ? Oui, non, pas toujours. Il suffit de disposer des bons entrants, avoir accès à la bonne information, communiquer avec toutes les parties prenantes.
Stratégie de test et contextes projet
Une organisation, une entreprise mène des projets informatiques dans des domaines très variés – réalisation d’une nouvelle application, intégration d’une solution logicielle du marché, maintenances/évolutions de l’existant, migrations techniques…
S’ajoutent à cela des méthodes spécifiques et particulières de gestion de projet, séquentielle ou agile, guidée par une gestion des risques ou non, par des normes, ou essentiellement par les délais et les budgets
Les organisations projet sont aussi très variables, avec des équipes internes ou externalisées ou en centre de services, l’équipement en outillage technique pour la modélisation, l’intégration, le test… est aussi un critère important.
Tout cela additionné oblige, on le voit bien, à définir la stratégie de test selon le contexte du projet.
Le test pour une nouvelle application à intégrer dans un SI ne sera pas le même que pour un projet de virtualisation de serveurs ou de montée de version d’un ERP.
Une organisation du test pour des évolutions planifiées d’un SI gérées en mode séquentiel sera bien différente que le déploiement de nouvelles fonctionnalités de services web en mode agile.
Le contexte du projet justifie une stratégie de test dédiée, pour répondre à des objectifs de test particuliers qui seront couverts par des moyens adaptés à ces caractéristiques.
Le postulat “phare” précédent précise donc de spécifier plusieurs stratégies de test, dès lors qu’une organisation est confrontée à des contextes projet IT variés.
2 cas se présentent pour situer la stratégie de test dans l’organisation et dans le projet IT :
Cas 1 :
L’organisation a développé, dans le cadre de sa politique pour la qualité logicielle, un ensemble de livrables type “stratégies générales de test”.
Chacun de ces livrables, pour un contexte projet IT spécifique, donne une vision macro des objectifs à atteindre et des instructions générales quant aux moyens de test à mettre en œuvre – méthodes et techniques, ressources, outillage, environnements…
Ainsi, le test manager du projet IT s’inspirera d’une, ou peut-être de plusieurs, stratégie(s) générale(s) de test de l’organisation qu’il déclinera dans le cadre de son projet de test.
La stratégie de test sert alors de base à la préparation du plan de test, LE livrable du projet de test pour le projet IT – quoi ! un autre livrable ? c’est osé non ?
Cas 2 :
L’organisation n’a pas particulièrement de politique pour la qualité logicielle et ne dispose pas de stratégie(s) générale(s) de test.
Cela n’empêche pas de diriger le test !
Par contre et si on n’a pas capitalisé des expériences passées, on risque de réinventer la roue – et puis la roue, ça date de 3 500 avant JC, quand même, il serait temps d’apprendre !
Bref, pas de stratégie de test ? Pas de phare à l’horizon pour guider le test du projet IT ?
Charge alors au test manager de s’inspirer de ses propres expériences et surtout de trouver les bonnes infos – ça c’est la phase “je fais mon marché auprès des parties prenantes du projet” – pour identifier les objectifs de test et proposer des moyens de test en accord avec l’organisation et le projet IT.
Dans ce cas la stratégie de test ne sera pas un livrable à part entière mais sera spécifiée dans le plan de test, qui détaillera les aspects du test au fur et à mesure de l’arrivée des informations et de leur granularité.
En synthèse, la stratégie de test peut exister et accompagner le projet IT en tant qu’input (cas 1) ou de livrable via le plan de test (cas 2).
À vous de décider.