Juillet 2010 - Les Tests Et l'Informatique

8/18/2019 Juillet 2010 - Les Tests Et l'Informatique

1/9

1 Fiche Thématique JUILLET 2010

FICHE JUILLET

2010

Direction de projets et programmes

THÉMATIQUETests et recettes dans les projets Systèmed’Informations : une étape délicate Toutes les directions métier ou infor-

matique connaissent l’importance des

tests. Rares sont celles qui sont réel-

lement satisfaites de la place effecti-

vement occupée par cette activité. On

a le sentiment d’en faire trop ou pas

assez, que personne ne se satisfait

vraiment des résultats obtenus, que les

intervenants sont peu motivés. L’image

des tests reste mitigée. Aucune solu-

tion n’apparaît réellement satisfai-

sante, définitivement acquise.

Pourquoi ce déficit d’image, pourquoice sentiment ?

Les tests sont l’activité qui fâche par

excellence alors que spécifier avec les

métiers est passionnant, concevoir la

solution est créatif, développer techni-

quement ou faire évoluer le logiciel est

constructif et l’exploiter en pr oduction

c’est rendre service tous les jours.

Et puis, tester arrive toujours au mau-

vais moment, puisque la qualification

devient l’activité dominante à la sortie

du tunnel de la réalisation, lorsque l’on

est pressé de mettre en production.

Beaucoup d’interlocuteurs doivent se

remettre autour d’une table : les mé-

tiers, les développeurs ou mainteneurs

et les exploitants.

Pour finir, l’affaire n’est pas simple : la démarche

de qualification fonctionnelle suppose une prépa-

ration importante, basée sur les exigences fonc-

tionnelles initialement collectées. Des scénarios

doivent être produits pour refléter le déroulement

attendu des procédures informatisées, cas par cas.

La fabrication technique des jeux d’essai ou des

bases de test est une expertise en elle-même…

SSOOMMMMAAIIRREE

Qu’est-ce que la recette ?............................................ 2

La stratégie de recette ............................................... 3

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

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

Les vérifications ....................................................... 7

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

Quelques définitions .................................................. 9

Vincent DrecqProfessionnel certifié PMP, iltravaille depuis plus de 17 ans

dans le management de projets.Sa vision du projet est trèspragmatique et orientée versles résultats.

Il est l’auteur de « Pratiquesde management de pro-jet, 40 outils et tech-

niques pour prendre la bonne décision »aux éditions DUNOD

Cette fiche thématique est gratuite, n’hésitez

pas à la diffuser largement à votre entourage.


2/9


La « recette », c’est l’opération parlaquelle le client reconnaît que le

produit livré par le fournisseur estconforme à la commande passée, qu’ilest exploitable dans le systèmed’informations de l’entreprise, et en-fin qu’il est opportun de le mettre àla disposition des utilisateurs.

Pourquoi doit-on tester une application ?

- Pour obtenir, tout d’abord, la sa-tisfaction du client. Mais cettedernière s’obtient progressivementet non pas le jour de la réception

- Parce que le bon fonctionnementde l’application doit être garanti.Les risques liés aux défaillancesdoivent être maîtrisés. La récep-tion d’un logiciel n’est pas unexercice de corde raide mais estl’aboutissement d’une démarchemaîtrisée.

- Parce que le désordre coûte.Les modèles itératifs, tel le Uni-fied Process, permettent de dé-marrer les tests fonctionnels parti-cipant à la vérification, beaucoupplus tôt dans le déroulement duprojet. La conception des testspeut ainsi démarrer dès que lesexigences fonctionnelles d’une ité-ration sont disponibles, et leurexécution dès qu’une version exé-

cutable de l’application est dispo-nible. La validation demeure à lafin du cycle, en raison de son ca-ractère « contractuel ». On ob-serve une croissance exponentielledes coûts d’une anomalie en fonc-tion du moment où elle est décou-verte (plus on la découvre tarddans le projet, plus elle coûtecher).

Fig. 1 : Charge pour traiter une anomalie

- Pour éliminer le stress lié àl’incertitude

- Parce que l’on a tout à y gagner

Diminution des coûts de main-tenance,

Optimisation de la réception

Amélioration de la fiabilisation

Satisfaction du travail bien fait

Remotivation des équipes

La recette est réalisée selon des pro-cédures qui ne s’improvisent pas.

L’anticipation de cette activité per-met d’améliorer l’efficacité des tests(simplification et optimisation destests).

La recette se décompose alors en deux grandes phases :

Phase 1 : La préparation

Cette phase consiste à bâtir la straté-gie de test. Il s’agit de planifier lesdifférentes activités sans négliger lapréparation logistique nécessaire àune réalisation dans de bonnes condi-tions.

Phase 2 : La réalisation

Les tests sont réalisés, les bogues sontremontés, le reporting informe le ma-nagement et un bilan permetd’améliorer la prochaine série detests.

Qu’est-ce que la recette ?


3/9


Fig. 2 : Démarche de planification et réalisation de tests itératifs

La stratégie de tests consiste à dé-terminer précisément les vérificationsqu’il est indispensable de conduire.Elle permettra de définir la méthodeà utiliser et les preuves à apporter. Lecahier de recette doit permettre derépondre à quelques questions :

-

Qu’est-ce qui sera testé ?- A partir de quand les tests débute-

ront ?

- Jusqu’à quelle profondeur les testsseront effectués ?

- Quel planning de tests est envisagé?

- Quelle organisation sera mise enœuvre ?

-

Est-ce que l’ensemble del’application sera concernée par lestests ?

- Quelles preuves tangibles serontfournies pour justifier de la bonneréalisation des tests ?

- …

La stratégie de test doit répondre àplusieurs exigences :

-

Elle doit rester souple pour éviterles blocages

- Elle doit intégrer les risques tech-niques et prévoir des alternatives

- Elle doit rester centrée sur son but:atteindre ses objectifs et identifierles chemins pour les atteindre

- Elle doit être « collaborative » avecles parties prenantes – cela est en-core plus vrai en approche itéra-

tive: les points de contacts entreséquipes doivent être bien identi-fiés, les « règles de priorité » doi-vent être claires pour tous.

Ainsi, on s’attachera à garder ces va-leurs à l’esprit lors du déroulementd’une campagne de tests afin de trou-ver le bon équilibre entre la rigueurnécessaire au suivi et à l’évaluationde l’exécution, et la souplesse néces-saire pour s’adapter aux perturbationsinévitables.

La stratégie de recette

La gestion d’une campagne de testsdoit donc répondre à deux intérêtsqui peuvent paraître antinomiques:souplesse et rigueur.


4/9


La démarche globale des tests doit suivre les étapes clé suivantes :

- Définition des objectifs :

Prendre en compte l’ensemble desspécificités du projet : exigencesclients, criticité, caractéristiques

produit, … - Estimation et identification des

moyens disponibles :

Humains, matériels, logiciel, …

- Planning de mise en œuvre :

Ordonnancement, composants uni-taires, responsabilités, environne-ments informatiques, jeuxd’essais, …

- Organisation du processus de réali-sation des tests :

Traçabilité, …

- Suivi de l’avancement des tests :

Tableaux de bord de suivi, % avan-cement, …

- Gestion des écarts :

Résultats obtenus/résultats atten-dus

- Reporting :

Remontée des points bloquants, …

- Réalisation d’un bilan :

Évaluation des tests

Processusmétier

Besoins

Spécificationsfonctionnelles

Spécificationstechniques

Conceptiondétaillée

Développement

Tests uni taires

Tests deValidation

Recette Version

Tests deVérification

Testsd’intégration

Stratégiede test

Cahier derecette

Scenarioset cas de

test

Reporting

Diminutiondes

défauts

Référentielde test

Stratégie detest

Analyse desspécifications

Conception etautomatisation

des tests

Exécution destests

Détection etcorrection des

anomalies

Reporting

Fig. 3 : Les tests et le cycle de développement

On distingue ainsi sous le nom de véri-fication les activités de tests visant às’assurer que le produit développécorrespond en tout point à la solutiondécrite dans le dossier de spécifica-tions ; et sous le nom de validation les tests visant à s’assurer que le pro-duit correspond bien au besoin dudonneur d’ordre (La MOA, Maîtrised’Ouvrage).

La vérification relève donc générale-ment de la maîtrise d’œuvre et la va-lidation de la maîtrise d’ouvrage. Lavérification fait généralement appa-raître des défauts de conception etdes non conformités fonctionnelles,alors que la validation remonte le plussouvent des défauts dans le recueildes besoins ou des ambiguïtés dans lacompréhension et la formalisation desexigences.


5/9


La théorie de l’informatique, confir-

mée d’ailleurs par la pratique, en-seigne qu’il est impossible de prouverqu’un logiciel ne comporte aucuneerreur. L’application du théorème deGödel nous permet d’affirmer qu'il estimpossible de concevoir un pro-gramme capable de vérifier tous lesprogrammes. Certes on peut définirdes méthodes de vérification efficaceset les outiller de sorte qu'elles soientfaciles à utiliser. Mais ces méthodes,

aussi efficaces soient-elles, ne garan-tissent pas que tous les programmesqu'elles valident soient corrects.

La procédure de recette ne peut doncpas être exhaustive : quel que soit lesoin que l’on apporte à la définition

des tests qu’elle comporte, on n’aurajamais la certitude que le logiciel necomporte aucun bogue.

On peut toutefois, et cela relève du

bon sens, vérifier qu’il remplit correc-tement les fonctions essentielles quel’on attend de lui que ce soit entermes de performances, de qualitédes données ou d’interface homme-machine. La liste des tests à réaliserdoit être établie à froid, avant la li-vraison du produit ; elle porte le nomde « cahier de recette ».

La combinatoire des tests possiblesétant infinie, le cahier de recetteconstitue une sélection au sein decette combinatoire. Certains testssont coûteux en raison de la volumé-trie ou des difficultés techniquesqu’ils impliquent. Comme le budgetaccordé à la recette est limité, le ca-hier de recette doit idéalement com-porter la liste de tests la plus efficacepour un coût donné. Il est nécessaired’adapter la démarche de tests au

cycle de vie et à la criticité du projet.

Fig. 4 : Positionnement des tests dans le déroulement d’un projet

Il faut que la recette soit effectuée enpartant de « vraies données » et nonde données de qualité parfaite. Onsait en effet qu’en informatique degestion, les données sont souvent,

pour des raisons parfaitement com-préhensibles, de qualité variable (co-dages imparfaits, données man-

quantes, vérifications insuffisantes).C’est par rapport à cet état de faitqu’il faut évaluer la qualité del’opération, et non par rapport aumonde idéal où les données seraientsans défaut.

Il faut préciser le protocole selon le-quel la recette sera organisée :

Le cahier de recette

[…] quel que soit le soin que l’onapporte à la définition des tests qu’ellecomporte, on n’aura jamais la certitudeque le logiciel ne comporte aucunbogue.


6/9


quelles seront les tâches qui incombe-ront au client, celles qui incomberontau fournisseur ; quels seront les do-cuments qu’ils devront se communi-quer; dans quel ordre les tests serontréalisés ; quels seront les seuils

d’acceptation du produit. Si le proto-cole n’est pas défini à l’avance, lerisque de conflits entre client et four-nisseur sera élevé.

Recette « usine » et recette « utilisateur » :

On distingue deux étapes dans la re-cette : la « recette usine », faite

avant la livraison du produit par lefournisseur, permet à celui-ci de véri-fier que le produit est conforme à lacommande reçue ; la « recette utilisa-teur » est faite par le client après li-vraison.

La recette usine

Il faut que le compte rendu de la re-cette usine soit livré par le fournisseuren même temps que le produit : cecompte rendu apportera au client lapreuve que le produit a été sérieuse-ment testé avant sa livraison, et per-mettra de gagner du temps en ne re-faisant pas les tests déjà réalisés parle fournisseur. Il faut prévoir la livrai-son du compte rendu de la recetteusine dans le protocole de recette,sinon le client aura du mal à l’obtenir.

Lors de cette phase, on réalise des

tests unitaires et des testsd’intégration. Les tests unitaires per-mettent d’assurer les fondations de laconstruction logicielle. Ces tests per-mettent de limiter les écarts par rap-port à toutes les spécifications ducomposant à tester et d’assurer lafiabilité de la phase de co-dage/paramétrage.

Quant aux tests d’intégration, ils

permettent d’assurer un bon fonc-tionnement de l’assemblage logi-ciel/logiciel et logiciel/matériel.

La recette utilisateur comporte deuxétapes :

une recette technique, réali-sée par la direction informa-tique du client, vérifie que leproduit est exploitable sur laplate-forme informatique del’entreprise (compatibilité avecses matériels, systèmesd’exploitation et logiciels) etque la performance physiqueest acceptable (volumétrie desbases de donnée et des flux demessages, délais d’affichagesur les écrans des utilisateurs,robustesse en exploitation

[évaluation du système aux caslimites]). Des tests de respectde l’ordonnancement sont éga-lement réalisés. L’objectifétant de vérifier la dynamiquedes tâches temps réel (syn-chronisation, priorités, parallé-lisme, précédence,…);

une recette fonctionnelle,réalisée par la maîtrised’ouvrage, vérifie que le pro-duit fournit les fonctionnalitésdemandées par le cahier descharges et qu’il est acceptablepar les utilisateurs.

Les anomalies détectées :

Les tests détectent des anomalies ;chacune d’elles fait l’objet d’une«fiche d’anomalie» envoyée au four-nisseur. Celui-ci corrige les anomaliesjusqu’à convergence des tests. Il ar-rive parfois que la correction d’uneanomalie provoque d’autres anoma-lies, ce qui peut obliger à refaire destests qui avaient auparavant donné unrésultat acceptable. On parle alors de

tests de non régression permettantde s’assurer que les modifications ef-fectuées dans le logiciel ne dégradent

Les recettes

La stratégie de tests doit égalementcomporter une stratégie de tests denon régression.


7/9


pas son comportement validé anté-rieurement. Ces tests sont à deman-der au fournisseur mais le client sedoit de vérifier la non régression. Celasuppose alors de pouvoir compareravec des résultats passés :

-

Scénarios de tests- Base de données d’essais

- Environnements identiques

La stratégie de test doit égalementdéfinir une stratégie de non régres-sion.

Il est normal, inévitable même, qu’unlogiciel d’une certaine importancecontienne des erreurs : la détectiond’anomalies au début de la recetten’a donc rien de scandaleux, même sielle suscite toujours une tension entreclient et fournisseur. Le véritable cri-tère de qualité réside dans le délai decorrection des anomalies : si ce délaiest long, si les corrections suscitentd’autres anomalies de telle sorte quele volume d’anomalies à traiter nediminue pas, le client doit

s’interroger sur la qualité du logicielet sur son évolutivité.

Lorsque les tests de recette ont con-vergé, le client prononce une «Vérifi-cation d’Aptitude au Bon Fonction-

nement» (VABF). Il est d’usaged’associer ce jalon à un jalon de fac-turation partielle. Puis le produit estmis en exploitation sur un site pilote.On détectera alors d’autres anoma-lies, puisque le cahier de recettes nepouvait pas être exhaustif. Elles de-vront elles aussi être corrigées. Laconvergence de ces corrections peutdemander quelques mois.

Cette étape terminée, le client pro-nonce la «Vérification de ServiceRégulier» (VSR), ce qui est souventassocié au dernier jalon de facturationdu fournisseur. Le produit peut alorsêtre déployé sur tous les sites del’entreprise, et l'on passe à l’étape du déploiement.

Fig. 5 : La réception d’un projet

Les vérifications


8/9


Toute recette présente des risques. Letest est l’application concrète de lagestion des risques. Évaluer le risqueest donc la raison d’être des tests, lecorolaire pouvant se formuler de la

manière suivante : tester c’est choi-sir. Une bonne stratégie de tests de-vra donc s’intéresser aussi au proces-sus de production du logiciel afin dedétecter les points faibles qui ont pucauser l’introduction de défauts.

Certaines anomalies n’apparaîtrontdonc que lors du test en site pilote. Ilest donc préférable que le passageentre la vérification d’aptitude et la

mise en exploitation soit clairementdéfini: si le produit est de grandetaille, et livré sous forme de lots suc-cessifs, on s’efforcera de définir ceslots de sorte que chacun soit un « mo-dule exploitable », qu’il soit possiblede le mettre en exploitation sur unsite pilote dès sa livraison afind’éviter l’« effet tunnel » qui se pro-duit lorsque la mise en exploitation nepeut se faire qu'après la réception del'ensemble des lots.L’application de la stratégie de testsreste le point délicat du processus etconditionne la bonne réussite d’unecampagne de tests fonctionnels.L’activité de tests a en effet pour par-ticularité de ne jamais être « finie » :on peut tester une application àl’infini et continuer de trouver desdéfauts. Cette particularité impose

une organisation très différente desautres activités d’ingénierie logicielle.Il convient de déterminer avant ledémarrage des tests, les conditionsd’arrêt de la campagne de tests, con-ditions qui déterminent les critèrespermettant de conclure à la réussiteou à l’échec de la campagne. Lors dudéroulement d’une campagne, cescritères doivent être suivis précisé-ment et régulièrement afin de mesu-rer à tout instant l’écart par rapport àl’objectif, et prendre les décisionsnécessaires à son atteinte ou bien ar-

rêter la campagne. On peut noterparmi les critères typiques :

- le taux de couverture des fonctionsou des processus métier

- le taux de couverture des règles degestion

-

le taux de réussite des tests- le nombre de défauts mineurs, ma-

jeurs, et bloquants

Il convient, lors de l’élaboration ducahier de recette, de ne pas trop hié-rarchiser les tests: on risquerait debloquer longtemps certains tests enl’attente de la correction des anoma-lies détectées en amont.

Le délai nécessaire à la convergencedes tests est aléatoire : on ne peutpas évaluer a priori la difficulté descorrections. Il faudra gérer la criseentre client et fournisseur quand cedélai semble s’allonger indéfiniment :cette crise peut aboutir soit (finale-ment) à une livraison de qualité ac-ceptable, soit au refus du produit.

Certaines des fiches d’anomalie se-ront interprétées par le fournisseurcomme des demandes d’évolution et ildemandera pour les corriger une ral-longe au contrat. Il en résultera alors

des négociations entre client et four-nisseur.

Enfin la recette est toujours pour leclient un moment délicat, puisque leproduit qu’il découvre résulte à la foisdes spécifications qu’il a fournies etde la réalisation bâtie par le fournis-seur sur la base de ces spécifications.

Les risques

Le test est l’application concrète dela gestion des risques. Évaluer lerisque est donc la raison d’être destests, le corolaire pouvant se formu-ler de la manière suivante : testerc’est choisir.

Nous contacter :[email protected]

mailto:[email protected]:[email protected]:[email protected]


9/9


CAMPAGNE DE TEST :C’est l’élément le plus important et qui consiste à organiser les tests. Une campagne detest décrit quels sont les scénarios qui seront testés et donc enchaînés les uns aux autres.Dans le cadre de la recette fonctionnelle, il s’agira de décliner les scénarios à exécuter

permettant par exemple de créer une situation applicative et ensuite dans un second scé-nario de faire subir des traitements applicatifs à ces données, pour enfin vérifier les résul-tats obtenus. Ce sont les règles de gestion qui font référence et constituent le résultatattendu. L’exécution de la fonction dans l’application permettra de constituer le résultatobtenu.

CAS DE TEST :C’est un composant du scénario, et représente une variante du scénario. Par exemple pourle test d’un changement d’adresse, le cas numéro un prévoira un changement d’adresse enFrance, alors que le cas de test 2 prévoira un changement d’adresse dans un pays étran-ger.

JEUX DE TEST :C’est un jeu de données, inscrit dans un document dans lequel figurera de manière précisequelles sont les données qui seront saisies dans l’application. Ce document inclura aussi lerésultat attendu au niveau des données rendues par le système, et ce en fonction desrègles de gestion.

PLAN DE TEST : ou protocole de test.

C’est un document qui précise ce que sera le test, quelles fonctionnalités de l’application

seront testées en précisant leur ordre ainsi que leur enchaînement. Le plan de test décritquelles sont les règles de gestion du dossier de conception qui seront testées.

QUALIFICATION FONCTIONNELLE :C’est l’ensemble des actions qui permettent de s'assurer que les développe-ments/paramétrages réalisés lors du projet répondent convenablement aux besoins expri-més et fonctionnent correctement au sein de l'environnement cible.

SCENARIO DE TEST :C’est le concept qui précise la fonction à tester, ce document est lié à un document de

jeux de données de test. La description y est précise et se réfère pour la recette fonction-nelle aux dossiers de conception. Un scénario de test est composé de un ou plusieurs casde tests.

Des techniques concrètes pour le management de projet !

Quelques définitions

Cette fiche thématique est gratuite, n’hésitez pas à la dif-fuser largement à votre entourage.

Documents

Juillet 2010 - Les Tests Et l'Informatique