bilan de qualification - freedriaf1.free.fr/bilanelmesbahiabdelilah.pdf · 2008-04-20 · début...

bilanelmesbahiabdelilah Abdelilah EL MESBAHI - Fitec CQL1- 2008

1

Abdelilah EL MESBAHI

Bilan De

Qualification

Flight Reservation System Version 4b


2

Sommaire

1- Informations sur le projet ____________________________________________________________________________ 3

1.1- Objectif du document _______________________________________________________________________ 3

1.2- Présentation générale _______________________________________________________________________ 3

1.3- Caractéristiques du projet ___________________________________________________________________ 3

2- Démarche de qualification ___________________________________________________________________________ 3

2.1- Démarche appliquée au projet ________________________________________________________________ 3 2.1.1- Planning de Recette ________________________________________________________________________ 4

2.2- Risques ___________________________________________________________________________________ 4 2.2.1- Ressources _______________________________________________________________________________ 4 2.2.2- Plates-formes _____________________________________________________________________________ 4 2.2.3- Disponibilité des outils _____________________________________________________________________ 4

3- Gestion des anomalies _______________________________________________________________________________ 4

3.1- Périmètre de test ___________________________________________________________________________ 4 3.1.1- Présentation et interprétation des résultats ______________________________________________________ 4 3.1.2- Coefficient d’Importance d’une Fonctionnalité (CIF) _____________________________________________ 5 3.1.3- Indice de Qualité Globale ___________________________________________________________________ 5

4- Bilan de recette ____________________________________________________________________________________ 5

4.1- Détails des exigences ________________________________________________________________________ 5

4.2- Création des tests ___________________________________________________________________________ 7

4.2- Exécution des tests __________________________________________________________________________ 8

4.3- Les scénarii ________________________________________________________________________________ 8

4.4- L’exécution manuelle des tests _______________________________________________________________ 10

4.5- Les Anomalies ____________________________________________________________________________ 10

5- Analyse des résultats. _________________________________________________________________________ 11

5.1- Indice de qualité ou l’Acceptation de la mise en production _______________________________________ 11 5.1.1- Les anomalies : criticité de l’exigence et gravité de l’anomalie. _____________________________________ 11 5.1.2- Céalcul du poids de la (non) qualité __________________________________________________________ 12 5.1.3- Conditions d’acceptation ___________________________________________________________________ 12

5- __________________________________________________________________________________________ Conclusion __________________________________________________________________________________________________ 13


3

1- Informations sur le projet

1.1- Objectif du document Le but de ce document est de développer un rapport de qualification concernant l’application « Flight Reservation » via les résultats de la campagne de tests. Au sortir de celle-ci, une mise en production ou non sera préconisée.

1.2- Présentation générale Flight Reservation System (FRS) est une application client/serveur à l’usage des agences de voyages. Elle doit s’installer sur les stations de travail des agents et sera connecté à un serveur central de base de données Oracle. Grâce à FRS, chaque agent sera en mesure de proposer des services de réservation de vols à ces clients. L’objet de ce document est de présenter le bilan des tests effectués pour la qualification de l’application FRS dans sa version 4b.

1.3- Caractéristiques du projet FRS est une Application Client/Serveur. Elle doit permettre une utilisation simultanée allant jusqu’à 2000 agents opérant dans un rayon de 1000 kilomètres autour du site hébergeant le serveur (Oracle). FRS doit permettre aux agents de créer, modifier, effacer des réservations de vols. Elle doit également permettre de créer et envoyer des télécopies de confirmation aux clients. Elle doit aussi produire des rapports et graphiques récapitulant les informations des réservations. FRS est une application sécurisée par l’attribution d’un identifiant et d’un mot de passe pour chaque agent. C’est également une application multilingue anglais, français, et allemand. L’extension à d’autres langue est prévue pour les prochaines versions.

2- Démarche de qualification

2.1- Démarche appliquée au projet La définition de l’application des points de vue fonctionnels et techniques telle que décrit dans le cahier des charges suppose que de nombreux tests soient effectués. Toutefois, compte tenu de notre environnement de qualification, certains tests n’ont pas été effectués puisqu’ils ne sont pas pertinents par rapport à la définition du cahier des charges.

Ainsi, ne disposant que d’un PC sous Windows XP, les tests de compatibilité sous OS/2 et X-Windows n’ont pas été effectués.

Toujours pour absence de matériel ad hoc, l’envoi de télécopie n’a pu être réellement testé. Seul le comportement simulé de l’application a été pris en compte pour cette fonctionnalité.

De même, en environnement de qualification, l’application se connecte sur une base MS Access installée en local, tandis qu’en environnement de Production nous devrions avoir une base Oracle située à distance, avec un accès à cette base par le réseau inter agence ou par modem RTC. Les tests de performance ont donc été exclus du périmètre de qualification puisque les résultats obtenus n’auraient en rien permis de tirer des conclusions sur les résultats en environnement de Production. Pour ces mêmes raisons, les tests de charge ont également été exclus du périmètre de test.

Seul donc les tests fonctionnels ont retenu notre attention.


4

2.1.1- Planning de Recette

Planifié Réalisé

Etapes Durée Durée

Réception application et CDC 0.5j 0.5j

Préparation et écriture exigences 1 j 1 j

Création Projet et paramétrage QC 0.5 j 1 j

Création Exigences et scénarii sous QC 1 j 1,5 j

Début recette 1 j 1.5 j

Fin recette et Analyse résultats 0.5j 0,5j

Préparation Bilan recette et soutenance 1 j 1 j

La création du projet de qualification sous Quality Center a pris plus de temps que prévu initialement. Afin de compenser ce retard, et compte-tenu d’une absence de deux journées, aucun test n’a été automatisé et la liste des tests a été réduite afin de pouvoir les effectuer dans de bonnes conditions.

2.2- Risques

2.2.1- Ressources Une seule personne était dédiée aux tests à effectuer et à leur organisation sur l’application. Cette dernière a donc veillé à documenter l’ensemble de ses actions et indiquer régulièrement l’état d’avancement de son travail. Ceci afin que le travail en question puisse aussi facilement que possible reprit par quelqu’un d’autre en cas d’absence imprévue.

2.2.2- Plates-formes Comme précisé en préambule de ce chapitre, l’application est supposée pouvoir fonctionner sur plusieurs plates-formes : Windows NT, IBM OS/2 et X-Windows. N’ayant à notre disposition qu’un environnement Windows XP Pro, nous ne pouvons garantir ou vérifier l’iso fonctionnalité dans les autres environnements.

De même, FRS est une application client/serveur et nous ne disposons pas d’un tel environnement pour les tests. Nous n’avons donc pu tester les mises à jour dans la base de données exactement comme elles devraient l’être en production, ni les tests de performances (connections simultanées via réseau d’agences ou modem RTC) puisque ces derniers n’auraient pas été pertinents.

2.2.3- Disponibilité des outils Les outils sont dès aujourd’hui disponibles. Pour pallier au risque de crash, des exports réguliers ont été effectués depuis Quality Center vers le poste de tests en local puis copiés sur un serveur réseau.

3- Gestion des anomalies

3.1- Périmètre de test

3.1.1- Présentation et interprétation des résultats Les anomalies mises en évidence pendant la recette sont classées en trois niveaux de gravité suivant leur influence sur le fonctionnement de l’application.

Les niveaux de gravité qui sont affectés aux anomalies sont les suivants :


5

Caractère de l’anomalie

Description Poids

Bloquante interdit l'utilisation d'au moins une fonction indispensable d'une fonctionnalité.

100

Moyenne interdit l'utilisation d'une fonction non indispensable d'une fonctionnalité.

50

Basse n'affecte pas l'utilisation d'une fonctionnalité. 10

L’anomalie détectée peut avoir un impact sur

• L’ergonomie : lourdeur dans l’enchaînement des fonctions, mauvaise présentation des informations ;

• Le fonctionnel : fonction non disponible ou non conformité aux spécifications,

• Logiciel : résultats erronés ;

• Documentation : erreur dans la documentation écrite ou dans l’information transmise à l‘utilisateur

• Sécurité : risque d’intégrité ou la confidentialité des données ;

• Robustesse : défaut de robustesse (arrêt intempestif du logiciel) ;

• Performance : lenteur de la restitution des données ;

• Configuration : gestion erronée ou insuffisante des éléments matériels ou logiciels de base.

3.1.2- Coefficient d’Importance d’une Fonctionnalit é (CIF)

Une exigence correspond à une attente fonctionnelle bien précise. Elle est définie par sa priorité (Haute, Moyenne, Faible) à laquelle on associe un coefficient (CIF) pour permettre sa pondération comme l’indique le tableau suivant :

Criticité de l’exigence CIF Haute 3

Moyenne 2

Faible 1

3.1.3- Indice de Qualité Globale

En fin de recette, un Indice de Qualité Globale - résultante du poids des anomalies et des CIF - est établi. On considère qu’une note supérieure à 100 pour le Seuil Qualité Global est le reflet d’une qualité inacceptable pour une mise en production de l’application.

4- Bilan de recette

4.1- Détails des exigences

Cette étape consiste à traduire les besoins du client en exigences fonctionnelles auxquelles devra répondre l’application.

Après lecture du cahier des charges, les exigences ont été créées et classées dans le module REQUIREMENT de QUALITY CENTER.

Les exigences ont été définies et classées par type (Fonctionnelle, Ergonomique, Technique, IHM et Sécurité) et criticité : 3 HAUTE, 2 MOYENNE, 1 FAIBLE.

La criticité d’une exigence indique son importance, ainsi les exigences niveau 3 sont indispensables


6

au service du client, celles de niveau 2 sont non indispensables et celles de niveau 1 n’entravent pas le fonctionnement normal de l’application.

La criticité se paramètre dans l’onglet « tools » puis sélectionner « customize » ensuite « project entities ».

Voici deux graphes sur les exigences utilisées dans cette campagne, le premier concerne les noms des exigences et leurs priorités :

Le second Graphe nous donne une vue sur les types d’exigences (et leur nombre) en fonction de la criticité.

ErgonomieFolderFunctionalGroupSécuritéTechnique

Requirem ents - Sum m ary Graph

Priorité - Criticité

1-F

aibl

e

2-M

oyen

ne

3-H

aute

Num

ber

of R

equi

rem

ents

17

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

0

8

5

16

AideAnnulation RéservationConnexionConsultation Réservation Exist..Consultation réservation par d..Consultation réservation par N..Consultation réservation par N..Consultation réservation par N..Création Nouvelle RéservationEnvironnementEnvoi TélécopieExigences FonctionnellesExigences IHMFormulaire uniqueGraphique analytiqueIntégrité de donnéesInterface multilingueLancement applicationLogin<Other>

Requirem ents - Sum m ary Graph

Priorité - Criticité

1-F

aibl

e

2-M

oyen

ne

3-H

aute

Num

ber

of R

equi

rem

ents

17

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

0

8

5

16


7

4.2- Création des tests

Cette étape s’effectue dans le module TEST PLAN de QUALITY CENTER et consiste à créer des cas de tests pour valider les exigences. Estimant le temps suffisant, même les exigences faibles ont été couvertes par au moins un test.

Le test se décompose en étapes définissant les actions à exécuter avec le résultat attendu. Certaines étapes sont dites « non passantes » afin de tester le comportement de l’application dans une situation inattendue.

Ci-dessous un exemple de test pour la consultation d’une réservation déjà enregistrée:

L’utilisation du paramétrage pour les valeurs de sortie et d’entrée a été largement utilisé, ce qui a permis une facilité d’écriture de cas de tests et une meilleure productivité lors de l’exécution. Tous les cas de tests définis ici sont de type manuel.

Voici un exemple de cas de test où j’ai utilisé l’appel d’autre test (Call Test) et le paramétrage des valeurs d’entrées et de sorties.


8

4.2- Exécution des tests

L’exécution s’effectue sur un PC Portable disposant de Windows XP SP2

Le test de l’application ne pourra pas être effectué sur les autres environnements (Windows X, NT et MacOS) car ces environnements ne sont pas disponibles.

Les tests de charges et de performances ne pourront pas être réalisés à cause de l’absence de licence LOAD RUNNER disponibles.

L’application étant déjà installée, les tests d’installation n’auront pas lieu.

4.3- Les scénarii

Avant d’exécuter les tests, il convient de les choisir en fonction d’une stratégie et de constituer ainsi un scénario dans le module TEST LAB. L’application étant nouvelle et le temps me paraissant suffisant, j’ai décidé de tester toutes les exigences. Ci dessous le scénario nommé Modification_date


9

Ici un graphe avec la liste des scenarii, le résultat de leur exécution et leur nombre.

Te

st Exe

cutio

n - S

um

mary G

raph

(Cro

ss

Te

st S

et)

Test Set

1.1.1. Login et PWD court

1.1.2. Login et PWD valides

1.1.3. Login sans PWD

1.1.4. login valide et pwd inv..

1.1.5. Sans login et PWD indif..

1.1.6. Intégrités Champ Login

1.3.1.1- Recherche par Nom_Com..

1.3.1.2- Recherche par Nom_Com..

1.3.1.3- Recherche par Nom_Par..

1.3.1.4- Recherche par Nom_Par..

1.3.1.5- Recherche Nulle

1.3.2.1- Recherche positive pa..

Annulation réservation

Création Nouvelle réservation

Envoi réservation par Fax et p..

Graphe

Intégrité données Nom client

Modification date

Modification réservation Exist..

Multilingue

Nom Complet_positive

Nom Partiel

Nom Partiel_positive

Rapport

Recherche négative par date de..

Résolution video

Résultat négatif nom complet

Résultat négatif recherche par..

Résultat unique Recherche par ..

Number of Tests 11109876543210

2

1

22

2

1

33

33

3

4

2

10

11

1

3

6

1

2

11

1

3

1

22

2

FailedPassed


10

4.4- L’exécution manuelle des tests

Les tests du scénario sont exécutés manuellement par le bouton « RUN ». A chaque écart entre le résultat attendu, décrit dans l’étape et le résultat constaté, le test est passé en « Failed » et une anomalie définie par sa sévérité (mineure, majeure, bloquante) est créée dans le module

DEFECTS comme suit :

4.5- Les Anomalies

Une anomalie désigne la non-conformité de l’application par rapport aux spécifications. Chaque anomalie est associée à un niveau de gravité appelé également sévérité, en fonction de son impact

sur le fonctionnement de l’application.

On retrouve ci dessous les poids associés aux trois niveaux de gravité retenus pour ce projet.

Niveaux de gravité d’une l’anomalie Description Poids

Bloquante Interdit l'utilisation d'une fonction indispensable de l’application. La fonctionnalité ne pouvant être contournée par l’opérateur, l’anomalie est bloquante

100

Importante Interdit l'utilisation d'une fonction non indispensable de l’application. Solution de contournement possible mais risqué et source d’erreurs

50

Mineure Elle n'affecte pas l'utilisation d'une fonctionnalité 10


11

5- Analyse des résultats.

5.1- Indice de qualité ou l’Acceptation de la mise en production

5.1.1- Les anomalies : criticité de l’exigence et g ravité de l’anomalie.

Ce graphe montre le nombre d’anomalies et leurs gravités par criticité de l’exigence correspondante ce qui facilite l’analyse des résultats des exécutions.

1-Mineure2-Importante3-Bloquante

Defects - Sum m ary Graph

Priorité - Critic ité

1-F

aibl

e

2-M

oyen

ne

3-H

aute

Num

ber

of D

efec

ts

11

10

9

8

7

6

5

4

3

2

1

0

4

3

10


12

5.1.2- Calcul du poids de la (non) qualité

Le poids de la (non) qualité est calculé selon la formule suivante :

Où : Nb(F) = Nombre d’anomalies bloquantes de la fonctionnalité F Nimp(F) = Nombre d’anomalies importantes de la fonctionnalité F Nmin(F) = Nombre d’anomalies mineures de la fonctionnalité F CIF(F) = Coefficient d’importance fonctionnelle de la fonctionnalité F

P = Poids

Voici les valeurs des inconnus de la formule ci-dessus.

Chaque anomalie rencontrée suite à l’exécution des tests est pondérée par sa gravité et par la criticité de l’exigence à laquelle elle se rattache.

Le calcul du poids de la non qualité de l’application n’a aucune valeur si les exigences ne sont pas couvertes par des tests. Les exigences devront être couvertes à 100%.

Calcul du poids de la non

qualité

Criticité des exigences Total (non) qualité = 2240

Faible 1

Moyenne 2

Haute 3

G

ravi

té d

es

anom

alie

s

Bloquante 100

0 0 4*100*3=1200 1200

Importante 50

2*50*1=100 1*50*2=100 5*50*3=750 950

Mineure 10

2*10*1= 20 2*10*2=40 1*10*3=30 90

5.1.3- Conditions d’acceptation

Cette acceptation n’aura lieu que si les tests couvrent une partie suffisante des exigences de l’application.

De même, on utilise la formule de calcul du seuil d’acceptation :

Poids d’une anomalie bloquante x CIF bas = 100*1=100

Donc, on n’autorisera aucune anomalie bloquante avec un CIF bas

F=n

NQP = ∑(Nb (F) x Pb x CIF(F)) + (Nimp (F) x Pimp x CIF(F)) + (Nmin (F) x Pmin x CIF(F)) F=1


13

5- Conclusion

Le poids de la non qualité de l’application s’élève à 2240, ce qui est bien au delà du seuil de 100 fixé.

A cela s’ajoute le fait que plus 30% des exigences hautes n’ont pu être testées du fait de l’inadéquation de l’environnement de test avec le futur environnement de production ou de l’absence de moyens techniques.

En conséquence, je préconise de ne pas mettre l’app lication en production.

bilan de qualification - freedriaf1.free.fr/bilanelmesbahiabdelilah.pdf · 2008-04-20 · début...

Documents