Cahier de Recette - mathieu.changeat.free.frmathieu.changeat.free.fr/stage/TEST-REC-2004-07-02-v1.1-CMA-VM… · Web viewL’équipe IBM de support à la recette effectue la correction

Cahier de Recette

du projet Farandole

Version 1.1

Objet du document :

Ce document regroupe l’ensemble des documents de recette du projet Farandole.

Statut du document : En cours d’élaboration En cours de validation Validé

Document : document.doc Date : 16/07/2004Version : 1.1Auteur : Christophe Matiachoff Page : 1/16

Validation

Nom Date Observations

Révisions

Version Date Auteur Objet1.0 29/06/2004 CMA Version initiale du modèle de cahier de

recette.1.1 02/07/2004 CMA Prise en compte des remarques IBM.


Table des Matières

1 PRÉAMBULE................................................................................................................................................4

2 PÉRIMÈTRE DE LA RECETTE................................................................................................................5

2.1 CRITÈRES DE RÉCEPTION........................................................................................................................52.2 NIVEAU DE SÉVÉRITÉ DES ANOMALIES..................................................................................................52.3 NATURE DES TESTS DE RECETTE ET DES ÉLÉMENTS À VÉRIFIER............................................................6

3 ORGANISATION DE LA PHASE DE RECETTE...................................................................................7

3.1 RÔLES ET PARTICIPANTS........................................................................................................................73.2 PÉRIODE DE RECETTE.............................................................................................................................8

4 PLAN DE TEST DE LA VÉRIFICATION D’APTITUDE AU BON FONCTIONNEMENT TECHNIQUE........................................................................................................................................................10

4.1 DÉFINITION...........................................................................................................................................104.2 EXÉCUTION...........................................................................................................................................104.3 FICHES DE TEST DE LA VABF TECHNIQUE..........................................................................................10

5 PLAN DE TEST DE LA VÉRIFICATION D’APTITUDE AU BON FONCTIONNEMENT FONCTIONNELLE..............................................................................................................................................12

5.1 DÉFINITION...........................................................................................................................................125.2 EXÉCUTION...........................................................................................................................................125.3 FICHES DE TEST D’INTÉGRATION FONCTIONNELLE.............................................................................13

6 EXERGUE...................................................................................................................................................15

6.1 POINTS STRUCTURANTS........................................................................................................................156.2 LIMITES................................................................................................................................................156.3 Points « ouverts ».................................................................................................................................15


1 Préambule

Le présent Cahier de Recette, prévu par le Plan d’Assurance Qualité, a pour objectif de définir les modalités des tests d’acceptation par la Direction du Budget des livrables fournis par IBM et comprend :

- la définition du périmètre de la recette (qu’est ce qui sera réceptionné, qu’est-ce qu’une anomalie),

- les rôles intervenant durant la recette (qui participera aux phases de recette),

- la période de recette et sa décomposition en phases (quand aura lieu la recette, comment se termine-t-elle),

- les plans de test (ce qui sera testé et comment).

Le Cahier de Recette est utilisé pour la Recette Usine conduite par IBM, et pour les Vérifications d’Aptitude au Bon Fonctionnement (VABF) Technique et Fonctionnelle conduites par la Direction du Budget. Dans la suite de ce document, le terme de recette est utilisé comme synonyme des phases de VABF Technique et Fonctionnelle.

Le présent Cahier de Recette décrit la recette de l’application Farandole. En particulier n’est pas traitée dans ce document la recette des livrables documentaires. Ces derniers sont validés conformément au Plan d’Assurance Qualité, pour la plupart avant la phase de recette.

Le présent document ne traite pas des points suivants, définis dans le Plan d’Assurance Qualité :

- les environnements de recette et leur localisation (où aura lieu la recette) ;

- la procédure de gestion des livraisons ;

- la procédure de gestion des anomalies.


2 Périmètre de la recette

2.1 Critères de réception

Les critères de recette sont les suivants :

- conformité aux spécifications fonctionnelles et transverses validées à l’issue de la phase L0,

- conformité aux normes techniques validées à l’issue de la phase L0,

- conformité aux objectifs de performance, définis par les transactions indiquées comme de référence dans les Plans de Test de ce document, et validées conjointement par IBM et la Direction du Budget.

Les spécifications et normes techniques sont regroupées dans le Dossier de Conception, livrable de la phase L0. Il centralise l’ensemble des spécifications (techniques et fonctionnelles) que devra respecter l’application.

Les spécifications indiquées dans le Dossier de Conception pourront être modifiées par les éléments suivants :

- des comptes-rendus de réunion validés en commun,

- des fiches de Demandes de Modifications validées en commun,

- des compléments de spécifications validés en commun.

Une Anomalie est définie comme une non-conformité au Dossier de Conception.

2.2 Niveau de sévérité des anomalies

Les anomalies sont affectées d’un niveau de sévérité déterminant leur importance :

- Anomalie de sévérité 1 (S1) : anomalie bloquant l’application et empêchant toute opération ou encore, anomalie définie comme telle d’un commun accord entre les parties pendant la recette.

- Anomalie de sévérité 2 (S2) : anomalie bloquant totalement l’exécution d’une fonction s’adressant à l’utilisateur final ou lui fournissant un résultat inexploitable mais autorisant l’utilisation de l’application pour d’autres fonctions, ou encore, anomalie conduisant à des pertes d’informations ou à des erreurs d’intégrité dans les bases de données, ou encore, anomalie définie comme telle d’un commun accord entre les parties pendant la recette.

- Anomalie de sévérité 3 (S3) : anomalie ne bloquant par l’utilisation de l’application ou d’une fonction principale de l’application mais pouvant perturber sous certaines conditions leur fonctionnement ou encore, anomalie définie comme telle d’un commun accord entre les parties pendant la recette. Ces perturbations conduisent à des limitations d’utilisation non critiques ou d’impact faible car pouvant être contournées.


Ces anomalies ne doivent pas conduire à des pertes d’informations ou d’intégrité dans les bases de données gérées par l’application.

- Anomalie de sévérité 4 (S4) : anomalie ne bloquant pas le fonctionnement de l’application (anomalie mineure et d’impact négligeable, par exemple d’ordre cosmétique) ou encore, anomalie définie comme telle d’un commun accord entre les parties pendant la recette.

2.3 Nature des tests de recette et des éléments à vérifier

L’ensemble des tests que la Direction du Budget réalisera est détaillé dans les chapitres Plan de Test de ce document, qui précisent les scénarios, cas de tests et jeux de données.

Pour pouvoir mener à bien les tests, une base de données cohérente est nécessaire. Pour cela la mise à disposition de données (en particulier de données de référence et de données provenant des systèmes externes) par la Direction du Budget est indispensable.

Les Plans de Test définissent

les grandes fonctions à tester,

selon quels scénarios,

avec quelles données (base de données et nomenclatures).

Ces informations sont décrites sous forme de fiches de test.

La conformité de l’application au Dossier de Conception est établie à l’issue de l’exécution des Plans de Test du présent document.


3 Organisation de la phase de recette

3.1 Rôles et participants

Afin d’assurer le suivi et la coordination des travaux de recette, IBM et la Direction du Budget nommeront des responsables, points de contact privilégiés durant cette phase :

- le Responsable de la Recette de la Direction du Budget,

- le Responsable IBM de la Recette.

Par ailleurs, les travaux de recette feront également intervenir :

- une équipe de recette de la Direction du Budget (personnes réalisant les tests),

- une équipe IBM de support à la recette (personnes réalisant les correctifs en cas d’anomalie).

De façon synthétique, l’intervention de ces rôles se déroulera de la façon suivante :

- L’équipe de recette de la Direction du Budget procède aux tests d’installation, de recette technique et de recette fonctionnelle en suivant les Plans de Tests définis dans ce document. Elle déclare auprès du Responsable de Recette de la Direction du Budget les éventuelles anomalies qu’elle rencontre et remplit les fiches correspondantes. Ces fiches devront être complètement remplies et comporter les informations permettant à IBM d’investiguer les causes de l’anomalie. L’équipe de recette de la Direction du Budget effectue la vérification des corrections fournies par IBM et a également la charge de réceptionner et installer les correctifs fournis par IBM.

- Le Responsable de Recette de la Direction du Budget propose une qualification (niveau de sévérité) des anomalies qui lui sont transmises, en s’assurant qu’il s’agit bien de non-conformités au Dossier de Conception et en vérifiant que la fiche d’anomalie est correctement renseignée. Il communique les fiches d’anomalies au Responsable IBM de la Recette. Il confirme ou infirme les correctifs après tests effectués par l’équipe de Recette de la Direction du Budget. Il réalise un point régulier sur le statut des anomalies et leur qualification en correspondance avec le Responsable IBM de la Recette.

- L’équipe IBM de support à la recette effectue la correction des anomalies, sa vérification et la préparation de la livraison des correctifs. Cette équipe effectue également la livraison technique des correctifs.

- Le Responsable IBM de la Recette confirme la livraison des correctifs au Responsable de la Recette de la Direction du Budget. Il réalise un point régulier avec le Responsable de la Recette de la Direction du Budget, au cours duquel le niveau de sévérité proposé pour les anomalies est confirmé ou requalifié en accord avec les deux parties. Un état de synthèse est soumis en Comité de Pilotage chaque semaine pour information et/ou arbitrage. Dans le cas où les informations fournies dans une fiche d’anomalie s’avéreraient insuffisantes pour permettre la correction de l’anomalie, le Responsable IBM de la Recette notifiera au Responsable de la Recette de la Direction du Budget que la fiche d’anomalie est en attente de complément d’information. Le processus


de traitement de cette fiche d’anomalie est suspendu jusqu'à l’obtention des informations nécessaires.

3.2 Période de recette

La recette se déroulera suivant les étapes suivantes :

1. IBM livre à la Direction du Budget l’application Farandole ainsi que l’ensemble de la documentation associée mise à jour, dont la procédure d’installation. La recette commence à la livraison par IBM de l’application, à la fin de la phase de recette usine.

2. La Direction du Budget installe l’application dans son environnement de recette en suivant la procédure d’installation fournie par IBM (cette procédure d’installation ayant fait l’objet d’une recette préalable, qui n’est pas traitée par le présent document).

3. La Direction du Budget déroule les Plans de Test de Recette du présent document. La Direction du Budget mettra en place l’organisation permettant de dérouler ce plan dans le délai prévu pour la réalisation de la recette, en prévoyant que des correctifs éventuels puissent imposer de dérouler à nouveau une partie des tests (tests de non régression).

La Direction du Budget prévoit de décomposer le déroulement de ses Plans de Test de la façon suivante :

- Vérification d’Aptitude au Bon Fonctionnement Technique. Durant cette phase, la Direction du Budget procédera à l’installation de l’application puis aux tests techniques détaillés dans le Plan de Test de la VABF Technique.

- Vérification d’Aptitude au Bon Fonctionnement Fonctionnelle. Durant cette phase, la Direction du Budget procédera aux tests fonctionnels détaillés dans le Plan de Test de la VABF Fonctionnelle.

Durant ces étapes de la recette, la Direction du Budget pourra détecter des anomalies. Celles-ci seront formalisées, traitées et suivies suivant le processus décrit dans le Plan Assurance Qualité.

Afin de déterminer les dates de fin des VABF, le scénario suivant est défini :

- A compter de la livraison par IBM de l’application Farandole, la Direction du Budget dispose de 15 jours calendaires pour effectuer les opérations de Vérification d’Aptitude au Bon Fonctionnement Technique :

En l’absence d’anomalie et passé ce délai de 15 jours calendaires, le prononcé de la VABF Technique (réception sans réserve majeure) sera formalisé par la signature d'un procès-verbal signé par IBM et la Direction du Budget au plus tard 2 jours ouvrés après cette date.

En cas d’anomalie(s) signalée(s) par la Direction du Budget, non corrigées à la fin du délai de 15 jours, toutes les anomalies de sévérité 1 et 2 étant résolues, des anomalies de sévérité 3 et 4 pourront être présentes après accord sur un engagement de résolution de ces anomalies. IBM communiquera alors à la Direction du Budget un plan de correction des anomalies de niveau de sévérité 3 et 4 détectées à ce stade. Dans ce cas la réception au titre de la VABF Technique sera formalisée par la signature d'un procès-verbal par IBM et la Direction du Budget après la fin de la


période de VABF Technique et au plus tard deux (2) jours ouvrés après accord entre les parties sur le plan de correction des anomalies de sévérité 3 et 4.

En cas d’anomalie(s) signalée(s) par la Direction du Budget, à la fin des 15 jours calendaires de VABF Technique, si des anomalies de sévérité 1 ou 2 sont encore présentes, IBM livrera ces corrections dans les meilleurs délais et la Direction du Budget les testera dans les meilleurs délais. En cas de décalage de la fin de la VABF Technique du fait d’IBM, la Direction du Budget disposera de 5 jours ouvrés pour prononcer la recette après la dernière livraison d’IBM.

- Le même type de processus sera appliqué pour la phase de VABF Fonctionnelle. A compter de la fin de la VABF Technique (réception sans réserve majeure), la Direction du Budget dispose de 15 jours calendaires pour effectuer les opérations de VABF Fonctionnelle.

Les 15 jours calendaires de chaque VABF doivent permettre à la Direction du Budget de réaliser l’ensemble de ses Plans de Test avec une marge suffisante pour la réalisation des tests des correctifs fournis par IBM. Le ratio préconisé par IBM est de prévoir 50% de temps pour la réalisation des tests et 50% pour des re-jeux.


4 Plan de Test de la Vérification d’Aptitude au Bon Fonctionnement Technique

4.1 Définition

Il s’agit de vérifier la conformité de l’application aux spécifications d’ordre technique :

Respect des conventions de nommage et normes de développement.

Compatibilité de l’application avec la ou les versions des logiciels cibles :

o Client :(Navigateur Web, MS Word).

o Serveur: (OS, serveur Web, serveur d’application, serveur éditique, MS Word, SGBD)

Vérification de l’exécution des tests techniques et fonctionnels définis dans les fiches du présent chapitre.

4.2 Exécution

Le tableau ci-dessous indique l’ensemble des tests qui seront effectués dans le cadre de la VABF Technique. L’ordre d’apparition dans le tableau est l’ordre dans lequel les tests doivent être réalisés.

TITRE DU TEST PROTOCOLE DE TESTInstallation des composants « Traitement »

Contrôle de la capacité à installer correctement le back office « Traitement »

Installation des composants « Editique »

Contrôle de la capacité à installer correctement le back office « Editique »

Echange intra applicatifs Contrôle des échanges suivant les couches réseau sur les différents protocoles mis en œuvre

Chargement initial de la base de données

Contrôle de la base de données afin de vérifier qu’elle a bien été chargée / contrôler les logs

Recalcul à froid des données Contrôle d’un échantillon de champs calculés de la base de données.

Logging et traces Lire les logs et traces pour vérifier leur exploitabilitéAffichage des pages Vérification du bon chargement des images incluse, du

comportement suivant la définition de l’écran.Habilitation Couvert par les fiches de test de la VABF Fonctionnelle

(FTF)Barre de navigation FTFBarre d’action FTFÉmission de mail FTFAccès LDAP FTFFonction Filtre des nomenclatures

FTF

Fonction Tri des nomenclatures FTFEvaluation de formules dans les nomenclatures

FTF

Evaluation de formules dans les FTF


TITRE DU TEST PROTOCOLE DE TESTprogrammes Java

A compléter.

4.3 Fiches de Test de la VABF Technique

Le modèle de fiche ci-dessous est à remplir pour chaque test de la VABF Technique.

Le texte en italique indique le mode de remplissage de la fiche.Les rubriques signalées par un astérisque * sont obligatoires.N/A signifie Non applicable ; s/o sans objet ; DCF date de création de la fiche.

Par jeux de test, on entend données en base et nomenclatures.


Projet FARANDOLE

Projet Farandole

Fiche de test de VABF Technique*Numéro : Attribué à la création de la fiche et repris dans le nom *Rédacteur : trigramme *Date de création : JJ/MM/AA*Titre du test : Libellé*Description : Décrire le protocole de test

Procédure de vérification de Conformité Technique Résultat

N°

Description Résultat Attendu Méthode de contrôle (affichage, log, script)

OK S1 S2 S3 S4 N° d’anomalie

Commentaire

1

2

3

4

5

6

7

Conclusion du testDate de fin: Statut :Liste des N° d’anomalie : Anomalies corrigées :Commentaire :


Projet FARANDOLE

5 Plan de Test de la Vérification d’Aptitude au Bon Fonctionnement Fonctionnelle

5.1 Définition

Il s’agit de vérifier le bon fonctionnement de bout en bout des modules applicatifs (enchaînement de fonctions).

Les interfaces seront testées pour vérifier les échanges avec un ministère participant.

Lorsque les modules applicatifs auront été jugés fonctionnellement stables, des tests techniques aux limites seront réalisés.

5.2 Exécution

Le tableau ci-dessous indique l’ensemble des tests fonctionnels qui seront effectués dans le cadre de la VABF Fonctionnelle. L’ordre d’apparition dans le tableau est l’ordre dans lequel les tests doivent être réalisés.

SCENARIO PROTOCOLE DE TESTProduction de document Couvert par les fiches de test de la VABF

Fonctionnelle (FTF)Test à faire pour chaque famille de document

Production de partie de document FTFSaisie des données et enregistrement effectif en base

FTF

Modification des données et mise à jour en base

FTF

Echanges avec le ministère FTFContrôles de surface FTFSaisie des textes riches FTFModification de textes riches FTFUpload de textes riches FTFContrôle de cohérence FTFEchanges avec le ministère FTF

A compléter et détailler.

Le tableau ci-dessous indique l’ensemble des tests techniques aux limites qui seront effectués dans le cadre de la VABF Fonctionnelle. L’ordre d’apparition dans le tableau est l’ordre dans lequel les tests doivent être réalisés.

SCENARIO PROTOCOLE DE TESTSur erreur (arrêt Oracle) Arrêt instance Oracle / contrôler les logs et les messages à

destination de l’utilisateur et cohérence des données


Projet FARANDOLE

SCENARIO PROTOCOLE DE TESTSur erreur (arrêt LDAP) Arrêt LDAP / contrôler les logs et les messages à destination

de l’utilisateurSur ereur (arrêt serveur Web)

Arrêt du service Apache / contrôler les logs et les messages à destination de l’utilisateur

Sur ereur (arrêt serveur d’application)

Arrêt du service / contrôler les logs et les messages à destination de l’utilisateur et cohérence des données

Sur erreur (arrêt serveur mail)

Arrêt serveur mail par Entreprise / contrôler les logs

Sur erreur (problème réseau)

Débrancher le câble réseau / contrôler les logs

Sur erreur (arrêt du serveur traitement)

Arrret brutal du serveur/ contrôler les logs et les messages à destination de l’utilisateur et cohérence des donnéesVérifier la reprise de service

Sur erreur (arrêt du serveur éditique - SGBD)

Arrret brutal du serveur/ contrôler les logs et les messages à destination de l’utilisateur et cohérence des donnéesVérifier la reprise de service

Gestion des erreurs Couvert par les fiches de test de la VABF Fonctionnelle (FTF)

A compléter.

5.3 Fiches de Test d’Intégration Fonctionnelle

Le modèle de fiche ci-dessous est à remplir pour chaque test de la VABF Fonctionnelle.

Les rubriques signalées par un astérisque * sont obligatoires.N/A signifie Non applicable ; s/o sans objet ; DCF date de création de la fiche.

Par jeux de test, on entend données en base et nomenclatures.


Projet FARANDOLE

Projet Farandole

Fiche de test de VABF Fonctionnelle*Ref : *Rédacteur : Trigramme *Date de création : JJ/MM/AA*Scénario :*Etape(s) : 1.

2.etc.

*Cas de test : 1. *Jeux de test : 1.2. 2.Etc. Etc.

Procédure de vérification de Conformité fonctionnelle Résultat

N° Description Résultat Attendu Méthode de contrôle OK S1 S2 S3 S4 N° d’anomalie

Commentaire

1

2

3

4

Conclusion du testDate de fin: Statut :Liste des N° d’anomalie : Anomalies corrigées :Commentaire :


Projet FARANDOLE

6 Exergue

6.1 Points structurants

6.2 Limites

6.3 Points « ouverts »


Documents

Cahier de Recette - mathieu.changeat.free.frmathieu.changeat.free.fr/stage/TEST-REC-2004-07-02-v1.1-CMA-VM… · Web viewL’équipe IBM de support à la recette effectue la correction