Actualit�

Quelles sont les questions � se poser pour d�ployer les tests � l'�chelle d'une organisation ?

Article
Publication : 15 / 05 / 2012
104 Consultations
(gras]Par Bertrand Cornanguer, Secr�taire du CFTL (Comit� Fran�ais des Tests Logiciels) Consultant Senior en qualit� logicielle.

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 ? 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
o 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.
o 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
o les testeurs qui v�rifieront que tout fonctionne avant de livrer le client.
o le d�veloppeur qui cr�era le logiciel et ex�cutera les tests unitaires (nouveaut� et non r�gression)

� Les personnes support comme les :
o sp�cialistes m�thodes, normes et outils de tests
o gestionnaires d'environnements de tests, sp�cialistes des jeux de donn�es de tests
o responsables de la gestion de configuration
o 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,
o Les plans de tests de niveau les pr�ciseront

� Les approches de tests concernent les chefs de projet de tests
o 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.


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
o v�rifient les interfaces entre programmes Cobol, modules java, DLL Windows...,
o 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.

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.