Module B :

Support méthodologie & outils de tests

De la conception à
l’exécution
V1.1

. VERIFIER .
VALIDER

ALTRAN CIS, de l’assurance Qualité à l’assurance de la qualité

 Plan de la formation

La spécification des tests – Le Plan de test

La conception des tests - Cahier de test

La mise en œuvre des tests

2
Le plan de test s’inscrit dans une démarche
Démarche de recette fonctionnelle MAP

S1 S2 S4 S5

Base de test
Reprise Organisation Préparation Exécution
S3
Existant de recette Constitution Déroulement
Conception
Spécifications Stratégie des jeux des tests,
Spécification
Générales de test, de données journal de
plan de test, des tests,
et détaillées Validation de test, fiches
Valorisation des
planning l’environnement d’anomalies
scénarios

(T5) Planifier les différentes

opérations de recette
(T4) Rédiger les cahier de recette et les scénarios de test
(T3) Participer à l’installation et à la gestion des environnements de recette
(T16) Vérifier la conformité … des produits livrés
(T17) Rédiger les procédures de paramétrage
(T4) Exécuter les cahier de recette et les scénarios de test
(T14) Valider le mode opératoire de outils
(T15) Tester les manuels utilisateurs
(T16) … Qualifier les produits livrés Management
Managementde derecette
recette
Production des indicateurs, reporting via tableaux de bord de suivi
Production des indicateurs, reporting via tableaux de bord de suivi
des tests et des anomalies, animation de l’équipe de recette,
des tests et des anomalies, animation de l’équipe de recette,
coordination
coordination
(T11) Evaluer et faire remonter les risques
(T7) Analyser/présenter les résultats de test
sous forme de rapport standards et exhaustifs.
(T10) Assurer un contrôle continu de la qualité des tests des documents d’échange et des livrables.
(T12) Participer à toute réunion relative à la recette utilisateur et au comité de suivi du contrat
(T18) Préparer et proposer les éléments de décision GO/NOGO.

© Propriété de MAP: « Toute reproduction, même partielle, sans l’autorisation de MAP est interdite. » « sujet » - « date » 29

3
L’objectif du plan de test

Stratégie de tests
Spécification
des tests

Plan de tests

Spécifications

Il est nécessaire pour chaque campagne de définir les modalités, les besoins, le périmètre des
tests et type de tests que vous avez à effectuer pour une campagne de test déterminée.

Celle ci se repose donc sur le document de stratégie en entrée ainsi que sur les spécifications en
entrée permettant de valider la campagne.

Une première lecture des spécifications est nécessaire pour compléter l’analyse du plan de test
ainsi que acquérir une bonne compréhension du système à tester.

Il s’agira d’établir une matrice de couverture afin de vous assurer que tous les éléments
sont pris en compte.
4
Le contenu du plan de test – Les exigences
Le plan de test : c’est le document qui va permettre de définir les règles du
de test lors d’une campagne (périmètre défini de fiches de tests).
On va définir les exigences de tests définies pour les fonctions testées ainsi
que les scénarii rattachés pour établir une matrice de couverture.
Le plan de test indique:
. les Exigences fonctionnelles ou autres à tester
. la criticité de ces Exigences
. le type de test et cas de test à réaliser
. les besoins techniques et fonctionnels à vérifier

Définition d’une Exigence:

Besoin ou attente formulée (ISO 9000/2000). Il s’agit d’un objectif de test.
Exemple :
⇒Je dois tester tel résultat pour valider la fonctionnalité XX (exigence
fonctionnelle)
⇒Je dois vérifier que l’application répond en moins de 2 secondes (exigence
de type performance). 5
La criticité des exigences
La criticité correspond à l’importance fonctionnelle ou technique du
besoin.
Il y a trois niveaux de criticité de besoin :
- Critique
- Majeur
- Mineur
Besoin critique Un besoin critique correspond à un besoin vital du produit
final.

Besoin majeur Un besoin majeur correspond à un besoin important mais non

vital du produit final.

Besoin mineur Un besoin mineur est un besoin ni majeur, ni critique

L’évaluation de la criticité d’un test sert à :

Priorisation des tests à passer en fonction du temps restant
Élaboration des campagnes de tests de non-régression
La fiche de test ou cas de test
Une fiche de test correspond à l’ensemble des actions à réaliser et
les résultats attendus pour valider une exigence. Pour chacun d’eux,
il faut déterminer les éléments suivants :

Couverture fonctionnelle
Indiquer les fonctionnalités qui vont être testées y compris les actions au sein des
fonctions

Couverture en terme de donnée

Indiquer la typologie et l’origine des données prises en compte pour
réaliser les tests. Pré requis.

Couverture technique
Indiquer les besoins en charge, stress et performance. Les traitements
batch ou JCL devant être lancés.

Définir la criticité des scénarii

La criticité des scénarii peut varier même pour une criticité d’exigence
établie.
La criticité des fiches de test

L’évaluation de la criticité d’un test sert à :

 Priorisation des tests à passer en fonction du temps restant

 Élaboration des campagnes de tests de non-régression

Des éléments d’évaluation :

 Y a-t-il un impact financier ou client, direct ou indirect, du non fonctionnement de cette
fonctionnalité ?
 Ex. : Émission d’un courrier erroné, annonce d’un résultat faux…

 Y a-t-il un impact, direct ou indirect, sur d’autres activités critiques au travers de

dépendances ?
 Ex. : Traitements batchs bloqués, début TP bloqué…

 Y a-t-il un impact sur les performances requises ou sur l’indisponibilité tolérée ?

 Ex. : temps de réponse exigé, batchs avec contraintes de durée…

La notation :
 Si la réponse à une de ces questions est Oui => niveau de criticité 1 (forte) ou 2
(majeure)
 Le niveau sera affiné par la probabilité de survenance.

 Sinon => niveau de criticité 3 (mineure)

 )
on
ti
op
ec
La matrice de couverture (matrice Alpha)

av
ie
ss

t
ra
do

nt
du

co
de

er
ov
an

on

s
ou
ed
m

ti

(s
uc
m

nd
co

tr

s
ha

se
ns
de

ri
en

l 'i

t
ep

en
if

d
nt
ot

tr
)

em
rs
er

r
ta

en
m

ie
lo

en
ov

ac
PC

is

t
ss
et

en
x
ex

pl
em
ed

au
FN

do
rt
pe

em
m
nd

rc

ca

gl
s

re
ur

ty

lle

ac
IC
pa

rè

io
ha

la
to

en
r

ie

pl
at
D
pa

e
du
re

de
on
rt

m
pp

lid
et

r
pa

lle
ie
on

re
i
s

el
it

lo

va
es
de

né

ss
X X X X X X X

ns

ue
ti

ré

ve
e

en
rt

e
co

uc

do
nc

on
ra
X X X X X X X

an
en

un
ca
f

es
ri
od

sa

is
(t
s

du

m
ta
X X X X X X X

d'
de

s
n

rt
ra
is
pr

te

de
lie

n
ca

ie
n
du

t
na
X X X X X X X

en

io
r

on

o
de

m
ca
io

on
du

ti

at
X X X X X X X

e
de

m
ti

no
de
at

la
ag
ur

is

ur
ut

ra

te
t

nu
X X X X X X X

lid

go
ra
te

ou
to

rç

ix
at

ct
ig

ai
Campagne1

an
da

liv
va
X X X X X X X

pr
re

er
fo

fa
aj
st

tr
AA AB AC AD AE AF AG AH AI AJ AK AL AM X X X X X X X

Impact C M M E G C C G E G E C E
Fréquence d'apparition du risque I O F I F F O F I I O F F
Criticité 3 1 2 2 3 3 3 3 2 3 1 3 1
C100 permutations état civil n° de permis X ●
C200 Interprétation manuelle et comparaison avec l'état COMPER X
C300 IHM : capacité de saisie des dates zéro X
C301 Test du batch de requête FNPC ● X
● ● ● ● ● ● ● ● ● ●
C302 Test du batch de requête TachoNet X
C303 Test du batch du fichier perso X ● ● ● ● ● ● ● ● ● ● ● ●
C400 Simulation temporelle de l'évolution du statut X
C401 Tester le cas retour carte X
C500 tester la validité de la mise à jour du statut carte sur une copie de la base réelle X
C600 Vérification du tarif sélectionné X ●
C601 Test de la mise à jour de la base ● X
C602 Validation des factures correspondantes X ● ● ● ●
C603 IHM, vérifier la valeur du tarif proposé par défaut X
C700 test cadre contractuel X
C701 test cadre pré-payé : chèques, mandats X X X X
C702 bordereaux : commande, par type de règlement X X X X X X
X X X X X
C703 DIC : bordereau de commande absent X X X X X
C704 validation des factures acquittées X X X X X X X
X X X X X
C705 validation des factures X X X X X
C706 IHM : tester les écrans par type de règlement X X X X X X
X X X X
C800 Validation de la mise à jour du contrat X
X X X
C801 Validation de l'expédition (regroupement, adresses) X X X
C802 IHM, tester la présence et la validité du lien LCE ● ● ● ● ● ● X ● ● ● ● X X X X

C803 courrier d'information complémentaire (porteur) X

C900 validation des restrictions du profil opérateur ● ● X
C901 validation du retour <SAISIE EN COURS> X
C902 vérifier la portée de la dé validation X
C1000 IHM : présence du motif de remplacement (proposition) X
C1001 validation du processus complet de remplacement, jusqu'à l'émission de la facture X
C1002 validation des restrictions du profil opérateur X
C1003 IHM : valider la possibilité de facturer manuellement, au niveau de la création de l'enveloppe X
C1100 IHM : valider la possibilité de facturer manuellement, et le commentaire enveloppe X
C1101 valider le flux fichier à plat facturation manuelle ET le flux facturation standard ! X
C1102 SIGD : valider le topage IMMEDIAT des éléments facturables X
C1200 Simulation temporelle et validation des tarifs appliqués (carte en remplacement) X X
9
La matrice de couverture sous Test Director
Les critères d’acceptation du livrable
MOE :
Il faut déterminer quels sont les fonctionnalités possédant des exigences rattachés qui
sont critiques et qui doivent être validées pour une mise en production.

MOA :
Il faut déterminer les process métier qui doivent obligatoirement être passés pour une
mise en production acceptée.

Exemple : la couleur du site est une exigence de criticité faible qui si elle n’est pas
validée n’empêchera pas la mise en production.
A l’inverse le module permettant le paiement en ligne de internaute doit fonctionner
pour la survie de l’entreprise.
Plan de formation

La spécification des tests – Le plan de test

La conception des tests – Cahier de test

La mise en œuvre des tests

12
La conception des tests s’inscrit dans une
démarche
Démarche de recette fonctionnelle MAP

S1 S2 S4 S5

Base de test
Reprise Organisation Préparation Exécution
Existant de recette S3 S3 Constitution
Conception Déroulement
Spécifications Stratégie Conceptio
Spécification
des jeux des tests,
Générales de test, de données
plan de test, ndes tests, Validation de
journal de
et détaillées Valorisation des test, fiches
planning l’environnement d’anomalies
scénarios

(T5) Planifier les différentes

opérations de recette
(T4) Rédiger les cahier de recette et les scénarios de test
(T3) Participer à l’installation et à la gestion des environnements de recette
(T16) Vérifier la conformité … des produits livrés
(T17) Rédiger les procédures de paramétrage
(T4) Exécuter les cahier de recette et les scénarios de test
(T14) Valider le mode opératoire de outils
(T15) Tester les manuels utilisateurs
(T16) … Qualifier les produits livrés Management de recette
Management de recette
Production
Production des indicateurs,reporting
des indicateurs, reportingvia
viatableaux
tableauxde debord
bordde
desuivi
suivi
des
destests
testsetetdes
desanomalies,
anomalies,animation
animationdedel’équipe
l’équipede
derecette,
recette,
coordination
coordination
(T11) Evaluer et faire remonter les risques
(T7) Analyser/présenter les résultats de test
sous forme de rapport standards et exhaustifs.
(T10) Assurer un contrôle continu de la qualité des tests des documents d’échange et des livrables.
(T12) Participer à toute réunion relative à la recette utilisateur et au comité de suivi du contrat
(T18) Préparer et proposer les éléments de décision GO/NOGO.

© Propriété de MAP: « Toute reproduction, même partielle, sans l’autorisation de MAP est interdite. » « sujet » - « date » 29

13
La conception se matérialise par un cahier de test

Préparation
Spécification
d ’une
des tests
campagne
Spécification,
Stratégie de tests Plan de test
Documents projet Cahier de test

Le cahier de test ne peut être démarrer sans avoir pris connaissance de la stratégie de test et le
plan de test.
Dans le cas où ce livrable n’aurait pas été établi en amont, vous devrez vous poser les mêmes
questions que si vous aviez à l’établir.
Il vous sera donc nécessaire d’élaborer une stratégie de test, ou tout au moins par un plan de test
formel.
A minima, vous devez établir une matrice de couverture afin de vous assurer que tous les éléments
sont pris en compte dans votre cahier de test et élaborer une stratégie.
Terminologie du cahier de test
Pas de test
Le pas de tests décrit une action élémentaire à réaliser et le contrôle
correspondant à effectuer (résultat attendu)
Fiche de test (ou scénario)
La fiche de test est constituée d’une description succincte du test à
effectuer, son objectif et l’ensemble des pas de test qui le constitue. Une
fiche de test peut contenir des cas de test « passants », « non passants »
ou « aux limites ».
Jeu d’essai
Un jeu d’essai représente l’ensemble des données nécessaires au déroulement
d’un test.
Cahier de test
Le cahier de test est l’ensemble des fiches de tests décrivant les tests à réaliser. Il
doit être structuré de façon à être le reflet des besoins utilisateurs (MOA et MOE).
Campagne de test
Une campagne de test est constituée d’un sous ensemble ordonné de fiches de
tests extraites du cahier de tests et de leurs jeux d’essais associés.
15
Terminologie du cahier de test

Un cas de test est une manière spécifique d’utiliser une partie d’une
fonctionnalité d’un système selon un contexte donné et ceci afin de
vérifier si le résultat obtenu correspond au résultat attendu.

Un cas de test est un couple (action, résultat attendu).

C'est sur le cas de test que s'apprécie l'écart par rapport au
référentiel.

16
Les éléments cités sous Test Director

Exigences

Anomalies

Campagnes de
Fiche de test Test
Plans de Test
Dossier ou sous-dossier
17
Les cas de tests
Les différents cas de tests fonctionnels
 Passants : permis par l’application et produisant une donnée finale

 Non passants : interdits par l’application, ne produisant pas de donnée finale

 De borne aussi appelés, « de seuil » : portant sur des actions ou plus

généralement sur des saisies dans la limite des données permises (dates,
montants... )

Objectif
Permet d’augmenter la couverture de test en démultipliant les scénarios ou les pas
de test.

En général le comportement de l’application est peu ou pas spécifié dans les cas
non-passant. Il ne faut pas hésiter à faire spécifier ces cas lors des
relectures de spécifications.

Si le qualifieur ne sait pas comment doit se comporter l’application, le développeur

ne le sait pas non plus.
18
Les cas de tests – Les questions à se poser
5 questions obligatoires à se poser :
Que veut-
veut-on tester ?
« je veux tester la fonctionnalité qui permet de… ».
Dans quel cas ?
« je veux tester la fonctionnalité qui permet de […] lorsque
l’application est dans l’état… ».
Que dois-
dois-je obtenir ?
« lorsque le système est dans cet état et que j’exécute cette
fonctionnalité, le résultat que je dois obtenir est… ».
Quel déroulement ?
« Pour exécuter complètement la fonctionnalité je dois réaliser… ».
Quelles sont les opérations préliminaires à effectuer ?
« que dois-je faire initialement pour être en situation d’exécuter cette
fonctionnalité ».

19
Les cas de tests – Niveau de maille

Niveau de maille faible

N° Action à réaliser Résultat attendu
1 Imprimer la liste des dernières L’impression est conforme à la
écritures du compte-courant. visualisation écran

Niveau de maille fort

N° Action à réaliser Résultat attendu
1 Sélectionner Compte-> Affichage de la liste des comptes
Visualisation à partir du Menu
2 Sélectionner le compte courant Affichage de la visualisation du
compte
3 Cliquer sur le bouton Imprimer Une boite de dialogue demandant la
confirmation de l’impression
apparaît
4 Confirmer l’impression - La liste des dernières
écritures du compte
s’imprime
- Une barre de progression
s’affiche à l’écran pendant
l’impression
5 Vérifier l’impression - Liste des contrôles à
effectuer
- ...
20
La fiche de test

Le libellé

Description claire et succincte permettant de comprendre le scénario en une

phrase.
Exemple : Impression de la liste des écritures du compte courant
Mauvais exemple : Compte bancaire

Le numéro
Identifiant unique permettant de référencer la fiche de test. Ce numéro peut
être composé d’un préfixe pouvant indiquer :

- Le type de test (exemple PERF, TU, RCT …)

- Le module ou le composant testé (FI, CO, IMP …)
- La référence du besoin technique ou fonctionnel testé.
La fiche de test

L’objectif de la fiche de test

Description plus détaillée de la fiche de test. Cette description permet en

quelques phrases de comprendre l’objectif du test.
Exemple : Valider l’impression de la liste des écritures du compte
courant selon la date de demande.

La liste des besoins testés

La liste des besoins testés permet de faire le lien entre les fonctions à
tester définies dans le plan de test et les tests réalisés.

La consolidation de ces informations permet de créer une matrice de

traçabilité entre les fonctions et les tests.

22
La fiche de test

L’état de la fiche de test

Cet état permet de vérifier l’état d’avancement du cahier de test.

Il peut avoir comme valeur :

- A définir
- A valider
- Prêt
- Non Applicable
-…
Les pré-requis de la fiche de test

Certains tests ne peuvent être réalisés que si certaines conditions

sont réunies.

Ces conditions peuvent être :

- Test n°=XXX, OK
- Présence d’un contrat de type …
- Service de messagerie opérationnel… 23
  Données logiques
 Données physiques Rédacteur : Nom Prénom
La fiche  Données d’exécution Responsable de l’exécution : Nom Prénom

de test Identifiant

Description / Objectif

Priorité

Identifiant du pré-requis

Description du pré-requis
Fiche de test

Dans un premier Identifiant du Description du Situation Action à Valeur Résultat Résultat Date
temps les pas de test pas de test pas de test Initiale accomplir Utilisée Attendu Obtenu d’exécution
ne sont pas
renseignés

Pas de test 24
La fiche de test sous Test Director

25
Fin de la boucle : le cahier de test

26
Plan de formation

La spécification des tests – Le plan de test

La conception des tests – Le cahier de test

La mise en œuvre des tests

27
La mise en œuvre des tests s’inscrit dans une
démarche
Démarche de recette fonctionnelle MAP

S1 S2 S4 S5

Base de test
Reprise Organisation S3 Préparation
S3 Exécution
Existant de recette Constitution Déroulement
Conception
Spécifications Stratégie Conception des jeux des tests,
Spécification
Générales de test, de données journal de
plan de test, des tests,
et détaillées Validation de test, fiches
planning Valorisation des
l’environnement d’anomalies
scénarios

(T5) Planifier les différentes

opérations de recette
(T4) Rédiger les cahier de recette et les scénarios de test
(T3) Participer à l’installation et à la gestion des environnements de recette
(T16) Vérifier la conformité … des produits livrés
(T17) Rédiger les procédures de paramétrage
(T4) Exécuter les cahier de recette et les scénarios de test
(T14) Valider le mode opératoire de outils
(T15) Tester les manuels utilisateurs
(T16) … Qualifier les produits livrés Management
Managementde derecette
recette
Production
Productiondes
desindicateurs,
indicateurs,reporting
reportingvia
viatableaux
tableauxdedebord
bordde
desuivi
suivi
des tests et des anomalies, animation de l’équipe de recette,
des tests et des anomalies, animation de l’équipe de recette,
coordination
coordination
(T11) Evaluer et faire remonter les risques
(T7) Analyser/présenter les résultats de test
sous forme de rapport standards et exhaustifs.
(T10) Assurer un contrôle continu de la qualité des tests des documents d’échange et des livrables.
(T12) Participer à toute réunion relative à la recette utilisateur et au comité de suivi du contrat
(T18) Préparer et proposer les éléments de décision GO/NOGO.

© Propriété de MAP: « Toute reproduction, même partielle, sans l’autorisation de MAP est interdite. » « sujet » - « date » 29

28
La préparation de la campagne

- S’assurer que tut ce qui est écrit dans la stratégie et le plan

de test sont en place
- Préparer les jeux de données
- Préparer les environnements

29
L’exécution de la campagne
Conformité
résultats
Exécution des obtenus/
fiches de test résultats Non
attendus ?

Oui

PV recette et Bilan Déclarations et

Application validée
de test suivi des
anomalies

Demandes de
correction des
Re-livraison de
anomalies
l’application suite
aux corrections

30
La fiche anomalie

Suivre l’état de l’anomalie Décrire l’anomalie

Fiche
d’anomalie

Référencer l’anomalie

Tracer et historiser toutes

actions sur l’anomalie
31
La fiche anomalie
Le libellé
Description claire et succincte permettant de comprendre
l’anomalie en une phrase. Commencez toujours par le code
attribué au module, la fonction, l’action puis la description
succincte de l’anomalie
Exemple : PARAM, Bilan comptable - Édition : impression erronée
Mauvais Exemples :
- impression erronée du bilan comptable
- impossible de faire les tests

Le numéro
Identifiant unique permettant de référencer l’anomalie.

La reproductibilité
Champs indiquant si le problème est reproductible de façon systématique
ou si celui-ci arrive de temps en temps.

32
La fiche anomalie
La description
Description claire et détaillée permettant de comprendre
l’anomalie et permettre de la reproduire.

Cette description doit comprendre :

- Le contexte du problème (version d’application, type de
données …)
- Le scénario de reproduction de l’anomalie
- Le résultat obtenu
- Le résultat attendu

La criticité
Champs indiquant l’importance du problème. En règle
générale une anomalie peut-être :
- Bloquante
- Majeure
- Mineure
33
La fiche anomalie
Anomalie bloquante
Une anomalie est dite bloquante ou critique si une fonction vitale
du système n’est pas opérationnelle.
Exemple : pour un système de facturation, impossible d’imprimer
les factures.

Anomalie majeure
Une anomalie est dite majeure si une fonction principale du
système n’est pas opérationnelle ou si un problème bloquant est
contournable.

Exemple : pour un système de facturation, impossible

d’imprimer les factures inférieures à 10 Euros.
Anomalie mineure
Une anomalie est dite mineure si elle n’est ni majeure ni
bloquante.
Exemple : une faute d’orthographe sur un écran de saisie 34
La fiche anomalie - Workflow

35
Le bilan de recette 1/3
Outil de formalisation de la synthèse de projets de test

 Objet : Rappel succinct du projet

 Domaine d’application ; Informations relatives à l’application testée :

- architecture
- environnement
- version

 Documents associés
Récapitulatif des différents documents d’entrée ayant servis à la conception des
tests.

 Remarques sur le déroulement des tests

Tout détail important relatif au déroulement des tests comme :
- les dates des livraisons successives
- l’utilisation d’un outil d’automatisation de test
- freins rencontrés
- etc.…
36
Le bilan de recette 2/3
 Restrictions et anomalies restantes
Récapitulatif des restrictions et anomalies restantes en fin de recette.

- une restriction est une anomalie rencontrée lors de l’exécution des tests qui ne sera pas
corrigée

- une anomalie restante est une anomalie rencontrée lors de l’exécution des tests qui fera
l’objet d’une correction ultérieure

 Etat des tests

Synthèse donnant pour chaque scénario (référence et descriptif) le nombre d’anomalies :

- critiques
- majeures
- mineures

rencontrées lors des tests ainsi que leurs références.

37
Le bilan de recette 3/3 - Exemple
1 OBJET

2 DOMAINE D'APPLICATION

3 DOCUMENTS ASSOCIES
Référence Ai/Ri Intitulé

4 REMARQUES SUR LE DEROULEMENT DES TESTS

5 Restrictions et anomalies restantes.

5.1 Restrictions

5.2 Anomalies restantes

6 ETAT DES TESTS

Ref. Scénario Etat CR. MA. MI. Commentaire

38
Le PV de recette
code signataire
PROCES-VERBAL DE RECETTE code signataire

<logo société> code signataire code signataire

<Nom du lot> code signataire code signataire
<nom des services intervenants informatique et recette>
<date>

IDENTIFICATION
Référence lot
Origine : Interne Externe : <Nom prestataire>
Type de recette : Fonctionnelle Recette provisoire
Technique Recette définitive
Exploitation

OBJET DE LA RECETTE
Décrire l’objectif de la recette du lot concerné

DESIGNATION DU LOT
Code du lot

DATE D’EXECUTION DE LA RECETTE

JJ/MM/AAAA

BILAN DE LA RECETTE

Acceptée Refusée

Acceptée avec réserve(s) Date de levée des réserves : ../../….

RESERVES ET/OU MOTIFS DE REFUS
Tests à réaliser :

Sous lot Sous lot Sous lot Sous lot Sous lot Sous lot Sous lot
<n°> <n°> <n°> <n°> <n°> <n°> <n°>
Pièces jointes :

DOCUMENT ETABLI EN xx EXEMPLAIRE(S) SOUS LA RESPONSABILITE DES SIGNATAIRES :

SIGNATAIRES
Qualité Nom Date Visa
Maîtrise d’ouvrage

Maîtrise d’oeuvre

39
Les outils du marché

b) FileAid,
c) QADirector, Track Record a) Gestion des
d) QArun, TestPartner exigences
e) QALoad

b) Extraction,
a) Caliber,
c) SilkCentral,
Base Données
d) SilkTest
e) SilkPerformer c) Gestion Plan
de test +
b) Relational Tools (Princeton) Anomalies
c) TestDirector
d) WinRunner, QTP d) Automate
e) LoadRunner fonctionnel

c) ClearQuest e) Test de
d) Rational Robot charge
e) Rational Robot
f) Gestion de
configuration
f) Continus
f) PVCS Tracker
40
40
Exemple d’un workflow Métier
CLIENT Centre de Services MAP
Applications Recueillir
Définir
Conception la stratégie
les besoins
Evolution de test

Faire
l’analyse Etablir
fonctionnelle le plan de test Workflow ‘Métier’
Responsable des tests, Expert AMOA
Cahier des charges Concevoir les
fonctionnel scénarii Responsable Outils / Intégrateur
Cahier de test utilisateur de test
utilisateur Ingénieur Test
Validation
Client
Faire Concevoir les
la conception scénarii Développement / Production
générale du SI de test Applicatif
Spécification Détaillées
Fonctionnelles et
Préparer
Conception techniques Valoriser les
préliminaire Validation l’environnement
Dossier de Scénarii de test
codage
paramétrage conception
Livraison du logiciel
Tests unitaires Exécuter
Validation les tests fonctionnels
et techniques

Anomalie Gérer des

Anomalies Evaluer
les tests fonctionnels
Validation
END et techniques
Incident
Bilan de campagne Bilan de campagne

Validation Evaluer Exécuter

PRODUCTION
Les tests utilisateur les tests utilisateur

41