Organisation de La Recette Fonctionnelle

Organisation de la Recette Fonctionnelle
2/1/2006
Jean Christophe BOUSCASSE - Consultant en Management de projets
Introduction Quest-ce que le Test, la Validation... ?

Tests & Validations : Dfinitions Exemple de modle : le TMM Les diffrents types de tests Prparer les Tests

Dmarche de conception des tests
Dfinir les ressources humaines Choisir une plate-forme de tests Choisir un outil de tests Dfinir une politique pour le suivi des anomalies Objectif d'un Plan de tests Structure d'un Plan de tests Les facteurs de risques Priorit du risque Cycle de test Rapport de test Interprtation des rsultats
Jean Christophe BOUSCASSE - Consultant en Management de Projets 2
Planifier les tests

Analyse du risque

Analyse des resultats

2/1/2006
Introduction Quest-ce que le Test, la Validation... ?


Planifier les tests

Analyse du risque


2/1/2006
Introduction

La recette : un mtier part entire ! La recette seffectue en Matrise douvrage Une recette est une validation des aspects fonctionnels dune application Elle se droule du cot du client Effectuer une recette, cest se placer de ce cot de la relation entre le fournisseur de la nouvelle application et celui qui va ensuite lutiliser
2/1/2006
Jean Christophe BOUSCASSE - Consultant en Management de Projets
Introduction
Toute entre dans le processus de recette est un livrable, en tant que tel, il satisfait aux caractristiques de qualit que le client est en droit dattendre Se placer de ce cot de la relation fournisseur client, cest se placer du cot de celui qui reoit des entres, et non celui qui doit adapter ce quon livre son environnement
2/1/2006
Introduction
Tout livrable est directement utilisable dans lenvironnement client Lors de la livraison dans lenvironnement, le fournisseur peut effectuer des tests permettant la signature dun PV de recette technique Le PV de recette dfinitive tant sign la fin de la recette Ainsi, le fournisseur est libr de ses engagements de garantie
2/1/2006
Introduction
Cette signature constitue galement le dbut du processus de maintenance
2/1/2006
Introduction Quest-ce que le Test, la Validation ?


Planifier les tests

Analyse du risque


2/1/2006
Quest-ce que le Test, la Validation ?
Tester consiste excuter un programme dans le but de faire apparatre des anomalies enfouies Le test appartient l'activit de vrification et de validation d'une application Cela consiste dterminer si cette dernire a t dveloppe correctement en fonction des exigences Les tches lies l'activit de vrification et de validation dmarrent avec le projet et s'adaptent chaque phase de dveloppement
2/1/2006
On peut se demander pourquoi chercher des anomalies si on suit une dmarche organise... Rponses :
Des erreurs ont peut-tre t commises au cours du dveloppement Les possibilits d'utilisation sont trs nombreuses Le logiciel n'a peut-tre pas t bien conu
2/1/2006
10
Sil nest pas toujours vident pour un responsable du SI de tester une application, il nen demeure pas moins que lorsque lide du test est accepte, le projet nen est pas russi pour autant Les tests doivent tre mens selon une dmarche et tre organiss
2/1/2006
11
On parlera de campagne, de scnarios, de cas de test, ainsi que de tests unitaires, fonctionnels, de non rgression... Le(s) probme(s)...
Les tests doivent tre mens de manire organise et tre grs en tant que projet part entire Dans une application, il nest pas possible de tout tester Des facteurs humains entrent en ligne de compte et ds lors ne peuvent tre pris en considration par linformatique
2/1/2006
Il faut bien sassurer que ce que lon dcide de tester rponde une couverture soit fonctionnelle soit technique dune telle ampleur que les risques pris soient minimes, par rapport au SI
2/1/2006
13


Planifier les tests

Analyse du risque


2/1/2006
Exemple de modle : le TMM
Ces dernires annes, les industriels du logiciel ont ralis des efforts importants pour livrer des produits de meilleure qualit. Cela fut un travail difficile, compte tenu de la complexit croissante des logiciels, des dlais impartis leur ralisation, et du niveau d'exigence exprim par les utilisateurs
2/1/2006
15
Pour parvenir ce rsultat, les industriels ont concentr leurs efforts sur l'amlioration des processus de dveloppement. Parmi les mthodes largement utilises, le " Capability Maturity Model ", CMM, tend devenir un standard
2/1/2006
16
Cependant, malgr le poids grandissant de l'effort de test sur les projets informatiques, ce domaine ne possdait pas de modle ou de mthode, servant de cadre cette pratique C'est pour combler ce vide, que la communaut du test, a cr son propre modle damlioration, TMM pour "Test Maturity Model". Fonctionnant suivant des modles de maturit des organisations, ce modle est le pendant de CMM
2/1/2006
17
L'intrt du modle TMM :
Qu'il soit utilis en complment de CMM, ou de manire autonome, le modle TMM offre une relle amlioration de l'effort de test Les niveaux de maturit sont autant de jalons qui permettent de baliser le parcours des organisations, d'une stratgie de dtection des anomalies vers celle de prvention Le modle offre un cadre rassurant et raliste, o chaque intervenant concourt efficacement la russite de l'ensemble
2/1/2006
18
Cette mthode ne se dcline pas uniquement en objectifs atteindre, elle propose une mthodologie qui permet de les atteindre Alors que les activits de test commencent tre reconnues, TMM va plus loin, en imposant le test comme une vritable profession
2/1/2006
19
Son contenu permet notamment :
De sparer le debugging du test ; cette propension concourt amliorer et clarifier les relations entre les quipes de dveloppement et celles de test De prendre en compte tous les aspects d'un processus de test structur (Cycle de vie, Techniques, Infrastructure, organisation)
2/1/2006
20
D'offrir un cadre l'implmentation des outils de test. Bon nombre d'checs, relatifs l'introduction de ces derniers, peuvent s'expliquer par un dcalage entre le niveau de maturit de l'organisation et les fonctionnalits structurantes des produits. L'mergence de TMM a conduit les diteurs segmenter leur offre en fonction des degrs de maturit rencontrs chez leurs clients et prospects
2/1/2006
21
D'amliorer l'image renvoye par les quipes de test. En effet, TMM apporte une transparence aux activits de qualification. L'ensemble des membres participant un projet peut savoir ce qui sera test et l'tat d'avancement de l'effort de test De dcrire les activits du testeur, concourrant ainsi une revalorisation de son statut. Il n'est plus un excutant de bout de chane mais un intervenant part entire sur l'ensemble du cycle de vie du projet
2/1/2006
22
Les diffrents niveaux de maturit :
La mthode TMM est balise par des niveaux de maturit, qui permettent d'accompagner les organisations, d'une organisation empirique des tests un processus de test efficace et optimis Ces diffrents niveaux sanctionnent la propension des entreprises, mettre en place et respecter un certain nombre de processus lis la qualification des logiciels. Ces niveaux correspondent des niveaux de maturit
2/1/2006
23
Niveau de Maturit 1
A ce niveau, l'effort de test est chaotique et empirique, il est principalement tourn vers la recherche des anomalies L'objectif est que les programmes tournent sans dfaillance majeure Les produits sont mis en production sans relle visibilit en termes de qualit et de risques encourus l'usage Aucun contrle visant vrifier la concordance avec les spcifications, la stabilit ou encore les performances, n'est effectu
24
2/1/2006
Niveau de Maturit 1
Les tests sont effectus par un personnel non spcialis et il n'existe aucun outil de gestion des exigences ou d'automatisation
2/1/2006
25
Niveau de Maturit 2
Pour ce niveau, le processus de test est dfini et clairement spar de la recherche des anomalies Afin de structurer et d'organiser l'effort de test, les plans de qualification obissent une stratgie Pour la dtermination des cas de tests pertinents, des techniques de formalisation des tests sont utilises
2/1/2006
26
Niveau de Maturit 2
Toutefois, l'effort de test continue se situer relativement tard dans le cycle de vie du projet, dans la phase de conception ou encore de dveloppement L'objectif principal tant de vrifier la concordance du produit aux spcifications Dernier lment constitutif de ce niveau, la dfinition d'un environnement de test optimal et oprationnel
2/1/2006
27
Niveau de Maturit 3
Pour les entreprises qui atteignent ce niveau de maturit, les activits de test sont prsentes sur tout le cycle de vie du projet L'effort de test prend forme ds le dbut du projet et est inscrit dans un plan de test global La stratgie de test est dtermine partir de l'valuation des risques, elle est base sur des spcifications correctement documentes
2/1/2006
28
Niveau de Maturit 3
Une entit responsable de la recette existe, ainsi que des programmes de formation aux techniques de test Le test est peru comme une profession, avec ses spcialistes Des revues d'inspection ou de pairs sont mises en place, cependant ce niveau elles ne font pas l'objet d'un process standard et document
2/1/2006
29
Niveau de Maturit 4
Ici, le processus de test est compltement dfini, reconnu et peut faire l'objet de mesure Les revues et les inspections existent de manire formelle sur tout le cycle de vie et sont partie intgrante de l'effort de test Les logiciels livrs sont valus en utilisant des critres qualitatifs comme la fiabilit, l'usabilit et la maintenabilit Les jeux d'essais sont centraliss et historiss, afin d'tre utiliser lors des campagnes de non rgression
30
2/1/2006
Niveau de Maturit 4
Un programme de mesure de la qualit fournit des informations sur le processus de test et la qualit des produits Les activits de test sont perues comme une valuation de la qualit des logiciels
2/1/2006
31
Niveau de Maturit 5
Ce dernier niveau correspond une optimisation des processus prcdemment dcrits Sur la base des rsultats obtenus en remplissant les objectifs des niveaux prcdents, le test est une activit capable de contrler les cots et son efficacit Des processus de prvention des anomalies et de contrle qualit sont implments Une procdure de slection et d'valuation des outils de test existe
32
2/1/2006
Niveau de Maturit 5
Les outils accompagnent aussi efficacement que possible les phases de design, d'excution et de gestion des jeux d'essai Au dernier niveau de maturit, le test est une activit dont l'objectif est de prvenir les anomalies (passage d'une stratgie de dtection une stratgie de prvention)
2/1/2006
33
Correspondance CMM et TMM
Le modle TMM a t dvelopp en complment de CMM Exemple 1 : pour atteindre le niveau de maturit 2 dans TMM, il faut que l'organisation ait mis en place :

Une gestion des exigences Une gestion de la configuration des logiciels
Ces deux items tant constitutifs du niveau 2 dans CMM
2/1/2006
34
Correspondance CMM et TMM
Exemple 2 : pour atteindre le niveau de maturit 5 TMM, l'organisation devra avoir conduit et mis en place :

Une stratgie de prvention des anomalies Un processus de conduite du changement
Items appartenant au niveau 5 dans CMM
2/1/2006
35


Planifier les tests

Analyse du risque


2/1/2006
Les diffrents types de tests
Les tests unitaires
Les tests unitaires consistent tester individuellement les composants de l'application. On pourra ainsi valider la qualit du code et les performances d'un module. Ces tests sont excuts pour valider l'intgration des diffrents modules entre eux et dans leur environnement d'exploitation dfinitif. Ils permettront de mettre en vidence des problmes d'interfaces entre diffrents programmes.
Les tests d'intgration
2/1/2006
37
Les tests fonctionnels
Ces tests ont pour but de vrifier la conformit de l'application dveloppe avec le cahier des charges initial. Ils sont donc bass sur les spcifications fonctionnelles et techniques. Les tests de non-rgression permettent de vrifier que des modifications n'ont pas altres le fonctionnent de l'application. L'utilisation d'outils de tests, dans ce domaine, permet de faciliter la mise en place de ce type de tests.
38
Les tests de non-rgression
2/1/2006
Les tests IHM
Les tests IHM ont pour but de vrifier que la charte graphique a t respecte tout au long du dveloppement. Cela consiste contrler : la prsentation visuelle : les menus, les paramtres d'affichages, les proprits des fentres, les barres d'icnes, la rsolution des crans, les effets de bord, la navigation : les moyens de navigations, les raccourcis, le rsultat d'un dplacement dans un cran.
2/1/2006
39
Les tests de configuration
Une application doit pouvoir s'adapter au renouvellement de plus en plus frquent des ordinateurs. Il s'avre donc indispensable d'tudier l'impact des environnements d'exploitation sur son fonctionnement.
2/1/2006
40
Voici quelques sources de problmes qui peuvent surgir lorsque l'on migre une application vers un environnement diffrent :
l'application dveloppe en 16 bits migre sur un environnement 32 bits, les DLL sont incompatibles, les formats de fichiers sont diffrents, les drivers de priphriques changent, les interfaces ne sont pas gres de la mme manire...
2/1/2006
41
Ainsi, pour faire des tests efficaces dans ce contexte, il est ncessaire de fixer certains paramtres comme par exemple :

la mme rsolution graphique, le mme nombre de couleurs l'cran, une imprimante identique, les mmes paramtres pour le rseau...
2/1/2006
42
Les tests de performance
Le but principal des tests de performance est de valider la capacit qu'ont les serveurs et les rseaux supporter des charges d'accs importantes. On doit notamment vrifier que les temps de rponse restent raisonnable lorsqu'un nombre important d'utilisateurs sont simultanment connects la base de donnes de l'application.
2/1/2006
43
Pour cela, il faut d'abord relever les temps de rponse en utilisation normale, puis les comparer aux rsultats obtenus dans des conditions extrmes d' utilisation. Une solution est de simuler un nombre important d'utilisateurs en excutant l'application partir d'un mme poste et en analysant le trafic gnr.
2/1/2006
44
Le deuxime objectif de ces tests est de valider le comportement de l'application, toujours dans des conditions extrmes. Ces tests doivent permettrent de dfinir un environnement matriel minimum pour que l'application fonctionne correctement.
2/1/2006
45
Les tests d'installation
Une fois l'application valide, il est ncessaire de contrler les aspects lis la documentation et l'installation. Les procdures d'installation doivent tre testes intgralement car elles garantissent la fiabilit de l'application dans la phase de dmarrage. Bien sr, il faudra aussi vrifier que les supports d'installation ne contiennent pas de virus.
2/1/2006
46


Planifier les tests

Analyse du risque


2/1/2006
Prparer les Tests
On organise la phase de test de la mme manire qu'on organise un projet. Ainsi, le premier travail consiste dfinir toute la partie ressources d'une part, et l'organisation des campagnes de tests, d'autre part
2/1/2006
48


Planifier les tests

Analyse du risque


2/1/2006
Prparer les Tests
Dfinir les ressources humaines
On se pose souvent la question de savoir qui doit participer aux tests S'il n'y a pas de rponse tranche cette question (cela dpend du projet), on peut tout de mme dfinir les rles suivants :
le chef des tests : tout comme un chef de projet, le chef des tests a pour mission d'assurer la bonne russite des tests. C'est pourquoi on choisira la personne qui a la vue la plus globale du projet.
2/1/2006
50
Prparer les Tests
S'il n'y a pas de rponse tranche cette question (cela dpend du projet), on peut tout de mme dfinir les rles suivants :
Le concepteur des jeux d'essais : on prendra de prfrence un programmeur ayant une grande exprience de l'environnement d'exploitation et de l'application. Pour prparer les jeux d'essais ce concepteur devra s'appuyer sur les spcifications techniques et le cahier des charges.
2/1/2006
51
Prparer les Tests
S'il n'y a pas de rponse tranche cette question (cela dpend du projet), on peut tout de mme dfinir les rles suivants :
Les testeurs : ce peut tre toutes personnes impliques dans le dveloppement et le dploiement de l'application. Le profil idal du testeur est un utilisateur expriment et motiv, ayant une bonne connaissance du logiciel. Toutefois, on vitera de faire participer les dveloppeurs eux-mmes.
2/1/2006
52


Planifier les tests

Analyse du risque


2/1/2006
Prparer les Tests
Choisir une plate-forme de test
Afin d'viter tout problme li une diffrence entre l'environnement de tests et d'exploitation rel, une mthode est de fixer dans le cahier des charges la configuration matrielle minimale Ainsi, les tests seront effectus sur plusieurs plates-formes, dont la configuration minimum
2/1/2006
54


Planifier les tests

Analyse du risque


2/1/2006
Prparer les Tests
Choisir un outil de tests
Les outils de test ont pour vocation de rejouer des scnarios de tests pour mettre en vidence des problmes de rgression ou de dgradation des performances Avantage : dtection des problmes de rgression en rejouant entirement des scnarios de tests identiques chaque version d'une application
2/1/2006
56


Planifier les tests

Analyse du risque


2/1/2006
Prparer les Tests
Dfinir une politique pour le suivi des anomalies
La faon dont va circuler les anomalies doit tre dfinie ds cette phase Il s'agit de se mettre d'accord sur la faon dont seront ralises les corrections et par qui De plus, les anomalies dclares suite aux tests seront consignes sur des formulaires avec l'tat de progression de la correction
2/1/2006
58


Planifier les tests

Analyse du risque


2/1/2006
Planifier les tests
Objectif d'un Plan de tests
L'activit de planification est productrice d'ides et d'organisation Elle exige une grande imagination, car elle ncessite de formaliser des processus qui sont en gnral mens de manire intuitive Le plan de tests recense les objectifs et les moyens pour raliser les tests Il permet l'organisation technique des tests, il planifie leur droulement dans le temps et dfinit les points de repre, en particulier les conditions d'arrt
2/1/2006
60
Planifier les tests
Objectif d'un Plan de tests
Il sert aussi de document de validation de la qualit finale du logiciel et fait partie des documents contractuels du projet, au mme titre que les spcifications techniques ou les besoins fonctionnels Il est conu par le responsable des tests et valid par le chef de projet
2/1/2006
61


Planifier les tests

Analyse du risque


2/1/2006
Planifier les tests
Structure d'un plan de tests
Introduction : l'introduction prsente les informations gnrales du plan : prsentation de l'application, Contexte de ralisation, Choix technologiques, Coordonnes du responsable des tests Projet tester : il s'agit ici de dcrire prcisment le projet : liste des modules et/ou des lots, date de livraison Documents joints : documents gnraux, documents techniques, documentation
2/1/2006
63
Planifier les tests
Environnement de test. Ce paragraphe prsentera une description la plus prcise possible des plate-formes, en indiquant si elles sont reprsentatives des plates formes utilisateurs : sites de test, configurations matrielles, outils de test, bases de test, donnes de test, coordonnes de l'administrateur de la base de donnes, coordonnes du responsable du parc micro
2/1/2006
64
Planifier les tests
Tests raliser : listes des modules tester, objectif des tests, exigences, analyse du risque, matrice Exigences/Risques pour dfinir les priorits, jeux d'essais, estimation de la charge Stratgie de tests. On dcrira dans ce paragraphe la dmarche mise en uvre pour raliser les tests : description de l'approche gnrale, phase de tests, campagne de test, ordre d'excution des tests
2/1/2006
65
Planifier les tests
Condition d'arrt : critres retenus et pourquoi Gestion des fiches d'anomalies : modles des fiches d'anomalie, actions et tats, gestion des flux, liste des intervenants. Ressources humaines : nom et responsabilit, informations utiles. Planning des tests : planning, acteurs
2/1/2006
66


Planifier les tests

Analyse du risque


2/1/2006
Analyse du risque
Une fois les objectifs de test recenss, il faut dfinir les objectifs les plus importants et ceux qui prsentent le plus grand risque Comme les tests ne pourront pas liminer toutes les anomalies de l'application, on sera toujours amen faire des choix Attention ne pas liminer les tests les plus importants On dfinira pour chaque objectif de test une priorit qui drivera directement du facteur de risque
2/1/2006
68
Analyse du risque
On peut dfinir le facteur de risque comme tant la combinaison de : la probabilit d'apparition d'un disfonctionnement et l'impact de ce disfonctionnement sur les utilisateurs ou sur l'environnement Cela consiste prendre chaque objectif de test, donc chaque fonction principale de l'application, et dfinir si la fonction est souvent utilise et quel sera impact d'un ventuel disfonctionnement
2/1/2006
69
Analyse du risque
Le rsultat de cette analyse du risque conduit attribuer une priorit chaque objectif de test qui fera l'objet d'un paragraphe spar du plan de tests Le risque s'applique des catgories particulires qui peuvent tre :
Fonctionnalit : la fonction teste ne correspond pas aux besoins, Performance : les temps de rponse sont inacceptables, Instabilit : les fonctions ne sont pas reproductibles,
70
2/1/2006
Analyse du risque
Le risque s'applique des catgories particulires qui peuvent tre :
Cot financier : le cot du disfonctionnement est important, Planning : la correction de l'anomalie induira un retard important de la livraison, Fiabilit : le nombre constat d'anomalies et leur svrit pose problme
2/1/2006
71


Planifier les tests

Analyse du risque


2/1/2006
Analyse du risque
Les facteurs de risque
Probabilits d'apparition :
C'est la premire tape de l'analyse du risque On parcourt l'ensemble des objectifs et on dfinit le degr d'utilisation de chaque fonction
2/1/2006
73
Analyse du risque
Dfinition des degrs de risque :
Invitable (une partie de l'application que tous les utilisateurs rencontreront ncessairement. Ex : l'cran d'accueil.), Frquent (une partie de l'application utilise par les utilisateurs, mais pas dans toutes les sessions. Ex : impression d'un document.), Occasionnel (une partie de l'application qu'un utilisateur moyen n'utilisera pas, mais qui peut tre utilise par un utilisateur expriment en cas de besoin. Ex : paramtrage des options.),
74
2/1/2006
Analyse du risque
Dfinition des degrs de risque :
Rare (une partie de l'application qui n'apparat que dans certains cas, dans le cadre d'oprations complexes. La majorit des utilisateurs ne l'utilisent pas, mais elle joue un rle dans certaines situations. Ex : modifications de barres d'outils.)
Cette analyse des probabilits d'apparition s'effectuera au niveau de chaque objectif de test. Elle guidera les testeurs vers les fonctionnalits les plus utilises
2/1/2006
75
Analyse du risque
Une fois les zones importantes identifies, il faut analyser l'impact d'un disfonctionnement sur l'utilisateur ou sur l'environnement externe l'application
2/1/2006
76
Analyse du risque
L'impact : on dfinit l'impact des anomalies avec les niveaux suivants :
Catastrophique (Ex : la machine s'arrte, le logiciel dans son ensemble ne fonctionne plus, on ne peut pas sauvegarder, etc.),
2/1/2006
77
Analyse du risque
Grave (Si cette fonction ne marche pas, l'application peut continuer, mais le risque de perdre des donnes ou d'utiliser des donnes corrompues est important. Il est ncessaire de relancer l'ordinateur pour rsoudre le problme. Ex : la communication vers l'ordinateur hte s'interrompt, et les donnes ne sont plus mises jour.),
2/1/2006
78
Analyse du risque
Modr (Le problme rencontr perturbe l'utilisateur, mais ce dernier peut le contourner en effectuant des actions complmentaires. Ex : la disquette de sauvegarde est pleine, l'utilisateur doit passer par le disque dur pour finir la sauvegarde.),
2/1/2006
79
Analyse du risque
Ennuyeux (Si cette fonction ne marche pas, on peut continuer utiliser l'application, mais elle peut poser des problmes ultrieurement. Ex : on veut entrer un nom de fichier de dix caractres, mais l'application ne permet d'en entrer que cinq.)
2/1/2006
80
Analyse du risque
Le fait de combiner les probabilits d'usage avec les impacts sur les utilisateurs va permettre de classer les objectifs de tests par priorit
2/1/2006
81


Planifier les tests

Analyse du risque


2/1/2006
Analyse du risque
Priorit du risque
Le fait de combiner les probabilits d'usage avec les impacts sur les utilisateurs va permettre de classer les objectifs de tests par priorit La priorit servira valoriser l'importance que l'on accorde chaque objectif de test Une priorit leve dfinira les problmes qui doivent imprativement tre rsolus, une priorit moyenne les problmes qui pourront tre rsolus ultrieurement, mais qu'il ne faut pas ngliger, et en fin une priorit basse les problmes dont la solution peut attendre et qui seront traits en dernier
83
2/1/2006
Analyse du risque
Priorit du risque
L'action suivante est d'assigner ces priorits aux objectifs de test Cette dmarche s'effectue en deux tapes : dfinir une table de risque, puis assigner des priorits en fonction de cette table Ex :
Invitable Eleve Eleve Moyenne Moyenne Frquent Eleve Eleve Moyenne Basse Occasionnel Eleve Moyenne Basse Basse Rare Moyenne Basse Basse Basse
Impact/Probabilit Catastrophique Grave Modr Ennuyeux
2/1/2006
84
Analyse du risque
Priorit du risque
La dernire tape de l'analyse du risque est la constitution de la matrice de risque pour l'ensemble des objectifs de test. Cette matrice contient les champs suivants : objectif de test, probabilit d'usage, impact, catgorie, sujet, risque
2/1/2006
85


Planifier les tests

Analyse du risque


2/1/2006
Cycle de test
Le cycle de test correspond la priode durant laquelle un ensemble de tests est excut A la fin de chaque cycle, un examen des rsultas obtenus permettra de dfinir si l'on peut passer ou non au cycle suivant Organiser ces cycles dans un tableau permettra de simplifier l'analyse des rsultats Si l'application dveloppe est une version n+1 d'une application existante, on sera amen en vrifier la non-rgression
2/1/2006
87
Cycle de test
Pour cela, on pourra dfinir un cycle de nonrgression qui consistera rejouer des scnarios de test de la version prcdente
2/1/2006
88
Rapport de test
On trouve en gnral cinq familles de rapport dans ce domaine :

les rapports de synthses, les rapports de couverture de test (ils mettent en relation les scnarios de test avec les objectifs et les rgles de gestion. Toutefois, mme avec l'aide de ce rapport il reste en gnral difficile d'affirmer que toute l'application a t teste)
2/1/2006
89
Rapport de test
les rapports d'avancement (afin de pouvoir valuer l'avancement des tests, on gnrera des rapports visualisant les scnarios enregistrs, ceux qui contiennent des bogues, par rapport l'ensemble des procdures. On pourra galement lister les scnarios qui auront t excuts sans problme. Comme les rapports de couverture de test, les rapports d'avancement doivent faire rfrence aux objectifs de test)
90
2/1/2006
Rapport de test
les rapports de performance (les performances sont lies aux temps de rponse observs lors des tests de monte en charge ou des tests en mode dgrad. Afin de simplifier la lecture de ces rapports, les rsultats obtenus pourront tre prsents sous la forme de graphiques appropris)
2/1/2006
91
Rapport de test
les rapports d'anomalies (ces rapports doivent faciliter le suivi d'une anomalie. De plus, ils permettront de dterminer quels sont les modules les plus fiables de l'application)
2/1/2006
92


Planifier les tests

Analyse du risque


2/1/2006
Interprtation des rsultats
Une fois les rapports de test crits, il faut se prononcer sur leur signification Le premier critre prendre en compte est li la phase de test que l'on vient d'excuter Si on se trouve dans des phases prliminaires, on aura la possibilit de corriger les anomalies dtectes sans trop perturber la suite des tests et le dveloppement ultrieur de l'application
2/1/2006
94
Si au contraire on se trouve dans une phase de test avance, il est important de prendre en compte l'impact de la correction des anomalies sur les tests ultrieurs
2/1/2006
95
Dans tous les cas, on veillera spcialement qualifier correctement les anomalies, surtout celles qui ont t dfinies comme bloquantes et on recherchera les modules provoquant le plus grand nombre d'anomalies
2/1/2006
96
Enfin, avant de dfinir les conditions de test du cycle suivant, il faudra prciser quelles sont les anomalies que l'on voudra suivre tout particulirement pour vrifier si elles ont bien t corriges
2/1/2006
97

Organisation de La Recette Fonctionnelle

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Organisation de La Recette Fonctionnelle

Transféré par

Droits d'auteur :

Formats disponibles

Organisation de la Recette Fonctionnelle

Jean Christophe BOUSCASSE - Consultant en Management de projets

Introduction Quest-ce que le Test, la Validation... ?

Dmarche de conception des tests

Planifier les tests

Analyse des resultats

Introduction Quest-ce que le Test, la Validation... ?

Dmarche de conception des tests

Planifier les tests

Analyse des resultats