QR Stratégie de test

1. Définir un cas de test.

C’est un test élémentaire qui est décrit avec une situation initiale, un
traitement et un résultat attendu qui répond à un objectif unique.

1. Définir un catalogue de test

C’est un référentiel de test dans lequel on capitalise les exigences, les cas de
test, et la couverture des exigences par les cas de test.

2. Définir un scénario de test

C’est un enchaînement d’un ensemble cohérent de cas de test permettant de

vérifier un cas d’utilisation, une fonctionnalité, …

3. Définir une campagne de test.

C’est un regroupement de scénarios de tests exécutés selon un ordre bien

défini. Elle se caractérise par un objectif de test (Tests de non- régression,
tests de performance, tests fonctionnels, …), et une durée.

4. Définir un plan de test.

C’est un regroupement de campagnes de test. 

5. Définir un test.

C’est un processus manuel ou automatique qui vise à :

- Etablir qu’un système vérifie les propriétés exigées par sa spécification.

- Détecter des différences entre les résultats engendrés par le système et
ceux qui sont attendus par la spécification.
 6. Citez les impératifs d'un cas de tests

Un test doit avoir les caractéristiques suivantes :

- Précis : chaque test doit avoir un objectif distinct et unique, comme

vérifier une fonction spécifique.
- Concis : il doit comprendre uniquement les étapes nécessaires à la
validation de son objectif.
- Cohérent : il doit entrainer les mêmes résultats à chaque itération quelle
que soit la personne qui l’a réalisé.
- Conforme : un cas de test doit être adapté à l’environnement de test avec
notamment des jeux de données appropriés.
- Traçable : un cas de test doit être lié au moins à une exigence.

7. Citez les objectifs d’une stratégie de tests.

La stratégie de tests vise à rendre l’effort de test efficace en :

- Maximisant les chances de détecter les erreurs.

- Tentant de trouver le plus d’erreurs possibles, le plus rapidement possible.
- Facilitant le diagnostic.

8. C’est quoi un plan de test ?

C’est un document rédigé séparément par les assistants MOA et MOE leur
permettant de préparer et de réaliser leurs tests d’intégration (AMOE) et de
recette (AMOA). Il comprend l’ensemble des scénarii qui englobent tous les cas
de tests possibles de l’application.

Le plan de test est rédigé en deux phases : la première juste après la validation
des SFD et avant les tests et le second après la réalisation des tests.
 Dans sa première phase, un plan de test est constitué de scénarii qui regroupent :

- L’ensemble des règles de gestion de chaque fonctionnalité, décrites dans

la SFD ou même plus,
- Des jeux de données les plus représentatives possibles des données
réelles, et
- Les résultats théoriques attendus et qui sont obtenus par calcul manuel.
Règles de gestion Echantillons de Résultat théorique
données attendu

Règle n°1
Scénario n°1

La seconde phase, vient après les tests d’intégration et de recette réalisés

respectivement par les AMOE et les AMOA, et elle correspond à :

- Compléter le plan de tests rédigé auparavant en rajoutant une colonne des

résultats pratiques obtenus.
- La comparaison des résultats théoriques et pratiques.

Règles de Echantillons Résultat Résultat

gestion de données théorique pratique
attendu obtenu

Règle n° 1
 Règle n° 2

9. Qu'est-ce qu'un bon plan de tests ?

Pour avoir un bon plan de test, ce dernier doit :

⮚ Contenir l'ensemble des cas de tests pour tester l'ensemble des

fonctionnalités de l'application. En plus, il comprend tous les scénarii et
cas de tests possibles même ceux qui ne figurent pas dans les SFD comme
la concurrence d’accès.
⮚ Respecter les règles de nommage.
⮚ L’échantillonnage de données représentatives de toutes les autres données
doit être fait soigneusement pour détecter les anomalies le plus tôt
possible.
⮚ Permettre à l’utilisateur de gagner du temps pendant les tests de non-
régression. En effet pendant la première compagne de tests, le plan de
tests est complété avec les résultats obtenus et validés qui nous serviront
de références pendant les tests de non-régression.

10.Quels sont les taches d'un consultant tests ?

⮚ Déterminer une stratégie de tests.
⮚ Définir les exigences à tester et priorisation de celles-ci
⮚ Rédaction du plan de tests
 ⮚ Mettre en place l'environnement de tests : c'est-à-dire installation de
l'application sur le serveur, choix de l'outil avec lequel on va tester et
détermination de l'échantillon de tests
⮚ Alimenter la base de données avec par exemple SQL
⮚ Lancer des campagnes de tests
⮚ Répertorier les anomalies
⮚ Suivre le workflow des anomalies
⮚ Reporting pour le chef de projet

11.Quel est le nombre de pages d’un plan de test ?

Le nombre de pages d’un plan de tests d’une fonctionnalité de l’application est

sensiblement supérieur au nombre de pages du dossier des SFD de la même
fonctionnalité. Une trentaine de pages.

12.En combien de temps on peut rédiger  le plan de test ?

La rédaction d’un plan de test prend 2 à 3 jours.

13.C’est quoi un Jeux de Données de test ?

Un ensemble de données qui contribue à vérifier une ou plusieurs étapes d’un

cas de test.

14.Comment se fait la rédaction des scénarios de test ?

On rédige un plan de test à partir des spécifications détaillées.

Un scénario de test est un ensemble de :
✔ pré requis (données, déroulement d’autres scénarios),
✔ actions et résultats attendus.

15.Comment écrire le plan de tests ?

On doit suivre les étapes suivantes :

✔ Définir les scénarios et cas de tests à partir des règles de gestion
✔ Définir les échantillons de données
 ✔ Calculer le manuel des résultats de tests

16.C’est quoi la recette ?

La recette est validée par les utilisateurs (MOA) du lot fonctionnel livré de
l’application. La recette permet la vérification de l'application si elle est
conforme aux spécifications.
Cette phase de test ne se porte pas que sur le l’application mais également sur la
documentation fournie.

17.Comment préparer un environnement de recette ?

C’est en préparant les outils, les machines à utiliser, Les échantillons à étudier
ainsi que Les logiciels et les bases de données à utiliser.

18.C’est quoi un PV recette ?

Un PV de recette est un compte rendu de la compagne des tests. Il contient la

liste des anomalies et les évolutions prises en compte, les intervenants, la
version, les anomalies corrigées avec leurs types, les évolutions prises en
comptes. Si rien n’est bloquant, la MOA décide que les conclusions sont
positives et que les fonctionnalités testées peuvent être livrées en production,
alors on signe le PV de recette.

19.Combien de page contient un PV de recette ?

Un PV de recette contient trois pages au maximum.

20.Quelle est la différence entre une évolution et un avenant ?

Une évolution est l’ajout d’une ou plusieurs règles de gestion voir une ou
plusieurs fonctionnalités. Dans le premier cas, elle est dite mineure et dans
le second cas majeur et peut faire l’objet d’un projet. Un avenant est la
modification d’une ou plusieurs règles de gestion, il est plus cher qu’une
évolution.

21.C’est quoi une anomalie ?

Une anomalie est le non-respect d’une ou plusieurs règles de gestion.

22.C’est quoi une anomalie bloquante, majeure, et mineure ?

On distingue trois types d’anomalies :

 ● Bloquante : s’il n’y a pas de moyens de la contourner
● Majeure : elle touche au fonctionnel, c’est une erreur grave
● Mineure : concerne généralement la forme

23.Quels sont les délais de traitement des anomalies ?

● Bloquante : traitement immédiat

● Majeur : dans les deux jours
● Mineurs : la correction se fait dans les cinq jours ou on peut les intégrer
dans la prochaine version s’il ne va pas tarder.

24.Les anomalies fonctionnelles sont de quel degré de sévérité ?

Elles sont souvent des anomalies bloquantes ou majeures.

25.Que signifie « reproduire une anomalie » ?

✔ A la détection elle est ouverte ;

✔ En cours si on arrive à la reproduire
✔ Rejetée si on n’arrive pas à la reproduire
✔ Vérification ou en validation
✔ Fermée ou corrigée

On reproduit une anomalie pour vérifier si c’est une anomalie ou pas ou c’est
avenant.

26.Quels sont les différents outils de gestion des anomalies ?

Quality center, excel, QTP

27.C’est quoi une évolution majeure et mineure ?

Une évolution est l’ajout d’une ou de plusieurs règles de gestion :

✔ une évolution mineure : c’est une mise à jour d’une IHM ou d’une règle
de gestion, elle concerne généralement la forme (Ajout d’un champ,
d’un bouton…)
✔ Une évolution majeure : elle fait l’objet d’un nouveau projet et que l’on
appelle un lot, remise en cause (ou ajout) l’expert métier soumis un
besoin, refaire tout le cycle du projet ou une plusieurs fonctionnalités.

28.C’est quoi le journal d’exécution ?

C’est un document texte dans lequel figure la trace de l’exécution du batch
(équivalent du log en informatique).

29.En quoi consistent les tests de recette ?

Les tests de recette consistent à refaire les tests d’intégration dans

l’environnement de recette. Ils sont réalisés par l’assistant MOA en déroulant
son propre plan de tests.

30.En quoi consistent les tests de non régression?

Les tests de non régression consistent à tester le bon fonctionnement des anciens
modules dans la nouvelle version. Ils sont réalisés à chaque fois qu’un
changement intervient que ce soit au niveau progiciel, matériel de l’application.
Ils prennent moins de temps que les tests de première compagne, utilisent les
mêmes échantillons et se basent sur les résultats théoriques du plan de tests pour
trouver les anomalies rapidement.

31.En quoi consistent les tests de pré-production ?

Les tests de pré-production consistent à installer l’environnement de

l’application sur le serveur et les postes de production et la tester par le service
production dans le but de s’y familiariser et de stabiliser l’environnement. Ils
exigent beaucoup de sang-froid et de réactivité de la part des ingénieurs de
développement.

32.Quels sont les types d’interfaces ?

Il existe deux types d’interfaces :

✔ Les Interfaces Homme Machine : Les écrans de consultation (fiche et
liste) et les écrans de mise à jour.
✔ Les interfaces entre applications : Les batchs d’extraction de données et
les batchs d’intégration de données utilisées en cas de refonte de la base
de données ou de migration de données vers une autre base.

33.Comment faire pour gagner du temps pendant les tests de non

régression ?

Pour gagner du temps pendant les tests de non régression :

✔ on s’appuie sur les résultats validés de la première campagne de tests.

 ✔ Lorsque l’application devient stable (peu d’anomalies et d’évolutions)
on automatise les tests de non régression grâce à des outils comme
QARun et WinRunner et QTP.

Par souci d’efficacité, il faut absolument que l’application soit stable sinon on
passera notre temps à réadapter le programme d’automatisation. Pour un grand
projet la stabilisation est atteinte au bout d’une à deux années. On n’automatise
que 80% à 90% de tests.

34.Est-ce que vous automatisez tous vos tests ?

On n’automatise que 80% à 90% de tests. Il existe des tests qu’on ne peut pas
automatiser tel que les tests des journaux d’exécutions qui sont différents à
chaque lancement de batch, et quand on a besoins d’un cd par exemple pour le
lancement de tests.

35.Comment tracer une anomalie détectée ?

✔ On utilise un outil de gestion d’anomalies ex : continous, test director,

bugzilla….
✔ On clique sur Nouvelle anomalie, une fiche s’ouvre avec des champs à
remplir : obligatoires en rouge et facultatifs en noir.
✔ On saisit les champs obligatoires : Résumé, Description, l’application, la
version, module, mot clé, date, l’auteur, degré (bloquante, majeure,
mineure).
✔ On enregistre, la fiche est créée avec un N°, on pourra la consulter ou la
modifier (ajouter une pièce jointe pour une copie d’écran par ex). Le cycle
vie d’une fiche (les noms se différent d’un outil à l’autre mais le principe
reste le même) est constitué par les étapes suivants :
▪ A la création : elle est à Nouveau
▪ La recette la met à l’état « Vérifié », elle est transmise au CPI
▪ Le chef de projet l’affecte aux développeurs, état « Assigné »
▪ Le développeur la corrige et il la met à l’état « Corrigé ».
▪ La recette la valide et la met à l’état « Fermé » si corrigé sinon il
l’assigne au développeur.
▪ Le dernier état c’est « clôturé ».
2 autres statuts supplémentaires :
▪ Rejetée par le développeur car elle n’est reproduite ou due à une
mauvaise utilisation.
▪ Différée pour reporter la correction ultérieurement

36.Combien d’anomalies trouvées?

300 anomalies mineures, 30majeures et 10 bloquantes.

37.C’est quoi les facteurs qualité ?

Ce sont l’expression des exigences (point de vue externe, client…)

38.C’est quoi les critères qualité ?

Ce sont les caractéristiques du produit (point de vue interne, technique).

39.C’est quoi les métriques ?

Sont ce qui permet de mesurer un critère.

40.Qu’appelle t-on une exigence ?

Une exigence de test est la description du comportement attendu ou des

contraintes à respecter par le système.

41.C’est quoi un test ?

Les tests visent à s’assurer que le système régit de la façon prévue par ses de
scénarios et cas de test.

42.C’est quoi test boite blanche / noire ?

Boite blanche : en fonction de la structure interne du programme

Boite noir : en fonction de la description externe des fonctionnalités du
programme.