Tribunes

Déployer les tests à l'échelle d'une organisation

Les bonnes questions à se poser pour déployer une stratégie de test à l'échelle d'une organisation.

PublicitéAprès en avoir pris la décision, mettre en oeuvre les tests dans une organisation nécessite une connaissance approfondie du sujet. Faut- il se lancer en créant une entité de tests pour des projets pilotes et y faire adhérer progressivement l'organisation ? Ou bien faut-il, dès le départ, avoir une vue d'ensemble et mettre en place un cadre pour tous les projets de l'entreprise ?

Nous nous attacherons, à travers cet article, à passer en revue les questions incontournables à se poser, pour déployer une stratégie de test à l'échelle d'une organisation.

Qui sont les acteurs concernés par les tests ?

- La direction de l'organisation qui a défini la politique de tests, c'est-à-dire pourquoi il y a des tests, comment elle va vérifier que cette politique est respectée et quels moyens elle met en oeuvre et celle qui a défini La stratégie de tests, c'est-à-dire comment elle compte le faire.
- Les membres des services qualité iSO9000 ou autres qui veillent au respect des activités projet et des livrables associés.
- Le métier ou ses représentants qui ont émis un besoin. Ils ont la charge de valider les fonctions développées ou intégrées.
- L'exploitation qui assurera la disponibilité des systèmes et qui doit valider que les livraisons respectent leurs normes ou catalogues d'exigences d'exploitation et que le système se déploie sans anomalie.
- La direction de projet qui suit la mise en oeuvre des programmes/projets pour leur client, le ou les sponsors qui proposent des solutions logicielles, anticipent les besoins. Ils auront donc des actions sur la validation d'exigences projet, le respect des calendriers, la qualité des livraisons et le coût de la mise en oeuvre. Comme ces personnes ont une vision globale du projet, Les documents de stratégie, plans de tests maitre et de niveau devront donc être partagés avec eux. Avoir leur écoute et accord permettra de mettre en place un suivi transverse des tests allant du cadrage jusqu'à l'acceptation métier. Sinon, il risque d'y avoir une frontière entre les tests de la maitrise d'oeuvre et ceux de la maitrise d'ouvrage/métier. En effet les MOE éprouvent souvent des difficultés à rendre leurs activités de testing transparentes et à avoir la confiance des MOA.
- Le chef de projet qui a en charge de livrer un produit de qualité dans des délais pour un coût donné. Malheureusement le chef de projet est souvent pris dans des considérations plus générales que les tests. Même les plus formés au pilotage de projet par la qualité rencontrent souvent les affres des réunions de cadrages, les problèmes de ressources, d'ego de clients/Métier/MOA, les plans d'assurance qualité avec les fournisseurs, le cycle de vie du projet, l'agilité, l'argumentation sur les charges de développement (il faut bien produire avant de tester..).
Si le chef de projet conserve la responsabilité des tests, un chef de projet de tests dédié, peut lui permettre de se focaliser sur les actions premières pour lancer son projet.
- Le chef de projet de tests peut se concentrer sur les activités de testing au nom de l'organisation et pour le chef de projet. Il porte les activités de tests, voire l'assurance qualité pour le projet ou un niveau de tests. En effet son activité peut concerner un projet de A à Z, du cadrage aux acceptations opérationnelles et métier, ou bien un niveau comme l'intégration dans le SI ou un domaine d'applications. C'est lui qui mettra en garde le chef de projet sur des plannings de développements trop optimistes ou des lots d'évolutions ou de nouvelles fonctionnalités à développer trop importantes, non loties.
- Les testeurs qui collaboreront à l'élaboration des plans de tests, analyseront et prépareront les tests. Ceux qui les exécuteront s'ils sont différents.
- Les intégrateurs dans le SI qui, suivant les organisations, peuvent avoir des équipes dédiées.
- Le fabriquant du système logiciel qui réalise et livre le client : les testeurs qui vérifieront que tout fonctionne avant de livrer le client ; le développeur qui créera le logiciel et exécutera les tests unitaires (nouveauté et non régression)
- Les personnes support comme les spécialistes méthodes, normes et outils de tests, les gestionnaires d'environnements de tests, spécialistes des jeux de données de tests, les responsables de la gestion de configuration, les services / sociétés extérieures qui exécutent des Tierces Recette Applicatives à différents niveaux.

PublicitéQue vais-je tester ?

- Ce qui doit être testé en termes de modules/programmes/systèmes et en termes de types de tests.
- Qu'est-ce que j'attends de mon système logiciel, côté Métier, côté exploitation, côté développement ?
Cela est défini dans la norme ISO9126 qui a évolué depuis en ISO Square 25000. Pour un niveau donné, il convient de définir les caractéristiques Qualité qui peuvent être vérifiées ou validées pour des parties complètes ou des parties de logiciels. Planifier consistera à définir quels types de tests il faudra réaliser pour répondre à des objectifs de niveau de tests.

Ou vais-je le tester ?

Centres de compétences de tests, TRA, centres de services, plateau projet. Où les tests vont-ils être préparés, implémentés et exécutés dépend des organisations. Certaines, comme de grandes banques alliées à des SSII internationales, ont choisi de délocaliser les tests dans le monde, en Off-shore (Mumbai en Inde par exemple), Near shore (Afrique du nord), On shore ( villes de province pour les projets Parisiens ...).

Quand ?

Souvent mis avant le reste, le Quand est un élément de communication essentiel. Faire un calendrier en accord avec un plan de version SI est difficile. Le suivre encore plus.

Comment le chef de projet de tests peut-il dire quand les tests seront préparés, exécutés, s'il existe des incertitudes quant aux plannings de développement ?

Souvent le chef de projet commence par planifier en faisant un retro planning, en fonction d'un plan de version SI par exemple, de la date de livraison d'un projet avec lequel il est en adhérence, ou de la date de mise en production demandée par un service Marketing ou un client. Puis il cherche à intégrer dans les délais définis les activités liées aux tests. Une fois cela fait, en fonction de l'estimation de la charge de tests effectuée, il définit le nombre de ressources nécessaires.

Comment ?

Quelle stratégie de tests dois-je mettre en oeuvre ? Il y a-t-il une stratégie à appliquer pour mon domaine fonctionnel par exemple ? Devrais-je suivre une norme industrielle ?
- Les techniques de tests concernent les analystes de tests. Les plans de tests de niveau les préciseront
- Les approches de tests concernent les chefs de projet de tests. Les plans de test « maître » et plans de test de « niveau » les détailleront.
- Les stratégies de tests concernent les domaines fonctionnels/Pôles applicatifs/organisations.

Pour certains projets, il faudra respecter une norme sur les systèmes à sécurité critique comme la DO178 pour l'avionique ou l'ISO 26262 dans l'automobile.
Ces normes ont un impact fort sur les tests, car elles précisent la couverture de test attendue.
Pour d'autres, les chefs de projet de tests définiront, en accord avec les parties prenantes, le délicat dosage qu'ils devront faire entre les :
- stratégies offensives (mettre en oeuvre les revues par exemple) ou défensives,
- approches analytiques basées sur les risques « produit »,
- approches méthodiques basées sur des listes contenant des points à vérifier,
- approches heuristiques comme la mise en oeuvre de tests exploratoires,
- approches stochastiques basées sur le principe du regroupement des défauts, la gestion des incidents et des problèmes connus.

Combien cela me coûtera-t-il ?

L'estimation budgétaire des tests est un point important qui peut être traité en deux temps :
- Lors du cadrage, puisqu'il est nécessaire de fournir des prévisions pour obtenir les budgets. Cette évaluation se fait souvent à partir d'abaques de projets antérieurs. Ces abaques peuvent être formalisés dans des matrices de chiffrage, ou bien fournies par des experts selon leur expérience.
- Lors de l'affinage des tests pour un niveau de tests, afin de définir les objectifs par objet de tests et caractéristique Qualité à vérifier (évolution, fonctionnalité). Cette estimation se fait avec le testeur qui a la connaissance précise des tâches à réaliser, et est pondérée avec les facteurs de qualité du processus.

L'investissement est à mettre en balance avec le coût de la non qualité. Une non qualité qui comprend, pour rappel :
- les coûts de supports (Détection, gestion, mise en oeuvre d'une solution palliative),
- les coûts de maintenance corrective (débogage, codage, tests, intégration, redéploiement en production).
- les coûts de perte de productivité des utilisateurs,
- le coût engendré par la non qualité des produits fabriqués, dans le cas où le logiciel est dédié à la fabrication de produits manufacturés.

Pourquoi se poser ces questions ?

Parce que le jeu en vaut bien la chandelle. Vais-je perdre mes clients si je livre un système logiciel qui n'assure pas une disponibilité 360/365 jours par an ? Vais-je attenter à la vie de personnes si je leur livre des systèmes défaillants ? Ou bien suis-je une entreprise qui offre un service exclusif et dans ce cas le risque pour moi est de voir les utilisateurs mécontents attaquer mes sites WEB et me critiquer dans la presse ?

Les risques liés aux non fonctionnement sont avérés pour tous les projets logiciels. Maintenant, il faut que les parties prenantes en aient conscience. Il faut qu'un médiateur explique aux clients, et aux développeurs, qu'entre le développement et l'acceptation utilisateur, de nombreux tests sont à réaliser pour couvrir des risques, comme de voir un client insatisfait. Ces tests sont regroupés par niveau :

Du côté de la partie en charge de construire et de délivrer le produit :
- Les tests de composants qui vérifient que les composants développés respectent les spécifications techniques à destination du développeur
- Les tests d'intégration de composants qui vérifient les interfaces entre programmes Cobol, modules java, DLL Windows..., et ceux qui vérifient les liens à partir des Dossiers d'architecture détaillés.
- Les tests systèmes réalisés par le fournisseur pour vérifier que ce qui a été développé correspond bien aux spécifications générales et que toutes les caractéristiques Qualité sont bien prises en compte.

Coté client en charge de l'intégration du système développé dans son environnement :
- Les tests d'intégration pour vérifier l'interopérabilité des systèmes, les interfaces entre elles.

- Des tests système qui vérifient que le système complet répond aux caractéristiques Qualité attendues
- Les tests d'acceptation utilisateur qui valident la concordance avec l'expression des besoins
- Les tests d'acceptation opérationnelle qui valident que le système développé respecte les normes/exigences d'exploitation.

Ces questions auxquelles vous aurez répondu vous permettront de concevoir une politique et une stratégie de test. A partir de ce cadre général, les chefs de projets ou chefs de projets de tests négocieront avec les parties prenantes ce qui convient le mieux pour le montage industriel du projet.

Pour chaque projet, il conviendra de mettre en oeuvre une logique industrielle adaptée. En fonction des systèmes développés, des organisations, des cycles de développement, de la maturité des organisations, il convient de rajouter/préciser des niveaux de tests ou de les supprimer.

Mettre en place les tests dans une organisation n'est pas chose aisée et nécessite de faire appel à des professionnels du test. C'est pour cela que l'ISTQB a défini plusieurs niveaux de certification qui assurent ce savoir-faire.

Article rédigé par

Bertrand Cornanguer, Secrétaire du CFTL (Comité Français des Tests Logiciels) Consultant Senior en qualité logicielle.
Diplômé de l'ISTIA d'Angers en 2005, mais actif dans la qualité logicielle depuis 1993, Bertrand Cornanguer, à rejoint SOGETI après un passage auprès de ACIAL où il a développé les formations Fondation et Avancées de l'ISTQB. Depuis 2010, Bertrand exerce en qualité de Secrétaire du CFTL pour lequel il a dirigé les travaux liés à la définition des fiches métier du test. Titulaire d'un DESS Qualité et Sûreté de fonctionnement des Systèmes Informatiques, il a dispensé plusieurs conférences et formations dans le domaine des tests de logiciels. En tant qu'expert, Bertrand Cornanguer est également membre du groupe de travail international pour le marketing de l'ISTQB et très actif dans le domaine des tests de logiciels.