JUILLET

2010

FICHE
THMATIQUE

Direction de projets et programmes

Tests et recettes dans les projets Systme

dInformations : une tape dlicate
Toutes les directions mtier ou infor-

Pour finir, laffaire nest pas simple : la dmarche

matique connaissent limportance des

de qualification fonctionnelle suppose une prpa-

tests. Rares sont celles qui sont rel-

ration importante, base sur les exigences fonc-

lement satisfaites de la place effecti-

tionnelles initialement collectes. Des scnarios

vement occupe par cette activit. On

doivent tre produits pour reflter le droulement

a le sentiment den faire trop ou pas

attendu des procdures informatises, cas par cas.

assez, que personne ne se satisfait

La fabrication technique des jeux dessai ou des

vraiment des rsultats obtenus, que les

bases de test est une expertise en elle-mme

intervenants sont peu motivs. Limage

Vincent Drecq

des tests reste mitige. Aucune solution napparat rellement satisfai-

Professionnel certifi PMP, il

travaille depuis plus de 17 ans
dans le management de projets.
Sa vision du projet est trs
pragmatique et oriente vers
les rsultats.

sante, dfinitivement acquise.

Pourquoi ce dficit dimage, pourquoi
ce sentiment ?
Les tests sont lactivit qui fche par
excellence alors que spcifier avec les

quement ou faire voluer le logiciel est

Pratiques
de management de projet, 40 outils et techniques pour prendre la bonne dcision

constructif et lexploiter en production

aux ditions DUNOD

cest rendre service tous les jours.

Cette fiche thmatique est gratuite, nhsitez

pas la diffuser largement votre entourage.

mtiers est passionnant, concevoir la

solution est cratif, dvelopper techni-

Et puis, tester arrive toujours au mauvais moment, puisque la qualification

devient lactivit dominante la sortie

Il est lauteur de

SOMMAIRE
Quest-ce que la recette ?............................................ 2

du tunnel de la ralisation, lorsque lon

La stratgie de recette ............................................... 3

est press de mettre en production.

Le cahier de recette .................................................. 5

Beaucoup dinterlocuteurs doivent se

Les recettes ............................................................ 6

remettre autour dune table : les m-

Les vrifications ....................................................... 7

tiers, les dveloppeurs ou mainteneurs

Les risques .............................................................. 8

et les exploitants.

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 ?

- 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).

Fiche Thmatique JUILLET 2010

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 :

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.

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

La stratgie de recette

- Elle doit intgrer les risques techniques et prvoir des alternatives

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 :

- Elle doit rester centre sur son but:

atteindre ses objectifs et identifier
les chemins pour les atteindre

- 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
3

Fiche Thmatique JUILLET 2010

- 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.

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,

- 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

- Planning de mise en uvre :

Ordonnancement, composants unitaires, responsabilits, environnements informatiques, jeux
dessais,

- Reporting :
Remonte des points bloquants,
- Ralisation dun bilan :
valuation des tests

Processus
mtier

Stratgie de
test

Recette Version

Reporting

Stratgie
de test

Tests de
Validation

Besoins

Tests de
Vrification

Spcifications
fonctionnelles

Analyse des
spcifications

Conception et
automatisation
des tests

Cahier de
recette

Scenarios
et cas de
test

Reporting

Spcifications
techniques

Tests
dintgration

Conception
dtaille

Diminution
des
dfauts

Dtection et
correction des
anomalies

Tests unitaires

Rfrentiel
de test

Excution des
tests

Dveloppement

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).

Fiche Thmatique JUILLET 2010

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.

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.

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.

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.

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.

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

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 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.

Cette fiche thmatique est gratuite, nhsitez pas la diffuser largement votre entourage.
Des techniques concrtes pour le management de projet !

Fiche Thmatique JUILLET 2010