Prêt à tester votre organisation ? Posez vous les bonnes questions avant
Après en avoir pris la décision, mettre en œuvre 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 ?
Nous nous attacherons, à travers cette chronique, à 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 œuvre.
- 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 œuvre
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 œuvre. 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’œuvre 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,
- gestionnaires d’environnements de tests,
spécialistes des jeux de données de tests,
- responsables de la gestion de configuration,
- les services/sociétés extérieures qui
exécutent des Tierces Recette Applicatives à différents niveaux
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 œuvre ? 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 test, 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 œuvre 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 œuvre 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 œuvre 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.
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 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
œuvre 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.
|