FICHE THMATIQUE

Toutes les directions mtier ou infortests, mais rares sont celles qui sont rellement satisfaites de la place effectivement occupe par cette activit. On a le sentiment den faire trop ou pas assez, que personne ne se satisfait vraiment des rsultats obtenus, que les intervenants sont peu motivs. Limage des tests reste mitige. Aucune solution napparat rellement satisfaisante, dfinitivement acquise. Pourquoi ce dficit dimage, pourquoi ce sentiment ? Les tests sont lactivit qui fche par excellence alors que spcifier avec les mtiers est passionnant, concevoir la solution est cratif, dvelopper techniquement ou faire voluer le logiciel est constructif et lexploiter en production cest rendre service tous les jours. Et puis, tester arrive toujours au mauvais moment, puisque la qualification devient lactivit dominante la sortie du tunnel de la ralisation, lorsque lon est press de mettre en production. Beaucoup dinterlocuteurs doivent se remettre autour dune table : les mtiers, les dveloppeurs ou mainteneurs et les exploitants.

JUILLET 2010

Conseils en SI & Gestion de projets

Tests et recettes dans les projets Systme dInformations : une tape dlicate
matique connaissent limportance des

Pour finir, laffaire nest pas simple : on sait que la dmarche de qualification fonctionnelle suppose une prparation importante, base sur les exigences fonctionnelles initialement collectes, que des scnarios doivent tre produits pour reflter le droulement attendu des procdures informatises, cas par cas. La fabrication technique des jeux dessai ou des bases de test est une expertise en elle-mme. Cette fiche tente de lever un peu le voile sur lactivit de la recette, aborde les tapes nce ssaires sa bonne ralisation et rappelle ses risques.

SOMMAIRE
Quest-ce que la recette ?............................................ 2 La stratgie de recette ............................................... 3 Le cahier de recette .................................................. 5 Les recettes ............................................................ 6 Les vrifications ....................................................... 7 Les risques .............................................................. 8 Quelques dfinitions .................................................. 9

Fiche Thmatique JUILLET 2010

Quest-ce que la recette ?

La recette , cest lopration par laquelle le client reconnat que le produit livr par le fournisseur est conforme la commande passe, quil est exploitable dans le systme dinformations de lentreprise, et enfin quil est opportun de le mettre la disposition des utilisateurs.
Pourquoi doit-on tester une application ?

Fig. 1 : Charge pour traiter une anomalie - Pour liminer le stress li lincertitude - Parce que lon a tout y gagner Diminution des cots de maintenance, Optimisation de la rception Amlioration de la fiabilisation Satisfaction du travail bien fait Remotivation des quipes La recette est ralise selon des procdures qui ne simprovisent pas. Lanticipation de cette activit permet damliorer lefficacit des tests (simplification et optimisation des tests).
La recette se dcompose alors en deux grandes phases :

- Pour obtenir, tout dabord, la satisfaction du client. Mais cette dernire sobtient progressivement et non pas le jour de la rception - Parce que le bon fonctionnement de lapplication doit tre garanti. Les risques lis aux dfaillances doivent tre matriss. La rception dun logiciel nest pas un exercice de corde raide mais est laboutissement dune dmarche matrise. - Parce que le dsordre cote. Les modles itratifs, tel le Unified Process, permettent de dmarrer les tests fonctionnels participant la vrification, beaucoup plus tt dans le droulement du projet. La conception des tests peut ainsi dmarrer ds que les exigences fonctionnelles dune itration sont disponibles, et leur excution ds quune version excutable de lapplication est disponible. La validation demeure la fin du cycle, en raison de son caractre contractuel . On observe une croissance exponentielle des cots dune anomalie en fonction du moment o elle est dcouverte (plus on la dcouvre tard dans le projet, plus elle cote cher).

Phase 1 : La prparation Cette phase consiste btir la stratgie de test. Il sagit de planifier les diffrentes activits sans ngliger la prparation logistique ncessaire une ralisation dans de bonnes conditions. Phase 2 : La ralisation Les tests sont raliss, les bogues sont remonts, le reporting informe le management et un bilan permet damliorer la prochaine srie de tests.

Fiche Thmatique JUILLET 2010

Fig. 2 : Dmarche de planification et ralisation de tests itratifs

La stratgie de recette
La stratgie de tests consiste dterminer prcisment les vrifications quil est indispensable de conduire. Elle permettra de dfinir la mthode utiliser et les preuves apporter. Le cahier de recette doit permettre de rpondre quelques questions : - Quest-ce qui sera test ? - A partir de quand les tests dbuteront ? - Jusqu quelle profondeur les tests seront effectus ? - Quel planning de tests est envisag? - Quelle organisation sera mise en uvre ? - Est-ce que lensemble de lapplication sera concerne par les tests ? - Quelles preuves tangibles seront fournies pour justifier de la bonne ralisation des tests ? - La stratgie de test doit rpondre plusieurs exigences : - Elle doit rester souple pour viter les blocages

- Elle doit intgrer les risques techniques et prvoir des alternatives - Elle doit rester centre sur son but: atteindre ses objectifs et identifier les chemins pour les atteindre - Elle doit tre collaborative avec les parties prenantes cela est encore plus vrai en approche itrative: les points de contacts entres quipes doivent tre bien identifis, les rgles de priorit doivent tre claires pour tous.
La gestion dune campagne de tests doit donc rpondre deux intrts qui peuvent paratre antinomiques: souplesse et rigueur.

Ainsi, on sattachera garder ces valeurs lesprit lors du droulement dune campagne de tests afin de trouver le bon quilibre entre la rigueur ncessaire au suivi et lvaluation de lexcution, et la souplesse ncessaire pour sadapter aux perturbations invitables.

Fiche Thmatique JUILLET 2010

La dmarche globale des tests doit suivre les tapes cl suivantes : - Dfinition des objectifs : Prendre en compte lensemble des spcificits du projet : exigences clients, criticit, caractristiques produit, - Estimation et identification des moyens disponibles : Humains, matriels, logiciel, - Planning de mise en uvre : Ordonnancement, composants unitaires, responsabilits, environnements informatiques, jeux dessais, - Organisation du processus de ralisation des tests : Traabilit, - Suivi de lavancement des tests : Tableaux de bord de suivi, % avancement, - Gestion des carts : Rsultats obtenus/rsultats attendus - Reporting : Remonte des points bloquants, - Ralisation dun bilan : valuation des tests
Stratgie de test Processus mtier Recette Version Reporting Besoins Tests de Validation

Stratgie de test

Reporting

Spcifications fonctionnelles Analyse des spcifications

Tests de Vrification

Cahier de recette

Spcifications techniques

Tests dintgration

Diminution des dfauts

Dtection et correction des anomalies

Conception et automatisation des tests

Scenarios et cas de test

Conception dtaille

Tests unitaires

Rfrentiel de test
Dveloppement

Excution des tests

Fig. 3 : Les tests et le cycle de dveloppement On distingue ainsi sous le nom de vrification les activits de tests visant sassurer que le produit dvelopp correspond en tout point la solution dcrite dans le dossier de spcifications ; et sous le nom de validation les tests visant sassurer que le produit correspond bien au besoin du donneur dordre (La MOA, Matrise dOuvrage). La vrification relve donc gnralement de la matrise duvre et la validation de la matrise douvrage. La vrification fait gnralement apparatre des dfauts de conception et des non conformits fonctionnelles, alors que la validation remonte le plus souvent des dfauts dans le recueil des besoins ou des ambiguts dans la comprhension et la formalisation des exigences.

Fiche Thmatique JUILLET 2010

Le cahier de recette
La thorie de linformatique, confirme dailleurs par la pratique, enseigne quil est impossible de prouver quun logiciel ne comporte aucune erreur. Lapplication du thorme de Gdel nous permet daffirmer qu'il est impossible de concevoir un programme capable de vrifier tous les programmes. Certes on peut dfinir des mthodes de vrification efficaces et les outiller de sorte qu'elles soient faciles utiliser. Mais ces mthodes, aussi efficaces soient-elles, ne garantissent pas que tous les programmes qu'elles valident soient corrects.
[] quel que soit le soin que lon apporte la dfinition des tests quelle comporte, on naura jamais la certitude que le logiciel ne comporte aucun bogue.

On peut toutefois, et cela relve du bon sens, vrifier quil remplit correctement les fonctions essentielles que lon attend de lui que ce soit en termes de performances, de qualit des donnes ou dinterface hommemachine. La liste des tests raliser doit tre tablie froid, avant la livraison du produit ; elle porte le nom de cahier de recette . La combinatoire des tests possibles tant infinie, le cahier de recette constitue une slection au sein de cette combinatoire. Certains tests sont coteux en raison de la volumtrie ou des difficults techniques quils impliquent. Comme le budget accord la recette est limit, le cahier de recette doit idalement comporter la liste de tests la plus efficace pour un cot donn. Il est ncessaire dadapter la dmarche de tests au cycle de vie et la criticit du projet.

La procdure de recette ne peut donc pas tre exhaustive : quel que soit le soin que lon apporte la dfinition des tests quelle comporte, on naura jamais la certitude que le logiciel ne comporte aucun bogue.

Fig. 4 : Positionnement des tests dans le droulement dun projet Il faut que la recette soit effectue en partant de vraies donnes et non de donnes de qualit parfaite. On sait en effet quen informatique de gestion, les donnes sont souvent, pour des raisons parfaitement comprhensibles, de qualit variable (codages imparfaits, donnes man5
Fiche Thmatique JUILLET 2010

quantes, vrifications insuffisantes). Cest par rapport cet tat de fait quil faut valuer la qualit de lopration, et non par rapport au monde idal o les donnes seraient sans dfaut. Il faut prciser le protocole selon lequel la recette sera organise :

quelles seront les tches qui incomberont au client, celles qui incomberont au fournisseur ; quels seront les documents quils devront se communiquer; dans quel ordre les tests seront raliss ; quels seront les seuils dacceptation du produit. Si le protocole nest pas dfini lavance, le risque de conflits entre client et fournisseur sera lev.

La recette utilisateur comporte deux tapes : une recette technique, ralise par la direction informatique du client, vrifie que le produit est exploitable sur la plate-forme informatique de lentreprise (compatibilit avec ses matriels, systmes dexploitation et logiciels) et que la performance physique est acceptable (volumtrie des bases de donne et des flux de messages, dlais daffichage sur les crans des utilisateurs, robustesse en exploitation [valuation du systme aux cas limites]). Des tests de respect de lordonnancement sont galement raliss. Lobjectif tant de vrifier la dynamique des tches temps rel (synchronisation, priorits, paralllisme, prcdence,); une recette fonctionnelle, ralise par la matrise douvrage, vrifie que le produit fournit les fonctionnalits demandes par le cahier des charges et quil est acceptable par les utilisateurs.
La stratgie de tests doit galement comporter une stratgie de tests de non rgression.

Les recettes
Recette usine et recette utilisateur : On distingue deux tapes dans la recette : la recette usine , faite avant la livraison du produit par le fournisseur, permet celui-ci de vrifier que le produit est conforme la commande reue ; la recette utilisateur est faite par le client aprs livraison. La recette usine Il faut que le compte rendu de la recette usine soit livr par le fournisseur en mme temps que le produit : ce compte rendu apportera au client la preuve que le produit a t srieusement test avant sa livraison, et permettra de gagner du temps en ne refaisant pas les tests dj raliss par le fournisseur. Il faut prvoir la livraison du compte rendu de la recette usine dans le protocole de recette, sinon le client aura du mal lobtenir. Lors de cette phase, on ralise des tests unitaires et des tests dintgration. Les tests unitaires permettent dassurer les fondations de la construction logicielle. Ces tests permettent de limiter les carts par rapport toutes les spcifications du composant tester et dassurer la fiabilit de la phase de codage/paramtrage. Quant aux tests dintgration, ils permettent dassurer un bon fonctionnement de lassemblage logiciel/logiciel et logiciel/matriel. 6
Fiche Thmatique JUILLET 2010

Les anomalies dtectes : Les tests dtectent des anomalies ; chacune delles fait lobjet dune fiche danomalie envoye au fournisseur. Celui-ci corrige les anomalies jusqu convergence des tests. Il arrive parfois que la correction dune anomalie provoque dautres anomalies, ce qui peut obliger refaire des tests qui avaient auparavant donn un rsultat acceptable. On parle alors de tests de non rgression permettant de sassurer que les modifications effectues dans le logiciel ne dgradent

pas son comportement valid antrieurement. Ces tests sont demander au fournisseur mais le client se doit de vrifier la non rgression. Cela suppose alors de pouvoir comparer avec des rsultats passs : - Scnarios de tests - Base de donnes dessais - Environnements identiques La stratgie de test doit galement dfinir une stratgie de non rgression. Il est normal, invitable mme, quun logiciel dune certaine importance contienne des erreurs : la dtection danomalies au dbut de la recette na donc rien de scandaleux, mme si elle suscite toujours une tension entre client et fournisseur. Le vritable critre de qualit rside dans le dlai de correction des anomalies : si ce dlai est long, si les corrections suscitent dautres anomalies de telle sorte que le volume danomalies traiter ne diminue pas, le client doit sinterroger sur la qualit du logiciel et sur son volutivit.

Les vrifications
Lorsque les tests de recette ont converg, le client prononce une Vrification dAptitude au Bon Fonctionnement (VABF). Il est dusage dassocier ce jalon un jalon de facturation partielle. Puis le produit est mis en exploitation sur un site pilote. On dtectera alors dautres anomalies, puisque le cahier de recettes ne pouvait pas tre exhaustif. Elles devront elles aussi tre corriges. La convergence de ces corrections peut demander quelques mois. Cette tape termine, le client prononce la Vrification de Service Rgulier (VSR), ce qui est souvent associ au dernier jalon de facturation du fournisseur. Le produit peut alors tre dploy sur tous les sites de lentreprise, et l'on passe ltape du dploiement.

Fig. 5 : La rception dun projet

Fiche Thmatique JUILLET 2010

Les risques
Toute recette prsente des risques. Le test est lapplication concrte de la gestion des risques. valuer le risque est donc la raison dtre des tests, le corolaire pouvant se formuler de la manire suivante : tester cest choisir. Une bonne stratgie de tests devra donc sintresser aussi au processus de production du logiciel afin de dtecter les points faibles qui ont pu causer lintroduction de dfauts. Certaines anomalies napparatront donc que lors du test en site pilote. Il est donc prfrable que le passage entre la vrification daptitude et la mise en exploitation soit clairement dfini: si le produit est de grande taille, et livr sous forme de lots successifs, on sefforcera de dfinir ces lots de sorte que chacun soit un module exploitable , quil soit possible de le mettre en exploitation sur un site pilote ds sa livraison afin dviter l effet tunnel qui se produit lorsque la mise en exploitation ne peut se faire qu'aprs la rception de l'ensemble des lots. Lapplication de la stratgie de tests reste le point dlicat du processus et conditionne la bonne russite dune campagne de tests fonctionnels. Lactivit de tests a en effet pour particularit de ne jamais tre finie : on peut tester une application linfini et continuer de trouver des dfauts. Cette particularit impose une organisation trs diffrente des autres activits dingnierie logicielle. Il convient de dterminer avant le dmarrage des tests, les conditions darrt de la campagne de tests, conditions qui dterminent les critres permettant de conclure la russite ou lchec de la campagne. Lors du droulement dune campagne, ces critres doivent tre suivis prcisment et rgulirement afin de mesurer tout instant lcart par rapport lobjectif, et prendre les dcisions ncessaires son atteinte ou bien ar8
Fiche Thmatique JUILLET 2010

rter la campagne. On peut noter parmi les critres typiques : - le taux de couverture des fonctions ou des processus mtier - le taux de couverture des rgles de gestion - le taux de russite des tests - le nombre de dfauts mineurs, majeurs, et bloquants
Le test est lapplication concrte de la gestion des risques. valuer le risque est donc la raison dtre des tests, le corolaire pouvant se formuler de la manire suivante : tester cest choisir.

Il convient, lors de llaboration du cahier de recette, de ne pas trop hirarchiser les tests: on risquerait de bloquer longtemps certains tests en lattente de la correction des anomalies dtectes en amont. Le dlai ncessaire la convergence des tests est alatoire : on ne peut pas valuer a priori la difficult des corrections. Il faudra grer la crise entre client et fournisseur quand ce dlai semble sallonger indfiniment : cette crise peut aboutir soit (finalement) une livraison de qualit acceptable, soit au refus du produit. Certaines des fiches danomalie seront interprtes par le fournisseur comme des demandes dvolution et il demandera pour les corriger une rallonge au contrat. Il en rsultera alors des ngociations entre client et fournisseur. Enfin la recette est toujours pour le client un moment dlicat, puisque le produit quil dcouvre rsulte la fois des spcifications quil a fournies et de la ralisation btie par le fournisseur sur la base de ces spcifications.

Nous contacter : contact@conseilorga.com

Quelques dfinitions
CAMPAGNE DE TEST : Cest llment le plus important et qui consiste organiser les tests. Une campagne de test dcrit quels sont les scnarios qui seront tests et donc enchans les uns aux autres. Dans le cadre de la recette fonctionnelle, il sagira de dcliner les scnarios excuter permettant par exemple de crer une situation applicative et ensuite dans un second scnario de faire subir des traitements applicatifs ces donnes, pour enfin vrifier les rsultats obtenus. Ce sont les rgles de gestion qui font rfrence et constituent le rsultat attendu. Lexcution de la fonction dans lapplication permettra de constituer le rsultat obtenu. CAS DE TEST : Cest un composant du scnario, et reprsente une variante du scnario. Par exemple pour le test dun changement dadresse, le cas numro un prvoira un changement dadresse en France, alors que le cas de test 2 prvoira un changement dadresse dans un pays tranger. JEUX DE TEST : Cest un jeu de donnes, inscrit dans un document dans lequel figurera de manire prcise quelles sont les donnes qui seront saisies dans lapplication. Ce document inclura aussi le rsultat attendu au niveau des donnes rendues par le systme, et ce en fonction des rgles de gestion. PLAN DE TEST : ou protocole de test. Cest un document qui prcise ce que sera le test, quelles fonctionnalits de lapplication seront testes en prcisant leur ordre ainsi que leur enchanement. Le plan de test dcrit quelles sont les rgles de gestion du dossier de conception qui seront testes. QUALIFICATION FONCTIONNELLE : Cest lensemble des actions qui permettent de s'assurer que les dveloppements/paramtrages raliss lors du projet rpondent convenablement aux besoins exprims et fonctionnent correctement au sein de l'environnement cible. SCENARIO DE TEST : Cest le concept qui prcise la fonction tester, ce document est li un document de jeux de donnes de test. La description y est prcise et se rfre pour la recette fonctionnelle aux dossiers de conception. Un scnario de test est compos de un ou plusieurs cas de tests.

Fiche Thmatique JUILLET 2010