Vous êtes sur la page 1sur 446

SUPPORT DE FORMATION ET PRÉPARATION À LA

CERTIFICATION

ISTQB - TESTEUR CERTIFIÉ – NIVEAU FONDATION

Version 2018
INTRODUCTION
MENTIONS LÉGALES / DROITS D'AUTEUR
Siège social : 8 rue de Choiseul 75002 Paris
OCÉANE CONSULTING
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TESTING SERVICES N° de SIREN : 45 202 56 53

N° de SIRET : 452 025 653 00042

Code APE (NAF) : 6202A

Référence Organisme :

Conformément aux lois régissant les droits de propriété littéraire et artistique ou les
COPYRIGHT : droits voisins, la reproduction et la représentation de tout ou partie des éléments
composant ce support de formation sont strictement interdites.

Cependant, sous réserve d'une demande préalable, la reproduction de certains éléments


issus du site (copies d'écran, photos, textes, etc.) peuvent être autorisées à d'autres fins.

Pour toute demande de reproduction, contactez :


formation@oceaneconsulting.com

INTRODUCTION 4
INTRODUCTION

PRÉSENTATION DE ISTQB
INTRODUCTION – PRÉSENTATION DE ISTQB
ISTQB pour « International Software Testing Qualifications Board » défini des standards et méthodes qui ont
permis de définir un programme homogène de gestion des tests au niveau international.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Un réseau de
500 000
certifiés

La Global Association for Software Quality, ou GASQ est un fournisseur international d’examens et un
leader dans le secteur de la qualité logicielle. Cette association est à ce titre responsable des certifications
ISTQB et IREB. Il met à disposition 2 documents de références :
✓ Un Syllabus : CTFL-Syllabus-2018-FR_201810
✓ Un Glossaire : Glossaire-des-tests-logiciels-v3_2F-ISTQB-CFTL-1 (ISTQB_Glossary_French_v2_0.pdf)
Il existe d’autres référentiels mais ISTQB est le seul reconnu en France par le CFTL (Comité Français du Test
Logiciel).

INTRODUCTION – PRÉSENTATION DE ISTQB 6


PRÉSENTATION DES CURSUS

PLUSIEURS EXPERTISES
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

1ère étape :
➢ ISTQB Testeur Niveau Fondation
Ensuite 3 voies sont possibles :
➢ Agile Tester
➢ Core
➢ Specialist
Avec les 3 niveaux :
▪ Fondation
▪ Avancé
▪ Expert
Pour en savoir plus / références :
https://www.gasq.org/fr/certification/istqb.html

INTRODUCTION – PRÉSENTATION DE ISTQB 77


LES OBJECTIFS DE L’ISQB ➔ CADRE GÉNÉRAL
✓ Faire reconnaître les tests comme une spécialisation essentielle et professionnelle en génie logiciel,
✓ Fournir un cadre standard pour le déroulement de carrière des testeurs,
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Permettre aux testeurs dûment qualifiés d'être reconnus par les employeurs, les clients et les pairs, et
de renforcer le professionnalisme des testeurs,
✓ Promouvoir des pratiques de test cohérentes et efficaces dans toutes les disciplines du génie logiciel,
✓ Identifier les sujets de test qui sont pertinents et de valeur pour l'industrie,
✓ Permettre aux éditeurs de logiciels d'engager des testeurs certifiés et d'obtenir ainsi un avantage
commercial par rapport à leurs concurrents en mettant en avant leur politique de recrutement de
testeurs,
✓ Offrir la possibilité aux testeurs et à ceux qui s'intéressent aux tests d'acquérir une qualification
reconnue à l'échelle internationale dans le domaine.

INTRODUCTION – PRÉSENTATION DE ISTQB 8


LES OBJECTIFS DE L’ISQB ➔ UNE PORTÉE INTERNATIONALE
✓ Pouvoir comparer les connaissances en matière de tests dans différents pays,
✓ Permettre aux testeurs de dépasser plus facilement les frontières nationales,
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Permettre aux projets multinationaux/internationaux d'avoir une compréhension commune des


questions relatives aux tests,
✓ Augmenter le nombre de testeurs qualifiés dans le monde entier,
✓ Avoir plus d'impact/valeur en tant qu'initiative internationale qu'une approche spécifique à un pays,
✓ Développer un corpus international commun de compréhension et de connaissances sur les tests par le
biais du syllabus et de la terminologie, et augmenter le niveau de connaissances sur les tests pour tous
les participants,
✓ Promouvoir le test en tant que profession dans un plus grand nombre de pays,
✓ Permettre aux testeurs d'obtenir une qualification reconnue dans leur langue maternelle,
✓ Assurer la reconnaissance internationale des testeurs et de cette qualification grâce à la participation de
nombreux pays

INTRODUCTION – PRÉSENTATION DE ISTQB 9


INTRODUCTION

Déroulé de la formation
OBJECTIFS ET NIVEAUX DE CONNAISSANCE
Classifications des niveaux de connaissance attendues dans le syllabus
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ NIVEAU 1 : SE SOUVENIR (K1)


Mots clés :
Identifier, Se souvenir, Retrouver, Rappeler, Reconnaître, Savoir

❑ NIVEAU 2 : COMPRENDRE (K2)


Mots clés :
Résumer, Généraliser, Abstraire, Classer, Comparer, Cartographier, Différencier, Illustrer,
Interpréter, Traduire, Représenter, Déduire, Conclure, Catégoriser, Construire des modèles

❑ NIVEAU 3 : APPLIQUER (K3)


Mots clés :
Implémenter, Exécuter, Utiliser, Suivre une procédure, Appliquer une procédure

INTRODUCTION – DÉROULÉ DE LA FORMATION 11


QUELQUES ÉLÉMENTS DE CONTEXTE

Tous les slides auront un titre, un contenu et un


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

titre bas de page

Le titre de bas de page fera toujours référence au


chapitre du syllabus en question

MOT-CLÉ Définition à connaître parfaitement

MOT-CLÉ Définition à connaître.

INTRODUCTION – DÉROULÉ DE LA FORMATION 12


PROGRAMME DU MODULE

1. LES FONDAMENTAUX DES TESTS


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

2. TESTER PENDANT LE CYCLE DE VIE DU DÉVELOPPEMENT LOGICIEL


3. TESTS STATIQUES
4. TECHNIQUES DE TEST
5. GESTION DES TESTS
6. OUTILS DE SUPPORT AUX TESTS

Ce cours s’appui sur le syllabus : pour faciliter le rapprochement entre les chapitres du cours et du syllabus les numéros de chapitre sont identiques.

INTRODUCTION – DÉROULÉ DE LA FORMATION 13


1. LES FONDAMENTAUX DES TESTS
SOMMAIRE

1.1 - QUE SONT LES TESTS ?


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

1.2 - POURQUOI LES TESTS SONT-ILS NÉCESSAIRES ?


1.3 - LES 7 PRINCIPES GÉNÉRAUX DES TESTS
1.4 - PROCESSUS DE TEST
1.5 - LA PSYCHOLOGIE DES TESTS

1. LES FONDAMENTAUX DES TESTS 15


1. FONDAMENTAUX DES TESTS

1.1 - QUE SONT LES TESTS ?


OBJECTIF(S) DE CONNAISSANCE
❑ FL-1.1.1
(K1) Identifier les objectifs habituels des tests
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ FL-1.1.2
(K2) Faire la différence entre tester et déboguer

1.1 QUE SONT LES TESTS ? 17


LES LOGICIELS DANS NOTRE QUOTIDIEN

Les logiciels ont pris une PLACE PRÉPONDÉRANTE dans nos activités quotidienne :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Gestion de notre compte bancaire, ✓ Internet, ✓ Véhicules motorisés,


✓ Téléphone portable, ✓ Véhicules motorisés, ✓ Commerce électronique,
✓ …
Nous avons tous un jour ou l'autre vécu une mauvaise expérience avec l'un de ces
produits de grande consommation.
Les CAUSES sont diverses et les EFFETS aussi.
L’IMPACT PEUT ÊTRE JUGÉ COMME « FAIBLE » ET AURA UNE INCIDENCE LIMITÉ :
✓ Un sèche-linge qui chauffe trop ✓ Une balance mal calibrée

L'IMPACT PEUT PARFOIS ÊTRE BIEN PLUS IMPORTANT :


✓ Entacher la réputation de l’entreprise ✓ Générer des blessures mortelles

1.1 QUE SONT LES TESTS ? 18


QU’EST-CE QUE LE TEST LOGICIEL ? (1/2)
Ensemble d'activités interdépendantes comprenant la planification des tests, le suivi
PROCESSUS DE
et le contrôle des tests, l'analyse de test, la conception des tests, l’implémentation
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TEST des tests, l'exécution des tests et la clôture des tests.

TEST Un ensemble d’un ou plusieurs cas de tests.

PERCEPTION ERRONÉE HABITUELLE DU TEST


Le test logiciel est souvent perçu uniquement comme l’exécution de tests et la
vérification des résultats. En fait ces activités ne sont qu’une partie d’un processus
qui comprend entre autres les activités de test suivantes :
✓ Planification des tests,
✓ Analyse, revue de produits d’activités,
✓ Conception et mise en œuvre des tests,
✓ suivi de la progression et des résultats des tests,
✓ évaluation de la qualité de l’objet de test…
EXÉCUTION DES Processus consistant à exécuter un test sur un composant ou système en test, en
TESTS produisant le(s) résultat(s) obtenu(s)

1.1 QUE SONT LES TESTS ? 19


QU’EST-CE QUE LE TEST LOGICIEL ? (2/2)

Confirmation par l’examen et la fourniture de preuves objectives que


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

VALIDATION les exigences, pour un usage ou une application voulue, ont été
satisfaites [ISO 9000]

PERCEPTION ERRONÉE HABITUELLE DU TEST


Le test vérifie uniquement que le système répond aux exigences, User Stories
spécifiées.
En fait il permet aussi de valider que le système répondra aux besoins des
utilisateurs et des autres parties prenantes

1.1 QUE SONT LES TESTS ? 20


OBJECTIFS HABITUELS DES TESTS (1/3)
Tester c’est :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Définir des objectifs de test

Atteindre ces objectifs et


trouver des défaillances

OBJECTIF DE TEST Une raison ou but de la conception et l’exécution d’un test

OBJET DE TEST Composant ou système à tester.

ARTICLE DE TEST Une partie d'un objet de test utilisé dans le processus de test.

1.1.1 OBJECTIFS HABITUELS DES TESTS 21


OBJECTIFS HABITUELS DES TESTS (2/3)

Valider si l'objet de test est


Évaluer les produits
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Vérifier si toutes les complet et fonctionne


d’activités : les exigences, les
exigences spécifiées ont été comme attendu par les
User Stories, la conception et
satisfaites utilisateurs et autres parties
le code
prenantes

Construire la confiance
Trouver des défaillances et
dans le niveau de qualité de Prévenir des défauts
défauts
l'objet de test

Fournir suffisamment
Se conformer aux exigences
d'information aux parties Réduire le niveau de risque
ou aux normes
prenantes pour leur d'une qualité logicielle
contractuelles, légales ou
permettre de prendre des inadéquate
réglementaires
décisions éclairées

1.1.1 OBJECTIFS HABITUELS DES TESTS 22


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

1.1.1 OBJECTIFS HABITUELS DES TESTS


Logiciel à tester
OU
Contexte projet

23
OBJECTIFS HABITUELS DES TESTS (3/3)
TEST ET DÉBOGAGE
Déboguer, cela consiste à :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Détection de défaillance
par le testeur

Recherche de la cause,
correction du défaut, test des
composants par le développeur

DÉBOGUER Processus de trouver, analyser et éliminer les causes de défaillance dans les logiciels

En développement Agile et dans d’autres cycles de vie, le testeur peut participer au débogage et aux
tests de composants

1.1.2 TEST ET DÉBOGAGE 24


1. FONDAMENTAUX DES TESTS

1.2 - POURQUOI LES TESTS SONT-ILS NÉCESSAIRES ?


OBJECTIF(S) DE CONNAISSANCE
❑ FL-1.2.1
(K2) Donner des exemples montrant la nécessité des tests
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ FL-1.2.2
(K2) Expliquer la relation entre les tests et l'assurance qualité et donner des exemples
montrant comment les tests contribuent à une amélioration de la qualité

❑ FL-1.2.3
(K2) Faire la différence entre erreur, défaut et défaillance

❑ FL-1.2.4
(K2) Faire la différence entre la cause racine d'un défaut et ses effets

1.2 POURQUOI LES TESTS SONT-ILS NÉCESSAIRES ? 26


ÉVOLUTION DU TEST
DÉMONSTRATION DÉTECTION PRÉVENTION ADAPTATION
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Montrer que ça Trouver tous les


Manager la qualité Optimiser
fonctionne défauts

ANNÉES 70 ANNÉES 80 ANNÉES 90 DEPUIS 2000

S'assurer d'une Modèles de


utilisation avec un risque Découvrir des défauts Détecter les défauts plus développement (Agile,
acceptable tôt DevOps…)

Essayer les fonctions aux Mesurer les limites et les Techniques de test (TDD,
limites performances BDD…)
Identifier les risques et
les solutions pour les Révolution
Vérifier que le produit Fournir une image de
éviter technologique (Web,
est complet et prêt qualité du produit
IoT, Cloud)

1.2 POURQUOI LES TESTS SONT-ILS NÉCESSAIRES ? 27


ORIGINE DES DÉFAUTS LOGICIEL
Un défaut logiciel peut avoir différentes origines :
✓ Erreur humaine (développeur, analyste)
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Conditions d'environnement (radiation, magnétisme, pollution…)


DÉFAUT
Une imperfection ou une déficience d'un produit d’activités lorsqu'il ne répond pas à
OU BOGUE / BUG ses exigences ou à ses spécifications [IEEE 1044].
OU FAUTE

L'erreur humaine arrive souvent à cause des contraintes :


✓ De délai (échéancier court),
✓ De complexité de l'architecture logicielle,
✓ De la forte évolutivité technologique,
✓ De la taille des systèmes de plus en plus communicants
ERREUR
Action humaine produisant un résultat incorrect [ISO 24765].
OU CONFUSION

1.2 POURQUOI LES TESTS SONT-ILS NÉCESSAIRES ? 28


CONSÉQUENCES DES DÉFAUTS LOGICIEL

Les conséquences du mauvais fonctionnement d'un logiciel peuvent être de


différentes natures :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Perte financière,
✓ Perte de temps,
✓ Perte de réputation,
✓ Perte humaine,
✓ …

Les défauts entraînent le plus souvent des défaillances mais pas


systématiquement.

Événement dans lequel un composant ou un système n'exécute pas une


DÉFAILLANCE fonction requise dans les limites spécifiées [ISO 24765].

1.2 POURQUOI LES TESTS SONT-ILS NÉCESSAIRES ? 29


CAUSES ET EFFET
Ariane en 1996 :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

CAUSES EFFET /
IMPACTS
INITIALES CONSÉQUENCE

Réutilisation
d'une
spécification
Ariane 4 non
valide pour Overflow durant
Ariane 5 l'exécution d'une
conversion de
données de 64-bits Explosion en vol
Instructions ADA (nombre flottant) à
d'Ariane 5
de conversion 16-bits (entier
non protégées signé) sur les
systèmes de
pilotage

Tests insuffisants

1.2 POURQUOI LES TESTS SONT-ILS NÉCESSAIRES ? 30


EXEMPLE ET PERTES HUMAINES
Entre 1985 et 1987, LE THERAC-25, une machine de radiothérapie, fut impliquée dans au
moins six accidents durant lesquels des patients reçurent des doses massives de radiation,
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

parfois de l'ordre de plusieurs centaines de grays.

AU MOINS CINQ PATIENTS DÉCÉDÈRENT DES SUITES DE L'IRRADIATION.

La cause directe du dysfonctionnement était d'ordre informatique.

La machine est depuis souvent citée dans les documents qui traitent de la sécurité et de la
validité des logiciels destinés à des applications sensibles où la vie peut être mise en
danger.

1.2 POURQUOI LES TESTS SONT-ILS NÉCESSAIRES ? 31


EXEMPLES MÉDIATISÉS
• 1994 : Bug industriel lié au calcul avec virgule flottante sur le processeur Intel de première
génération.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

➢ CONSÉQUENCE : PERTE DE RÉPUTATION INTEL AU PROFIT D'IBM, colère des clients de l'industrie,
baisse des volumes de vente.
• Bug de l’an 2000 [Y2K] : Problématique de standard de format de date, 1999 codé « 99 » l'an
2000 aurait été codé 00. (A venir bug 2038 C)
➢ CONSÉQUENCE : BUDGET ÉNORME DÉPENSÉ EN 1999. L'ENSEMBLE DES CONSTRUCTEURS AYANT ATTENDU
LE DERNIER MOMENT POUR RÉAGIR. Aucun compromis n'avait été trouvé avant pour traiter le
problème.
• 1998 : Perte de puissance de freinage sur les véhicules Nissan Pickup.
➢ CONSÉQUENCE : BUDGET ÉNORME DÉPENSÉ, rappel de 179 000 véhicules pour réparation.
• Depuis 2005 : divers problèmes sur les limiteurs de vitesse.
➢ CONSÉQUENCE : ACCIDENTS DE PERSONNES

1.2 POURQUOI LES TESTS SONT-ILS NÉCESSAIRES ? 32


CONTRIBUTION DES TESTS AU SUCCÈS (1/6)

Cycle de vie de développement logiciel


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Spécifications, Exigences
Système contractuelles,
documentation Composant Production
Release légales,
Back Log réglementaires

 Techniques de test appropriées,


❖ Qualité logicielle accrue
 Niveaux d’expertise appropriés,
 Niveaux de test appropriés, ❖ Risques de défaillances réduits
 Aux moments appropriés ❖ Parties prenantes satisfaites

1.2.1 CONTRIBUTION DES TESTS AU SUCCÈS 33


CONTRIBUTION DES TESTS AU SUCCÈS (2/6)
Exemples d’activités de test appropriées
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

ACTIVITÉS DE TEST BÉNÉFICES

❖ Testeurs participent ❖ Détecter des défauts dans ces produits d’activité


➢ Aux revues des exigences ❖ Réduit le risque de développement de
➢ Au raffinement des User Stories fonctionnalités incorrectes

1.2.1 CONTRIBUTION DES TESTS AU SUCCÈS 34


CONTRIBUTION DES TESTS AU SUCCÈS (3/6)
Exemples d’activités de test appropriées
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

ACTIVITÉS DE TEST BÉNÉFICES

❖ Testeurs travaillent ❖ Meilleure compréhension de la conception et


➢ En collaboration avec les concepteurs du comment la tester
système ➢ Réduire le risque de défauts dans la conception
➢ Pendant la conception du système ➢ Identifier les tests en amont

1.2.1 CONTRIBUTION DES TESTS AU SUCCÈS 35


CONTRIBUTION DES TESTS AU SUCCÈS (4/6)
Exemples d’activités de test appropriées
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

ACTIVITÉS DE TEST BÉNÉFICES

❖ Testeurs ❖ Détecter des défaillances


➢ Vérifient et valident le logiciel avant sa mise en
production ❖ Aide au processus d’élimination des défauts à
l’origine des défaillances

➢ Probabilité accrue de satisfaire les parties


prenantes et les exigences

1.2.1 CONTRIBUTION DES TESTS AU SUCCÈS 36


CONTRIBUTION DES TESTS AU SUCCÈS (5/6)
Exemples d’activités de test appropriées
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

ACTIVITÉS DE TEST BÉNÉFICES

❖ Représentants des parties prenantes ❖ Garantir la conformité du logiciel dans ses


➢ Valident les exigences contractuelles contextes d’utilisation
❖ Experts métier ➢ Probabilité accrue de satisfaire toutes les parties
prenantes
➢ Valident les exigences réglementaires

1.2.1 CONTRIBUTION DES TESTS AU SUCCÈS 37


CONTRIBUTION DES TESTS AU SUCCÈS (6/6)
Exemples d’activités de test appropriées
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

ACTIVITÉS DE TEST BÉNÉFICES

❖ La maintenance ❖ Réduit le risque de générer de nouvelles


➢ Effectue des tests de régression automatisés à défaillances dans les composants non modifiés
chaque changement du logiciel ou de ❖ Réduit le risque de dégrader certaines
l’environnement caractéristiques non-fonctionnelles comme la
➢ Utilise des outils de monitoring performance

1.2.1 CONTRIBUTION DES TESTS AU SUCCÈS 38


ASSURANCE QUALITÉ ET TEST (1/3)
Degré par lequel un composant, système ou processus atteint des exigences
QUALITÉ spécifiées et/ou des besoins ou attentes des clients ou utilisateurs [ISO 24765]
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Activités coordonnées pour diriger et contrôler une organisation en ce qui


concerne la qualité. La direction et le contrôle de la qualité incluent
GESTION DE LA QUALITÉ généralement la mise en place de recommandations et d’objectifs qualité,
de la planification qualité, du contrôle qualité, de l’assurance qualité et de
l’amélioration qualité.

Gestion de la Qualité

Assurance Qualité Contrôle Qualité Objectifs Qualité Planification Qualité Amélioration Qualité

1.2.2 – ASSURANCE QUALITÉ ET TEST 39


ASSURANCE QUALITÉ ET TEST (2/3)

Gestion de la Qualité
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Assurance Qualité Contrôle Qualité

ASSURANCE Partie de la gestion de la qualité visant à fournir l’assurance que les exigences qualité
QUALITÉ seront atteintes [ISO 9000].

CONTRÔLE Les activités et les techniques opérationnelles de la gestion de la qualité axées sur
QUALITÉ l'atteinte des exigences qualité [ISO 8402].

1.2.2 – ASSURANCE QUALITÉ ET TEST 40


ASSURANCE QUALITÉ ET TEST (3/3)
ASSURANCE QUALITÉ (QA) ≠ TESTS
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

ASSURANCE QUALITÉ CONTRÔLE QUALITÉ


Respect processus adéquats

Tests
Analyse causes racines des défauts ✓ Vérification
✓ Validation

Produits d’activités
de meilleure qualité Organisation
Rétrospectives
Communication

1.2.2 – ASSURANCE QUALITÉ ET TEST 41


ERREURS, DÉFAUTS ET DÉFAILLANCES (1/4)
Exemple : Une condition pour un distributeur de billet stipule qu'on ne peut pas retirer
PLUS de 200 €.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

1.2.3 - ERREURS, DÉFAUTS ET DÉFAILLANCES 42


ERREURS, DÉFAUTS ET DÉFAILLANCES (2/4)
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

SPÉCIFICATIONS
EXIGENCES MÉTIER CODE SYSTÈME
FONCTIONNELLES

ERREUR DÉFAUT DÉFAUT DÉFAILLANCE

DÉFAUT DÉFAUT

DÉFAUT

ERREUR DÉFAUT DÉFAUT DÉFAILLANCE

1.2.3 - ERREURS, DÉFAUTS ET DÉFAILLANCES 43


ERREURS, DÉFAUTS ET DÉFAILLANCES (3/4)
ORIGINE DES ERREURS :
✓ Contraintes de temps
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Fiabilité humaine,
✓ Inexpérience ou incompétence,
✓ Mauvaise communication,
✓ Complexité des exigences, de la conception, du code,
✓ Technologies utilisées,
✓ Les malentendus sur les interfaces intra-système et inter-système,
✓ …
Les défaillances peuvent aussi être déclenchées par des conditions
environnementales pour les logiciels à bas niveau (firmware) et/ou
pour les logiciels embarqués (changement conditions matérielles) :
rayonnement, champs électromagnétiques, pollution…

1.2.3 - ERREURS, DÉFAUTS ET DÉFAILLANCES 44


ERREURS, DÉFAUTS ET DÉFAILLANCES (4/4)

Faux Positifs Faux Négatifs


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

• Une défaillance est constatée mais le • Une défaillance n’est pas constatée
logiciel n’est pas en cause : l’origine alors qu’elle aurait dû l’être,
peut provenir d’une erreur dans la également à cause des mêmes erreurs
façon dont les tests ont été exécutés (mauvaise manipulation, testware
(par exemple le testeur a sauté une incorrect, etc.)
étape), ou des données de tests mal
enregistrées, ou d’une mauvaise
configuration de l’environnement de
test, ou de tout autre testware.

1.2.3 - ERREURS, DÉFAUTS ET DÉFAILLANCES 45


DÉFAUTS, CAUSES RACINES ET EFFETS
Une source de défaut telle que si elle est retirée, l’apparition de ce type de défaut
CAUSE RACINE est diminuée ou supprimée [CMMI].
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Exemple : les clients d’un site de e-commerce ne reçoivent pas leurs articles lorsqu’ils spécifient une
adresse de livraison spécifique (différente du domicile).

➢ CAUSE RACINE : l’analyste fonctionnel manque de compétences en UML


➢ ERREUR : pour rédiger la spécification fonctionnelle, l’analyste fonctionnel a mal interprété un
diagrammes UML du cahier des charges (cas d’utilisation).
➢ DÉFAUT : la règle de gestion de la spécification fonctionnelle est erronée, et par conséquent le
programme qui détermine l’adresse de livraison est incorrect.
➢ DÉFAILLANCE : l’adresse de livraison restituée par le logiciel est incorrecte pour certains clients.
➢ EFFET : les clients sont mécontents de devoir récupérer leur colis à la mauvaise adresse.
Pour éviter l’apparition d’un tel défaut, il faudrait agir sur la cause racine en formant l’analyste fonctionnel
sur les diagrammes UML par exemple.

1.2.4 - DÉFAUTS, CAUSES RACINES ET EFFETS 46


1. FONDAMENTAUX DES TESTS

1.3 - 7 PRINCIPES SUR LES TESTS


OBJECTIF(S) DE CONNAISSANCE
❑ FL-1.3.1
(K2) Expliquer les 7 principes généraux des tests
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

1.3 – 7 PRINCIPES SUR LES TESTS 48


LES 7 PRINCIPES SUR LES TESTS

PRINCIPE N°1 Les tests montrent la présence de défauts, pas leur absence
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

PRINCIPE N°2 Les tests exhaustifs sont impossibles

PRINCIPE N°3 Tester tôt économise du temps et de l’argent

PRINCIPE N°4 Regroupement des défauts

PRINCIPE N°5 Paradoxe du pesticide

PRINCIPE N°6 Les tests dépendent du contexte

PRINCIPE N°7 L’absence d’erreurs est une illusion

1.3 – 7 PRINCIPES SUR LES TESTS 49


LES 7 PRINCIPES SUR LES TESTS – PRINCIPE N°1
PRINCIPE N°1 Les tests montrent la présence de défauts, pas leur absence
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

LES TESTS PEUVENT PROUVER LA PRÉSENCE DE DÉFAUTS,


MAIS NE PEUVENT PAS EN PROUVER L'ABSENCE.

Les tests ont un objectif qui peut dépendre du niveau de couverture, de la typologie des
tests, des contraintes de planning…
➢ SI L'OBJECTIF EST ATTEINT : cela veut dire que la probabilité de ne pas avoir détecté tous
les défauts est faible, mais pas nulle.
Si des défauts sont découverts par la suite, il faut enrichir la base de tests.
➢ SI L'OBJECTIF N'EST PAS ATTEINT : la probabilité qu'il reste des défauts non détectés est
importante.

1.3 – 7 PRINCIPES SUR LES TESTS 50


LES 7 PRINCIPES SUR LES TESTS – PRINCIPE N°2
PRINCIPE N°2 Les tests exhaustifs sont impossibles
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

PLUTÔT QUE DE TENTER DE CIBLER DES TESTS EXHAUSTIFS,


IL FAUT UTILISER L'ANALYSE DES RISQUES ET LE CALCUL D'IMPACT
POUR FOCALISER LES EFFORTS DE TESTS

Tout tester (toutes les combinaisons d'entrées et de pré-conditions) n'est pas faisable sauf
pour des cas triviaux.
➢ EXÉCUTER TOUS LES CAS DE TEST POSSIBLES ➔ TRÈS DIFFICILE : Parcourir tous les chemins est
souvent trop long.
➢ EXHAUSTIVITÉ DES JEUX DE DONNÉES ➔ IMPOSSIBLE : Trop de valeurs, combinaisons infinies.
➢ TESTER DANS TOUS LES ENVIRONNEMENTS ➔ TRÈS DIFFICILE VOIR IMPOSSIBLE : Nombreuses
configurations différentes : Poste client, version de l'OS, langue, type de navigateur,
version du navigateur…

1.3 – 7 PRINCIPES SUR LES TESTS 51


LES 7 PRINCIPES SUR LES TESTS – PRINCIPE N°3 (1/2)

PRINCIPE N°3 Tester tôt économise du temps et de l’argent


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

LES TESTS DOIVENT COMMENCER LE PLUS TÔT POSSIBLE PAR RAPPORT AU DÉMARRAGE DU CYCLE DE
DÉVELOPPEMENT

➢ TESTS STATIQUES :
✓ Pendant la rédaction des spécifications ou le raffinement des user stories : revues pour
détecter les manques, ambiguïtés et contradictions,
✓ Pendant la conception : revues pour valider les documents d'architecture et les documents
de conception,
✓ Pendant la réalisation : revues de code,
➢ TESTS DYNAMIQUES :
✓ Pendant l'intégration : validation des interfaces ; principe de l’intégration continue,
✓ Et bien entendu lors des tests système et d'acceptation.

1.3 – 7 PRINCIPES SUR LES TESTS 52


LES 7 PRINCIPES SUR LES TESTS – PRINCIPE N°3 (2/2)

PRINCIPE N°3 Tester tôt économise du temps et de l’argent


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

➢ Plus un défaut est découvert tard dans le cycle de vie logiciel, plus la correction est
COÛTEUSE.
➢ Un défaut de spécification découvert lors de la maintenance logicielle coûte 100 FOIS
PLUS CHÈRE que si elle avait été découverte lors d'une revue de spécification.

LE FAIT DE TESTER TÔT EST PARFOIS APPELÉ « SHIFT LEFT ».

1.3 – 7 PRINCIPES SUR LES TESTS 53


LES 7 PRINCIPES SUR LES TESTS – PRINCIPE N°4 (1/2)

PRINCIPE N°4 Regroupement des défauts


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Généralement, la majorité des défauts se situent dans un petit nombre de modules :


➢ MODULES LES PLUS COMPLEXES :
✓ Complexité du code : algorithmique, cyclomatique...
✓ Complexité métier : spécifications difficiles à comprendre, ou mal rédigées.
➢ MODULES DÉVELOPPÉS DANS UNE CERTAINE TECHNOLOGIE :
✓ Nouveau langage / IDE mal maîtrisé, manque d'expérience,
✓ Techniques de langage objet, temps réel, code embarqué.

1.3 – 7 PRINCIPES SUR LES TESTS 54


LES 7 PRINCIPES SUR LES TESTS – PRINCIPE N°4 (2/2)
PRINCIPE N°4 Regroupement des défauts
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

➢ MODULES CONÇUS PAR CERTAINS DÉVELOPPEURS


✓ Compétence du développeur, peu d'expérience…
➢ MATURITÉ DES MODULES
✓ Nouveau module : beaucoup de défauts lors des premières livraisons,
✓ Module ancien : code instable, perte de compétences, pas de documentation.

DES REGROUPEMENTS PRÉVISIBLES DE DÉFAUTS, OU DES REGROUPEMENTS RÉELLEMENT OBSERVÉS EN


TEST OU EN EXPLOITATION, CONSTITUENT UN ÉLÉMENT IMPORTANT DE L'ANALYSE DES RISQUES UTILISÉE
POUR CIBLER L'EFFORT DE TEST

1.3 – 7 PRINCIPES SUR LES TESTS 55


LES 7 PRINCIPES SUR LES TESTS – PRINCIPE N°5
PRINCIPE N°5 Paradoxe du pesticide
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Si les mêmes tests sont répétés de nombreuses fois, le nombre de nouveaux défauts
détectés diminuera : c'est le « PARADOXE DU PESTICIDE ».
➢ LA PERTINENCE DES TESTS DIMINUE AU FIL DU TEMPS :
✓ Une fois que les défaut détectés par les tests sont corrigés, ces mêmes tests ne
détecteront plus ou peu de nouveaux défauts,
✓ Si le code ou l’environnement ne change pas, pas de nouveau défaut identifié.
➢ NÉCESSITÉ DE FAIRE ÉVOLUER LES TESTS ET/OU DE CONCEVOIR DE NOUVEAUX TESTS :
✓ Nouveau(x) type(s) de tests,
✓ Evolution du jeu de données : nouvelles partitions, valeurs limites, pool de
données, données aléatoires.

1.3 – 7 PRINCIPES SUR LES TESTS 56


LES 7 PRINCIPES SUR LES TESTS – PRINCIPE N°6 (1/2)
PRINCIPE N°6 Les tests dépendent du contexte
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Les tests seront effectués différemment dans des contextes différents.


Le nombre et le type des tests vont varier dans les cas suivants :
➢ LOGICIEL BUREAUTIQUE
✓ Souvent « Logiciel sur l’étagère », peu critique
➢ LOGICIEL EMBARQUÉ
✓ Appareil électronique : Smartphone, Autoradio,
✓ Organe de sécurité : ABS / ESP, Régulateur de vitesse.
➢ LOGICIEL EMBARQUÉ CRITIQUE
✓ Pilote automatique d'un avion,
✓ Appareil médical.

1.3 – 7 PRINCIPES SUR LES TESTS 57


LES 7 PRINCIPES SUR LES TESTS – PRINCIPE N°6 (2/2)
PRINCIPE N°6 Les tests dépendent du contexte
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Les tests seront effectués différemment dans des contextes différents.


Le nombre et le type des tests vont varier dans les cas suivants :
➢ LOGICIEL DE GESTION
✓ Critique ➔ Exemple : Gestion des données bancaires des clients, ERP,
Site d'achat en ligne,
✓ Peu critique ➔ Exemple : Intranet du CE, Gestion des absences.
➢ MODÈLE DE CYCLE DE VIE DE DÉVELOPPEMENT LOGICIEL :
✓ Le test dans un projet Agile est effectué différemment dans un projet à cycle de
vie séquentiel.

1.3 – 7 PRINCIPES SUR LES TESTS 58


LES 7 PRINCIPES SUR LES TESTS – PRINCIPE N°7
PRINCIPE N°7 L’absence d’erreurs est une illusion
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Les défauts détectés (ou non), et le résultat des tests sont pertinents si les objectifs de
test sont bien définis.
1. De façon illusoire, l’organisation peut s’attendre à ce que les testeurs effectuent tous
les tests possibles et qu’ils trouvent tous les défauts possibles (contradictoire avec les
principes 1 et 2).
2. Malgré un système qui est conforme aux spécifications, il ne répond pas aux vraies
attentes des utilisateurs, il est inutilisable dans l’environnement réel ou il est moins
performant que d’autres systèmes concurrents
3. L’absence de défauts peut s’expliquer par des activités de test inefficaces :
✓ Mauvaise qualité de conception des tests,
✓ Jeux de données non pertinents,
✓ Environnement non représentatif…

1.3 – 7 PRINCIPES SUR LES TESTS 59


1 - FONDAMENTAUX DES TESTS

1.4 – PROCESSUS DE TEST


OBJECTIF(S) DE CONNAISSANCE
❑ FL-1.4.1
(K2) Expliquer l'impact du contexte sur le processus de test
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ FL-1.4.2
(K2) Décrire les activités de test et les tâches associées, au sein du processus de test

❑ FL-1.4.3
(K2) Faire la différence entre les produits d'activités qui contribuent au processus de test

❑ FL-1.4.4
(K2) Expliquer les bénéfices apportés par le maintien de la traçabilité entre les bases de test et
les produits d'activités du test

1.4 – PROCESSUS DE TEST 61


PROCESSUS DE TEST - INTRODUCTION
Le test est une ACTIVITÉ FONDAMENTALE du projet.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

C'est un métier qui s'adresse à des PROFESSIONNELS.


Le test est un projet à part entière et nécessite donc :
✓ Des moyens,
✓ Un planning,
✓ Des objectifs.
Le test doit s'appuyer sur :
✓ Des experts,
✓ Une méthode,
✓ Des outils,
✓ Des activités.

1.4 – PROCESSUS DE TEST 62


DESCRIPTION GÉNÉRALE D’UN PROCESSUS

Description d’un processus (s’applique également au test)


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

MISSION
CONTRAINTES

ACTIVITÉS DE
ENTRÉES TRANSFORMATIONS PRODUITS

Ressources RESSOURCES Méthodes


humaines Outils
Procédés

ENVIRONNEMENT

1.4 – PROCESSUS DE TEST 63


PROCESSUS DE TEST - DÉFINITION
Pas d’unique processus de test logiciel universel,
✓ Mais un ensemble commun d'activités de test = PROCESSUS DE TEST.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

La STRATÉGIE DE TEST D'UNE ORGANISATION précise :


✓ Quelles activités de test sont impliquées dans ce processus,
✓ Comment ces activités sont mises en œuvre,
✓ Quand ces activités doivent être réalisées.

Produits d’activités réalisés au cours du processus de test pour la planification, la


TESTWARE conception, l'exécution, l'évaluation et l'établissement de rapports sur les tests [ISO
29119].

1.4 – PROCESSUS DE TEST 64


LE PROCESSUS DE TEST DANS LE CONTEXTE (1/2)
FACTEURS CONTEXTUELS qui influencent le processus de test d'une organisation :
✓ Le modèle de cycle de vie du développement logiciel et les méthodologies de
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

projet utilisées
✓ Les niveaux de test et types de test prévus
✓ Les risques liés aux produits et aux projets
✓ Le domaine d'activité
✓ Les contraintes opérationnelles (budget, délai, ressources…)
✓ Les politiques et pratiques organisationnelles
✓ Les normes internes et externes requises

1.4.1 – LE PROCESSUS DE TEST DANS LE CONTEXTE 65


LE PROCESSUS DE TEST DANS LE CONTEXTE (2/2)

Le degré, exprimé en pourcentage, selon lequel un élément de


COUVERTURE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

couverture spécifié a été exécuté lors d’une suite de test [ISO 29119]

KPI

BASE DE TEST OBJECTIFS DES TESTS

Il est très utile que les bases de test aient des CRITÈRES DE COUVERTURE mesurables définis,
qui peuvent servir efficacement d'indicateurs clés de performance (KPI) pour guider les
activités qui démontrent l'atteinte des objectifs des tests logiciels.

1.4.1 – LE PROCESSUS DE TEST DANS LE CONTEXTE 66


ACTIVITÉS ET TÂCHES DE TEST
Un processus de test se compose des principaux GROUPES D'ACTIVITÉS suivants :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

1. Planification des tests


2. Pilotage et contrôle des tests
3. Analyse de test
4. Conception des tests
5. Implémentation des tests
6. Exécution des tests
7. Clôture des tests.

CALENDRIER D’EXÉCUTION DES TESTS Un ordonnancement de l'exécution des suites de tests au sein d'un
OU PLANNING D’EXÉCUTION DES TESTS cycle de test.

1.4.2 – ACTIVITÉS ET TÂCHES DE TEST 67


1. LA PLANIFICATION DES TESTS

La PLANIFICATION DES TESTS implique de définir dans le plan de test :


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

PLANIFICATION DE TEST Activité de définition ou de mise à jour d’un plan de test

Documentation décrivant les objectifs de test à atteindre et les moyens et le


PLAN DE TEST calendrier pour les atteindre, organisée pour coordonner les activités de test
[ISO 29119]

L’APPROCHE RETENUE
OBJECTIFS DES TESTS pour atteindre ces objectifs

CONTRAINTES Cf. 5.2

1.4.2 – ACTIVITÉS ET TÂCHES DE TEST 68


2. PILOTAGE DES TESTS ET CONTRÔLE DES TESTS

Le PILOTAGE DES TESTS est une activité continue de comparaison de l'avancement actuel par
rapport à ce qui a été planifié dans le plan de test.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Comment ?
✓ A l’aide de MÉTRIQUES DE PILOTAGE définies dans le plan de test

Une activité de gestion des tests qui comprend la vérification de l'état des activités
PILOTAGE DES
de test, l'identification de tout écart par rapport à l'état planifié ou attendu, et le
TESTS reporting aux parties prenantes.

Une tâche de gestion des tests qui traite du développement et de l’application d’un
CONTRÔLE DES
ensemble d’actions correctives pour remettre un projet de test sur les rails quand les
TESTS métriques de suivi indiquent une déviation par rapport à ce qui a été prévu.

Cf. 5.3

1.4.2 – ACTIVITÉS ET TÂCHES DE TEST 69


3. ANALYSE DE TEST (1/3)
Les bases de test sont analysées pour identifier les CARACTÉRISTIQUES TESTABLES et définir les
CONDITIONS DE TEST associées.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Quoi tester

ANALYSER LES BASES DE TEST APPROPRIÉES AU NIVEAU DE TEST CONSIDÉRÉ

• Rapports d’analyse des risques


• Spécifications des exigences
• Informations sur la conception et l’implémentation
• Implémentation du composant ou du système

EVALUER LES BASES DE TEST ET LES ÉLÉMENTS DE TEST POUR IDENTIFIER DES DÉFAUTS

• Ambiguïtés, omissions, incohérences, inexactitudes, contradictions, déclarations


superflues
• Valider si les exigences capturent correctement les besoins des clients, utilisateurs et des
autres parties prenantes

1.4.2 – ACTIVITÉS ET TÂCHES DE TEST 70


3. ANALYSE DE TEST (2/3)
IDENTIFIER LES CARACTÉRISTIQUES ET LES ENSEMBLES DE CARACTÉRISTIQUES À TESTER
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

• Fonctionnelles
• Non-fonctionnelles : fiabilité, utilisabilité, rendement, maintenabilité, portabilité

DÉFINIR ET PRIORISER LES CONDITIONS DE TEST POUR CHAQUE CARACTÉRISTIQUE


Selon
• l'analyse des bases de test,
• les caractéristiques fonctionnelles, non-fonctionnelles et structurelles,
• des autres facteurs métier et techniques, et des niveaux de risque

CAPTURER LA TRAÇABILITÉ BIDIRECTIONNELLE ENTRE CHAQUE ÉLÉMENT DES BASES DE TEST ET LES
CONDITIONS DE TEST ASSOCIÉES

La mesure dans laquelle une relation peut être établie entre deux ou plusieurs
TRAÇABILITÉ produits d’activités [ISO 19506]

1.4.2 – ACTIVITÉS ET TÂCHES DE TEST 71


3. ANALYSE DE TEST (3/3)

ANALYSE DE TEST L'activité qui identifie les conditions de test en analysant les bases de test.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

L'ensemble des connaissances utilisées comme base pour l'analyse et la


BASE DE TEST conception des tests [Tmap].

CONDITION DE TEST
Un aspect des bases de test qui est pertinent pour atteindre des objectifs de
OU EXIGENCE DE TEST test spécifiques.
OU SITUATION DE TEST

Un ensemble de conditions préalables, de données d'entrée, d'actions (le cas


CAS DE TEST échéant), de résultats attendus et de postconditions, élaboré sur la base des
conditions de test [ISO 29119]

1.4.2 – ACTIVITÉS ET TÂCHES DE TEST 72


4. CONCEPTION DES TESTS
Les conditions de test sont déclinées en cas de test de haut niveau, en ensembles de cas de tests de haut niveau
et autres testware.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Comment tester

CONCEVOIR ET PRIORISER LES CAS DE TEST ET LES ENSEMBLES DE CAS DE TEST

IDENTIFIER LES DONNÉES DE TEST NÉCESSAIRES POUR LES CONDITIONS DE TEST ET LES CAS DE TEST

CONCEVOIR L'ENVIRONNEMENT DE TEST ET IDENTIFIER L'INFRASTRUCTURE ET LES OUTILS NÉCESSAIRES

ETABLIR LA TRAÇABILITÉ BIDIRECTIONNELLE ENTRE LES BASES DE TEST, LES CONDITIONS DE TEST, LES CAS DE
TEST ET LES PROCÉDURES DE TEST

1.4.2 – ACTIVITÉS ET TÂCHES DE TEST 73


5. IMPLÉMENTATION DES TESTS (1/2)
Le testware nécessaire à l'exécution des tests est créé et/ou complété, y compris l'ordonnancement des cas de
test en procédures de test.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Est-ce que tout est en place pour exécuter les tests ?

DÉVELOPPER ET PRIORISER LES PROCÉDURES DE TEST, ET, ÉVENTUELLEMENT, CRÉER DES SCRIPTS DE TEST AUTOMATISÉS

CRÉER DES SUITES DE TESTS À PARTIR DES PROCÉDURES DE TEST ET, LE CAS ÉCHÉANT, DES SCRIPTS DE TESTS AUTOMATISÉS

POSITIONNER LES SUITES DE TESTS DANS UN CALENDRIER D'EXÉCUTION DES TESTS DE MANIÈRE À OBTENIR UNE EXÉCUTION EFFICACE
DES TESTS

CONSTRUIRE L'ENVIRONNEMENT DE TEST ET VÉRIFIER QUE TOUT LE NÉCESSAIRE A ÉTÉ CORRECTEMENT MIS EN PLACE

PRÉPARER LES DONNÉES DE TEST ET S'ASSURER QU'ELLES SONT CORRECTEMENT CHARGÉES DANS L'ENVIRONNEMENT DE TEST

VÉRIFIER ET METTRE À JOUR LA TRAÇABILITÉ BIDIRECTIONNELLE ENTRE LES BASES DE TEST, LES CONDITIONS DE TEST, LES CAS DE TEST,
LES PROCÉDURES DE TEST ET LES SUITES DE TESTS

1.4.2 – ACTIVITÉS ET TÂCHES DE TEST 74


5. IMPLÉMENTATION DES TESTS (2/2)

IMPLÉMENTATION DES L'activité qui prépare le testware nécessaire à l'exécution des tests sur la base
TESTS de l'analyse et de la conception des tests.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Données créées ou sélectionnées pour satisfaire les préconditions d'exécution


DONNÉES DE TEST et les entrées pour exécuter un ou plusieurs cas de test [ISO 29119]
Une séquence de cas de test dans l'ordre d'exécution, et toutes les actions
PROCÉDURE DE TEST associées qui peuvent être nécessaires pour mettre en place les préconditions
initiales et toutes les activités de bouclage après l'exécution [ISO 29119]

SUITE DE TESTS Ensemble de cas de test ou de procédures de test à exécuter dans un cycle de
test spécifique.

Source utilisée pour déterminer les résultats attendus à comparer avec les
ORACLE DE TEST résultats obtenus de l’application en cours de test [Adrion]

1.4.2 – ACTIVITÉS ET TÂCHES DE TEST 75


6. EXÉCUTION DES TESTS
Pendant l'exécution des tests, les suites de tests sont exécutées conformément au
calendrier d'exécution des tests.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Enregistrer les IDs et les versions des éléments de test ou de l'objet de test, des outils de test et des testware

Exécuter les tests manuellement ou à l'aide d'outils d'exécution de test

Comparer les résultats obtenus avec les résultats attendus

Analyser les anomalies afin d'établir leurs causes probables

Signaler les défauts sur la base des défaillances observées

Enregistrer les résultats de l'exécution des tests (par exemple, réussite, échec, blocage)

Répéter certaines activités de test, soit à la suite d'une action prise pour une anomalie, soit dans le cadre de
l'activité planifiée de test
Vérifier et mettre à jour la traçabilité bidirectionnelle entre les bases de test, les conditions de test, les cas de test,
les procédures de test et les résultats des tests

1.4.2 – ACTIVITÉS ET TÂCHES DE TEST 76


7. CLÔTURE DES TESTS (1/2)
Les activités de clôture des tests collectent les données des activités de test terminées
afin de consolider l'expérience, les testware et toute autre information pertinente. Les
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

activités de clôture des tests ont lieu à des jalons du projet.

VÉRIFIER SI TOUS LES RAPPORTS DE DÉFAUTS SONT CLÔTURÉS, ET SAISIR DES DEMANDES DE MODIFICATION
OU DES ITEMS DU BACKLOG DU PRODUIT POUR TOUS LES DÉFAUTS NON RÉSOLUS À LA FIN DE L'EXÉCUTION
DES TESTS

CRÉER UN RAPPORT DE SYNTHÈSE DE TEST À COMMUNIQUER AUX PARTIES PRENANTES

FINALISER ET ARCHIVER L’ENVIRONNEMENT DE TEST, LES DONNÉES DE TEST, L'INFRASTRUCTURE DE TEST ET


AUTRES TESTWARE POUR UNE RÉUTILISATION ULTÉRIEURE

1.4.2 – ACTIVITÉS ET TÂCHES DE TEST 77


7. CLÔTURE DES TESTS (2/2)

REMETTRE LE TESTWARE AUX ÉQUIPES DE MAINTENANCE, AUX AUTRES ÉQUIPES DE PROJET, ET/OU À
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

D'AUTRES PARTIES PRENANTES QUI POURRAIENT BÉNÉFICIER DE SON UTILISATION

ANALYSER LES LEÇONS APPRISES DES ACTIVITÉS DE TEST TERMINÉES AFIN DE DÉTERMINER LES CHANGEMENTS
NÉCESSAIRES POUR LES ITÉRATIONS, VERSIONS ET PROJETS FUTURS

UTILISER L'INFORMATION RECUEILLIE POUR AMÉLIORER LA MATURITÉ DU PROCESSUS DE TEST

L'activité qui rend les actifs de test disponibles pour une utilisation ultérieure, laisse
CLÔTURE DES TESTS les environnements de test dans un état satisfaisant et communique les résultats des
tests aux parties prenantes concernées [ISO 29119]

1.4.2 – ACTIVITÉS ET TÂCHES DE TEST 78


CAS PARTICULIER : TESTS EXPLORATOIRES
Dans le cas des TESTS EXPLORATOIRES (tests basés sur l’expérience : cf. 4.4.2) :
✓ L'ANALYSE DE TEST produit des conditions de test qui doivent être utilisées comme
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

objectifs de test dans des chartes de test.


✓ Lorsque ces objectifs de test sont traçables avec les bases de test, la couverture
atteinte au cours de ce type de tests basés sur l'expérience peut être mesurée.
✓ LA CONCEPTION ET L’IMPLÉMENTATION DES TESTS peuvent être réalisées et
éventuellement être documentées lors de l'exécution des tests.
✓ Les tests exploratoires sont exécutés immédiatement, en même temps que leur
conception et leur implémentation.

Documentation des activités de test dans le cadre de tests


CHARTE DE TEST
exploratoires basés sur des sessions.

1.4.2 – ACTIVITÉS ET TÂCHES DE TEST 79


LES PRODUITS D’ACTIVITÉS DU TEST (1/3)
PLANIFICATION ❑ Plan(s) de test
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Le plan de test contient les informations sur les bases de test + critères de sortie ou définition du terminé («
DEFINITION OF DONE »).

PILOTAGE & CONTRÔLE ❑ Rapports d'avancement des tests ❑ Rapports de synthèse des tests

Les rapports de test devraient fournir des détails pertinents pour les parties prenantes ciblées au sujet de
l'avancement des tests à la date du rapport, dont les résultats d’exécution des tests. Ils devraient également
tenir compte des aspects spécifiques relatifs à la gestion de projet.

ANALYSE DE TEST ❑ Conditions de test priorisées ❑ Chartes de test (tests exploratoires) ❑ Défauts

Peut impliquer la création de chartes de test, peut également aboutir à la découverte de défauts dans les
bases de test et à leur documentation.

1.4.3 – LES PRODUITS D’ACTIVITÉS DU TEST 80


LES PRODUITS D’ACTIVITÉS DU TEST (2/3)
Activité consistant à dériver et à spécifier des cas de test à partir des conditions de
CONCEPTION DE TEST test [ISO 29119]
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ Ensemble de cas de test ❑ Conception environnement de test


CONCEPTION DE TEST ❑ Cas de test de haut niveau ❑ Identification infrastructure et outils
❑ Identification données de test ❑ Affinage conditions de test

Cas de test de haut niveau : sans valeurs concrètes pour les données d'entrée et les résultats attendus.

❑ Procédures de test ordonnancées ❑ Création données de test


IMPLÉMENTATION DES
❑ Suites de test ❑ Création environnement de test
TESTS
❑ Calendrier d’exécution des tests ❑ Cas de test de bas niveau (exécutables)

Cas de test de bas niveau (exécutables) : les données de test sont utilisées pour attribuer des valeurs concrètes aux
entrées et aux résultats attendus des cas de test (à l’aide d’un oracle de test).

1.4.3 – LES PRODUITS D’ACTIVITÉS DU TEST 81


LES PRODUITS D’ACTIVITÉS DU TEST (3/3)
❑ Documentation : quels
❑ Documentation statut tests /
EXÉCUTION DES TESTS ❑ Rapports de défauts éléments de test
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

procédures de test
impliqués

❑ Rapports de synthèse de test ❑ Actions pour améliorer les projets


CLÔTURE DES TESTS
❑ Demandes de changement / backlog ❑ Testware finalisés

Confirmation par l’examen et la fourniture de preuves objectives que des


VÉRIFICATION
exigences spécifiées ont été satisfaites [ISO 9000]

1.4.3 – LES PRODUITS D’ACTIVITÉS DU TEST 82


TRAÇABILITÉ (1/3)
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Conditions de test
Exigences
Articles
Événements
Bases de test

Cas de test
Procédures de test Cas de test
Suites de test Cas de test

Calendrier d’exécution des tests


Données de test

1.4.4 – TRAÇABILITÉ ENTRE LES BASES DE TEST ET LES PRODUITS D’ACTIVITÉS DU TEST 83
TRAÇABILITÉ (2/3)
Il est important d'établir et de maintenir la TRAÇABILITÉ tout au long du processus de test entre
chaque élément des bases de test et les divers produits d'activités du test associés à cet élément.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Une bonne traçabilité facilite :


✓ L'évaluation de la couverture de test
✓ L’analyse de l'impact des changements
✓ L’audit des tests
✓ La satisfaction des critères de gouvernance IT
✓ L’amélioration du caractère compréhensible des rapports d'avancement des tests et des
rapports de synthèse de test afin d'y inclure l'état des éléments des bases de test
✓ La restitution des aspects techniques des tests aux parties prenantes en des termes
qu'elles peuvent comprendre
✓ L’apport d’information pour évaluer la qualité du produit, l’aptitude du processus et
l'avancement du projet par rapport aux objectifs métier

1.4.4 – TRAÇABILITÉ ENTRE LES BASES DE TEST ET LES PRODUITS D’ACTIVITÉS DU TEST 84
TRAÇABILITÉ (3/3)
ILLUSTRATION
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

L'évaluation de la couverture de test


L’analyse de l'impact des changements
✓ L’identification d’une modification sur la condition de
1 test « 4 » aura un impact sur
➢ « 5, 6, 7 »
➢ et sur « 8, 9, 10, 11 ».
2 4
✓ Le risque de cet impact sur sept conditions de test
est à évaluer en fonction du sujet identifié.
3 5 8
✓ Exemple :
➢ L’évolution d’une exigence, une évolution de
6 9 11 spécification / user story, un risque métier dû à la
perte de connaissance (absence de l’expert pour une
longue durée) lors de la conception du logiciel…
7 10

1.4.4 – TRAÇABILITÉ ENTRE LES BASES DE TEST ET LES PRODUITS D’ACTIVITÉS DU TEST 85
85
1. FONDAMENTAUX DES TESTS

1.5 – LA PSYCHOLOGIE DES TESTS


OBJECTIF(S) DE CONNAISSANCE
❑ FL-1.5.1
(K1) Identifier les facteurs psychologiques ayant une influence sur le succès des tests
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ FL-1.5.2
(K2) Expliquer la différence entre l'état d'esprit requis pour les activités de test et l'état d'esprit
requis pour les activités de développement

1.5 – LA PSYCHOLOGIE DES TESTS 87


UN ENVIRONNEMENT HOSTILE ?
IDENTIFIER LES DÉFAUTS, lors de tests statiques ou dynamiques, peut être perçu comme une
CRITIQUE du produit et de ses auteurs.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Les tests sont souvent perçus à tort comme une activité CONTRE-PRODUCTIVE voire même
DESTRUCTRICE qui contient souvent de mauvaises nouvelles.

En effet, le BIAIS DE CONFIRMATION - élément de la psychologie humaine - peut rendre


difficile à accepter des informations en désaccord avec les croyances actuelles. D'autres
BIAIS COGNITIFS peuvent rendre difficile à comprendre ou à accepter l'information produite
par les tests.

1.5.1 – PSYCHOLOGIE HUMAINE ET TEST 88


L’ART DE COMMUNIQUER
Une COMMUNICATION POSITIVE ET CONSTRUCTIVE des problématiques rencontrées – défauts, défaillances -
permettra de réduire ces perceptions négatives sur le test.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Ainsi les tensions entre les testeurs et les analystes, les Product Owners, les Scrum Master, les concepteurs
et les développeurs peuvent être réduites.

AMÉLIORER LA COMMUNICATION du testeur et du Test

Suppose de : Suppose aussi d’éviter les :

✓ Commencer par la COLLABORATION plutôt que par la confrontation. ✓ Critiques,


✓ Rappeler si nécessaire les OBJECTIFS COMMUNS sur le projet. ✓ Conflits,
✓ Mettre l'accent sur les BÉNÉFICES DU TEST. ✓ Accusations,
✓ Communiquer de façon NEUTRE ET FACTUELLE, sans critiquer les personnes. ✓ Incompréhensions,
✓ Privilégier la courtoisie. ✓ Stigmatisations.
✓ Se mettre à la place de son interlocuteur pour comprendre son ressenti.
✓ S'assurer que chacun comprend ce que l'autre a exprimé.

1.5.1 – PSYCHOLOGIE HUMAINE ET TEST 89


DÉFINIR UN OBJECTIF COMMUN
DÉFINIR CLAIREMENT LE BON ENSEMBLE D'OBJECTIFS DE TEST a d'importantes implications
psychologiques.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

La plupart des gens ont tendance à aligner leurs plans et leurs comportements avec les
objectifs fixés par l'équipe, la direction et les autres parties prenantes.
Il est également important que les testeurs adhèrent à ces objectifs avec un biais
personnel minimum.

1.5.1 – PSYCHOLOGIE HUMAINE ET TEST 90


ETAT D’ESPRIT DES TESTEURS ET DES DÉVELOPPEURS (1/2)
DÉVELOPPEUR TESTEUR
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

UNE DIFFÉRENCE D'ÉTAT D'ESPRIT CAR DES OBJECTIFS DIFFÉRENTS


❖ Cherche à concevoir et construire une ❖ Effectue la vérification et la validation du
solution. produit.
❖ Pragmatique : cherche la solution la plus ❖ Détecte des défauts avant la livraison.
simple. ❖ Exécute le test par rapport à un scénario
❖ A tendance à se focaliser sur les cas précis et détaillé ou selon une charte de test.
nominaux.

A l’inverse l’union de ces points de vue permet d'atteindre un niveau plus élevé de
qualité des produits.

1.5.2 - ETAT D’ESPRIT DES TESTEURS ET DES DÉVELOPPEURS 91


ETAT D’ESPRIT DES TESTEURS ET DES DÉVELOPPEURS (2/2)
DÉVELOPPEUR TESTEUR
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

DIFFÉRENCE DE VISION DES TESTS


❖ Vision Technique. ❖ Vision plutôt métier.
❖ Se base sur son interprétation du besoin ❖ Son activité est en partie justifiée par la
utilisateur. découverte de défauts.
❖ Ne cherche pas naturellement à "casser" ❖ Aime détecter des défauts (preuve de
ce qu'il a développé ! l'efficacité de son travail).
❖ N'aime pas découvrir des défauts puisqu'il
peut en être la source.
❖ Difficulté à trouver des défauts (biais de
confirmation).

1.5.2 - ETAT D’ESPRIT DES TESTEURS ET DES DÉVELOPPEURS 92


QUEL ÉTAT D’ESPRIT ADOPTER POUR LE TESTEUR ?
Un état d'esprit reflète les hypothèses d'une personne et les méthodes qu'elle préfère
pour la prise de décision et la résolution de problèmes.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

L'ÉTAT D'ESPRIT D'UN TESTEUR devrait inclure :


✓ La curiosité.
✓ Un pessimisme professionnel.
✓ Un esprit critique professionnel (œil critique).
✓ Le souci du détail.
✓ La motivation pour de bonnes et positives communications et relations.
✓ L’expérience pour les estimations d'erreurs.
L'état d'esprit d'un testeur tend à grandir et à mûrir au fur et à mesure que le testeur
acquiert de l'expérience.
Avec le bon état d'esprit, les développeurs sont capables de tester leur propre code.

1.5.2 - ETAT D’ESPRIT DES TESTEURS ET DES DÉVELOPPEURS 93


L’INDÉPENDANCE DES TESTEURS

Dans certains modèles de cycle de vie de développement du logiciel (séquentiel


notamment), certaines activités de test peuvent être effectuées par des TESTEURS
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

INDÉPENDANTS.

L’INDÉPENDANCE DES TESTEURS AUGMENTE L'EFFICACITÉ DE LA DÉTECTION DES DÉFAUTS, ce qui est
particulièrement important pour les systèmes de grande taille, complexes ou critiques sur
le plan de la sûreté.
Elle évite également le parti pris.
Les testeurs indépendants apportent une PERSPECTIVE DIFFÉRENTE de celle des auteurs du
produit d’activités testé (c.-à-d. les analystes métier, les Product Owners, les concepteurs
et les développeurs), puisqu'ils ont des biais cognitifs différents de ceux des auteurs.

1.5.2 - ETAT D’ESPRIT DES TESTEURS ET DES DÉVELOPPEURS 94


2. TESTER PENDANT LE CYCLE DE VIE DU DÉVELOPPEMENT LOGICIEL
SOMMAIRE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

2.1 - LES MODÈLES DE DÉVELOPPEMENT LOGICIEL


2.2 - NIVEAUX DE TESTS
2.3 - TYPES DE TESTS
2.4 - TESTS DE MAINTENANCE

2. TESTER PENDANT LE CYCLE DE VIE DU DÉVELOPPEMENT LOGICIEL 96


2. TESTER PENDANT LE CYCLE DE VIE DU DÉVELOPPEMENT LOGICIEL

2.1 LES MODÈLES DE DÉVELOPPEMENT LOGICIEL


OBJECTIF(S) DE CONNAISSANCE
❑ FL-2.1.1
(K2) Expliquer les relations entre les activités de développement logiciel et les activités de test
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

dans le cycle de vie du développement logiciel.

❑ FL-2.1.2
(K1) Identifier les raisons qui font que les modèles de développement logiciel doivent être
adaptés au contexte du projet et aux caractéristiques du produit.

2.1 LES MODÈLES DE DÉVELOPPEMENT LOGICIEL 98


DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS

Quel que soit le MODÈLE DE CYCLE DE VIE DE DÉVELOPPEMENT LOGICIEL, il y a plusieurs caractéristiques
de bonnes pratiques des tests :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Chaque activité de développement : une activité de ✓ Chaque niveau de test : objectifs de test spécifiques
test correspondante à ce niveau
✓ Les testeurs participent aux discussions pour définir
et affiner les exigences et la conception, et sont
✓ L'analyse et la conception des tests pour un niveau
impliqués dans la revue des produits d'activités (p.
de test donné commencent au cours de l'activité de
ex. les exigences, la conception, les User Stories,
développement correspondante
etc.) dès que des versions préliminaires sont
disponibles.

Quel que soit le MODÈLE DE CYCLE DE VIE DE DÉVELOPPEMENT LOGICIEL, les activités de test devraient
commencer dès les premières étapes du cycle de vie, en respectant le principe de « Tester tôt ».

NIVEAU DE TEST Une instanciation spécifique d'un processus de test [ISO 29119].

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 99


MODÈLE DE DÉVELOPPEMENT SÉQUENTIEL

Un type de modèle de cycle de vie de développement selon lequel un


MODÈLE DE DÉVELOPPEMENT
système achevé est développé de manière linéaire en plusieurs phases
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

SÉQUENTIEL distinctes et successives, sans chevauchement entre elles.

En théorie, il n'y a pas de chevauchement des phases, mais dans la pratique, il est
bénéfique d'avoir un retour rapide de la phase suivante.
Les modèles de développement séquentiels fournissent des logiciels qui contiennent
l'ensemble des fonctionnalités, mais qui nécessitent généralement des mois ou des
années pour être livrés aux parties prenantes et aux utilisateurs.
✓ MODÈLE EN CASCADE
✓ MODÈLE EN V
✓ WATERFALL

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 100


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS


MODÈLE EN CASCADE OU WATERFALL

101
MODÈLE EN V
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Exigences métier
Tests d’acceptation
Cahier des charges

Spécifications
Tests système
d’exigences solution

Spécifications de
Tests d’intégration
conception générale

Spécifications de
Tests de composant
conception détaillée

Codage

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 102


CYCLE DE VIE D’UN PRODUIT (MODÈLE SÉQUENTIEL)

Vie du produit
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Vision MOA (Maîtrise d'ouvrage)

Etudes Mûrissement Développement Utilisation Fin de vie

Assistance au
Mûrissement Conception Construction Vérification Maintenance du produit
site pilote

Le produit entre en production limitée


Le produit entre en production généralisée

Vision MOE (Maîtrise d’œuvre) / Technique


Vie du projet

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 103


LES PHASES DE TESTS DANS LE CYCLE DE VIE D’UN PRODUIT

Avant projet Développement projet Maintenance et exploitation


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Conception du
Mûrissement Codage Mise en production
logiciel

Stratégie de
Conception des tests Exécution des tests
test

Principe du « Tester tôt » en modèle de développement séquentiel :


✓ Conception stratégie de test : peut débuter en phase de mûrissement.
✓ Conception des tests : peut débuter en phase de conception logiciel à partir de spécifications
fonctionnelles en version préliminaire.
✓ Exécution des tests : peut débuter dès la première livraison du code.

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 104


MODÈLES DE DÉVELOPPEMENT INCRÉMENTAL (1/2)
Un modèle de cycle de vie du développement dans lequel la portée du
projet est généralement déterminée au début du cycle de vie du projet,
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

mais les estimations de temps et de coûts sont régulièrement modifiées


MODÈLE DE DÉVELOPPEMENT à mesure que l'équipe du projet comprend mieux le produit. Le produit
INCRÉMENTAL est développé au moyen d'une série de cycles répétés, chacun
fournissant un incrément qui ajoute successivement à la fonctionnalité
du produit.

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 105


MODÈLES DE DÉVELOPPEMENT INCRÉMENTAL (2/2)
Le développement incrémental implique la définition des exigences, la conception, le
développement et le test d'un système par morceaux.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Nouveau cycle de développement


pour un incrément

VERSION 1 VERSION 2 VERSION 3 VERSION 4 VERSION 5

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 106


MODÈLES DE DÉVELOPPEMENT ITÉRATIF (1/2)

Un modèle de cycle de développement où le projet est séparé en un


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

nombre d’itérations (souvent nombreuses). Une itération est une boucle


MODÈLE DE DÉVELOPPEMENT complète de développement résultant en une livraison (interne ou externe)
ITÉRATIF d’un produit exécutable, un sous-ensemble du produit final en
développement, qui grandit d’itération en itération pour devenir le produit
fini.

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 107


MODÈLES DE DÉVELOPPEMENT ITÉRATIF (2/2)
CYCLE ITÉRATIF : succession de petites activités de développement aboutissant au système.
Pour chaque itération : exigences, conception, construction et tests.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Tests Système
Ou Service
Tests Complet

Tests

Conception Construction

Exigences Tests

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 108


EXEMPLE DE MODÈLES DE DÉVELOPPEMENT ITÉRATIF ET/OU INCRÉMENTAL

Cette liste n’est pas exhaustive :


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ RUP ✓ SCRUM

✓ KANBAN ✓ SPIRAL (ou par prototypage)

✓ XP

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 109


MODÈLE RUP (RATIONAL UNIFIED PROCESS) - DÉFINITION

RATIONAL UNIFIED PROCESS Un cadre propriétaire et adaptable décrivant le processus itératif de


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

développement d'un logiciel. Le processus comprend quatre phases du


RUP cycle de vie du projet : création, élaboration, construction et transition.

Chaque itération a tendance à être relativement longue (p. ex. deux à trois mois), et les
incréments de caractéristiques sont proportionnellement importants, de l’ordre de deux
ou trois groupes de caractéristiques connexes.

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 110


MODÈLE RUP (RATIONAL UNIFIED PROCESS) - DESCRIPTION
La méthode RUP est un processus qui se décompose en 4 phases :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

INCEPTION / CRÉATION
L'idée du projet est indiquée. L'équipe de développement détermine si le projet mérite
d'être poursuivi et quelles ressources sont nécessaires.

ÉLABORATION
L'architecture du projet et les ressources nécessaires sont encore évalués. Les développeurs
examinent les demandes et les coûts associés au développement.

CONSTRUCTION
Le projet est développé. Le logiciel est conçu, écrit et testé.

TRANSITION
Le logiciel est distribué aux utilisateurs. Les derniers ajustements ou mises à jour sont faits
en fonction de leurs commentaires.

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 111


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS


112
MODÈLE RUP (RATIONAL UNIFIED PROCESS) - EXEMPLE
MODÈLE SCRUM (AGILE)
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Chaque itération a tendance à être ✓ Les incréments de caractéristiques sont


relativement courte : en heures, jours ou proportionnellement petits : de l’ordre de
quelques semaines quelques améliorations et/ou deux ou
trois nouvelles caractéristiques

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 113


MODÈLE KANBAN (AGILE)
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Itérations de durée fixe ou ✓ Soit livrer à la fin d’une ✓ Soit regrouper des groupes
non. itération une seule de caractéristiques pour les
amélioration ou livrer en une fois.
caractéristique,

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 114


MODÈLE EN SPIRALE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Création d’incréments expérimentaux, dont certains peuvent être fortement


remaniés ou même abandonnés lors de travaux de développement ultérieurs.
2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 115
LES AVANTAGES DES MODÈLES ITÉRATIFS & INCRÉMENTAUX
Les modèles itératifs et incrémentaux :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Chevauchement et itération sur les ✓ Chaque caractéristique est testée à


niveaux de test. plusieurs niveaux de test.
✓ Dans certains cas : livraison continue ✓ Équipes auto-organisées : change
et/ou déploiement continu, les deux l’organisation du test et les relations avec
impliquant une automatisation des tests les développeurs.
dans le flux de livraison.

✓ Produisent un système aux ✓ Les tests de régression sont de plus en


caractéristiques croissantes, qui peut être plus importants à mesure que le système
livré aux utilisateurs finaux par grossit.
caractéristique, par itération, par version
majeure.

2.1.1 - DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS 116


DÉVELOPPEMENT DE LOGICIEL ET TESTS LOGICIELS
Un MODÈLE DE CYCLE DE VIE DE DÉVELOPPEMENT LOGICIEL APPROPRIÉ devrait être choisi et adapté en
fonction :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ de l'objectif du projet, ✓ du type de produit développé,


✓ des priorités métier, ✓ des risques produit et projet identifiés.

Selon le contexte du projet, il peut être nécessaire de combiner ou de réorganiser les niveaux de
test et/ou les activités de test, voire de combiner les modèles de cycle de vie du développement
logiciel eux-mêmes.

SYSTÈMES INTERNET Composés de nombreux objets différents (équipements, produits, services), ils
DES OBJETS appliquent généralement des modèles de cycle de développement logiciel distincts
pour chaque objet (difficile à gérer pour le système global IoT).
Ou IOT – INTERNET OF De plus, le cycle de développement logiciel de ces objets met davantage l'accent
THINGS
sur les phases ultérieures du cycle de vie du développement logiciel après leur mise
en service (exploitation, mise à jour…)

2.1.2 - MODÈLES DE CYCLE DE VIE DU DÉVELOPPEMENT LOGICIEL EN CONTEXTE 117


2. TESTER PENDANT LE CYCLE DE VIE DU DÉVELOPPEMENT LOGICIEL

2.2 – NIVEAUX DE TEST


OBJECTIF(S) DE CONNAISSANCE
❑ FL-2.2
(K2) Comparer les différents niveaux de test en termes d'objectifs, de bases de test, d'objets de
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

test, de défauts et de défaillances typiques, d'approches et de responsabilités

2.2 – NIVEAUX DE TEST 119


NIVEAUX DE TEST – DÉFINITION

NIVEAU DE TEST Une instanciation spécifique d'un processus de test [ISO 29119].
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OU PHASE DE TEST Un groupe d'activités de test qui sont organisées et gérées ensemble.

Quel que soit le MODÈLE DE CYCLE DE VIE DE DÉVELOPPEMENT LOGICIEL, il y a plusieurs caractéristiques de
bonnes pratiques des tests :
✓ TC ➔ Test de Composant
TA
✓ TI ➔ Test d’Intégration
✓ TS ➔ Test Système TS
✓ TA ➔ Test d’Acceptation
TI

TC

Pour chaque niveau de test, un environnement de test approprié est requis

2.2 – NIVEAUX DE TEST 120


ENVIRONNEMENT DE TEST

Environnement contenant le matériel, les instruments, les simulateurs, les


ENVIRONNEMENT DE TEST
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

outils logiciels et les autres éléments de support nécessaires à l’exécution d’un


OU BANC DE TEST
test [ISO 24765]

2.2 – NIVEAUX DE TEST 121


TEST DE COMPOSANT
TEST DE COMPOSANT
OU TEST UNITAIRE Le test de composants logiciels individuels. [ISO 24765]
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OU TEST DE MODULE

COMPOSANT Un élément logiciel minimal qui peut être testé isolément.


OU UNITÉ OU MODULE

TA

TS

TI

TC

2.2.1 - TEST DE COMPOSANTS 122


TEST DE COMPOSANT - OBJECTIFS
Les tests de composants se concentrent sur des composants qui peuvent être testés
séparément.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OBJECTIFS
✓Réduire les risques.
✓Vérifier si les comportements fonctionnels et non-fonctionnels du composant sont tels qu'ils
ont été conçus et spécifiés.
✓Renforcer la confiance dans la qualité du composant.
✓Trouver des défauts dans le composant.
✓Empêcher les défauts de passer à des niveaux de test plus élevés.

Les tests de composants peuvent porter sur des caractéristiques fonctionnelles (p. ex.,
exactitude des calculs), non-fonctionnelles (p. ex. recherche de fuites mémoire) et les
propriétés structurelles (p. ex., tests des décisions).

2.2.1 - TEST DE COMPOSANTS 123


TEST DE COMPOSANT - PRINCIPE

1
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Entrée Sortie

PILOTE OBJET À TESTER


Sortie* Entrée* BOUCHON
DRIVER DE TEST
2

HARNAIS DE TEST

* Optionnel

Les tests de composants sont souvent effectués indépendamment du reste du système, ce


qui peut nécessiter de mettre en place des objets fictifs, une virtualisation des services,
des harnais de test, des bouchons et des pilotes.

2.2.1 - TEST DE COMPOSANTS 124


TEST DE COMPOSANT – BASES ET OBJET DE TEST

BASES DE TEST OBJET DE TEST


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓Conception détaillée ✓Composants, unités ou modules


✓Code ✓Code et structures de données
✓Modèle de données ✓Classes
✓Spécifications des composants ✓Modules de bases de données

2.2.1 - TEST DE COMPOSANTS 125


TEST DE COMPOSANT - DÉFAUTS ET DÉFAILLANCES TYPES
DÉFAUTS ET DÉFAILLANCES TYPES
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓Fonctionnalité incorrecte (par exemple, non conforme aux spécifications de conception)


✓Problèmes de flux de données
✓Code et logique incorrects
✓Robustesse (défaillance en présence de données invalides)

Les défauts sont généralement corrigés dès qu'ils sont détectés (souvent sans
gestion formelle des défauts).
Cependant lorsque les développeurs rapportent vraiment des défauts, cela donne
des informations importantes pour l'analyse des causes racines et l'amélioration des
processus.

2.2.1 - TEST DE COMPOSANTS 126


TEST DE COMPOSANT - APPROCHES ET RESPONSABILITÉS SPÉCIFIQUES

APPROCHES ET RESPONSABILITÉS SPÉCIFIQUES


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓Les tests de composants sont généralement effectués par le développeur qui a écrit le code
✓Les développeurs peuvent alterner le développement des composants avec la recherche et la
correction de défauts
✓Les développeurs vont souvent écrire et exécuter des tests après avoir écrit le code d'un
composant
✓En développement Agile, l'écriture de cas de test de composants automatisés peut précéder
l'écriture du code de l'application : approche « test-first » (TDD : Test Driven Development).
✓Analyse statique

2.2.1 - TEST DE COMPOSANTS 127


TEST D’INTÉGRATION

Test effectué pour montrer des défauts dans les interfaces et interactions de
TEST D’INTÉGRATION
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

composants ou systèmes intégrés

TA

TS

TI

TC

2.2.2 - TEST D'INTÉGRATION 128


TEST D’INTÉGRATION – OBJECTIFS
Les tests d'intégration se concentrent sur les interactions entre les composants ou les
systèmes.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OBJECTIFS
✓Réduire les risques.
✓Vérifier si les comportements fonctionnels et non-fonctionnels des interfaces sont tels qu'ils
ont été conçus et spécifiés.
✓Renforcer la confiance dans la qualité des interfaces.
✓Trouver des défauts (qui peuvent se trouver dans les interfaces elles-mêmes ou dans les
composants ou systèmes).
✓Empêcher les défauts de passer à des niveaux de test plus élevés.

Types de test concernés : fonctionnels, non-fonctionnels et structurels.

2.2.2 - TEST D'INTÉGRATION 129


TEST D’INTÉGRATION – 2 NIVEAUX
Il y a deux niveaux différents de tests d'intégration, qui peuvent être effectués sur des
objets de test de taille variable.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TEST D’INTÉGRATION TEST D’INTÉGRATION


DE COMPOSANTS DE SYSTÈMES

2.2.2 - TEST D'INTÉGRATION 130


TEST D’INTÉGRATION DE COMPOSANTS - PRINCIPE

TEST D’INTÉGRATION DE Test effectué pour découvrir des défauts dans les interfaces et les
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

COMPOSANTS interactions entre des composants intégrés.

Database Connector IHM


Classe CalcFin
Principale

IHM de Classe CalcMath


Connexion
Classe Outils
Web Service 1
Module sécurité
Web Service 2

2.2.2 - TEST D'INTÉGRATION 131


TEST D’INTÉGRATION DE SYSTÈMES - PRINCIPE

TEST D’INTÉGRATION SYSTÈME Tester la combinaison et l'interaction des systèmes.


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

2.2.2 - TEST D'INTÉGRATION 132


TEST D’INTÉGRATION – BASES ET OBJET DE TEST

BASES DE TEST OBJET DE TEST


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓Conception du logiciel et du système


✓Sous-systèmes
✓Diagrammes de séquence
✓Bases de données
✓Spécifications des protocoles d'interface et de communication
✓Infrastructure
✓Cas d’utilisation
✓Interfaces
✓Architecture au niveau du composant ou du système
✓APIs
✓Workflows
✓Micro-services
✓Définitions des interfaces externes

2.2.2 - TEST D'INTÉGRATION 133


TEST D’INTÉGRATION DE COMPOSANTS - DÉFAUTS ET DÉFAILLANCES TYPES

DÉFAUTS ET DÉFAILLANCES TYPES


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓Données incorrectes, données manquantes ou encodage incorrect des données


✓Mauvais séquencement ou synchronisation des appels d'interfaces
✓Décalages au niveau des interfaces
✓Défaillances dans la communication entre les composants
✓Défaillances de communication non gérées ou mal gérées entre les composants
✓Hypothèses incorrectes sur la signification, les unités ou les limites des données transmises
entre les composants

2.2.2 - TEST D'INTÉGRATION 134


TEST D’INTÉGRATION DE SYSTÈMES - DÉFAUTS ET DÉFAILLANCES TYPES

DÉFAUTS ET DÉFAILLANCES TYPES


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓Structures de message incohérentes entre les systèmes


✓Données incorrectes, données manquantes ou encodage incorrect des données
✓Décalages au niveau des interfaces
✓Défaillances dans la communication entre les systèmes
✓Défaillances de communication non gérées ou mal gérées entre les systèmes
✓Hypothèses incorrectes sur la signification, les unités ou les limites des données transmises
entre les systèmes
✓Non-respect des règles de sécurité requises

2.2.2 - TEST D'INTÉGRATION 135


TEST D’INTÉGRATION - APPROCHES ET RESPONSABILITÉS SPÉCIFIQUES

APPROCHES ET RESPONSABILITÉS SPÉCIFIQUES


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓Les tests d'intégration de composants et les tests d'intégration de systèmes doivent se concentrer sur
l'intégration elle-même.
✓Responsabilités le plus souvent :
➢ Développeurs : tests d’intégration de composants
➢ Testeurs : tests d’intégration de systèmes
✓ Les composants ou systèmes peuvent être construits dans l'ordre requis pour des tests plus
efficaces.
✓Les stratégies d'intégration systématique peuvent être fondées sur :
➢ L'architecture du système (p. ex. de haut en bas et de bas en haut),
➢ Les tâches fonctionnelles,
➢ Les séquences de traitement des transactions,
➢ Les risques : complexité des interfaces.
✓Intégration incrémentale préférable au « Big Bang ».

2.2.2 - TEST D'INTÉGRATION 136


TEST D’INTÉGRATION - APPROCHE BIG-BANG
L’APPROCHE BIG-BANG est une méthode de test d'intégration dans laquelle les éléments
logiciels, matériels ou les deux sont combinés en une fois (plutôt qu'effectués par étape).
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

AVANTAGES INCONVÉNIENTS

❖ Peu ou pas de contraintes de planification, ❖ Approche unitaire,


❖ S'adapte aux petits et moyens systèmes. ❖ Pas de maîtrise des tests,
❖ Difficultés à déterminer la cause d’une
défaillance.

2.2.2 - TEST D'INTÉGRATION 137


TEST D’INTÉGRATION - APPROCHE INCRÉMENTALE
L’APPROCHE INCRÉMENTALE est une méthode de test d'intégration dans laquelle les éléments
logiciels, matériels ou les deux sont combinés par étape, c'est-à-dire avec un petit nombre
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

de composants ou de systèmes supplémentaires à la fois (plutôt qu'effectués en seule


fois).

AVANTAGES INCONVÉNIENTS

❖ Peu ou pas de contraintes de planification, ❖ Approche unitaire,


❖ S'adapte aux petits et moyens systèmes. ❖ Pas de maîtrise des tests,
❖ Difficultés à déterminer la cause d’une
défaillance.

2.2.2 - TEST D'INTÉGRATION 138


TEST D’INTÉGRATION - APPROCHE INCRÉMENTALE – BAS EN HAUT
L’APPROCHE INCRÉMENTALE DE BAS EN HAUT est une approche incrémentale de tests
d'intégration où le niveau le plus bas des composants est testé d'abord, et ensuite utilisé
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

pour faciliter les tests des composants de plus haut niveau. Ce processus est répété
jusqu'au test du composant le plus haut de la hiérarchie.

NÉCESSITE LA CONCEPTION D’UN NOMBRE IMPORTANT DE PILOTES POUR


DIRIGER CHACUN DES NIVEAUX D'INTÉGRATION

Niveau 1

Niveau 2 Niveau 2

Niveau 3 Niveau 3 Niveau 3 Niveau 3 Niveau 3

2.2.2 - TEST D'INTÉGRATION 139


TEST D’INTÉGRATION - APPROCHE INCRÉMENTALE – HAUT EN BAS
L’APPROCHE INCRÉMENTALE DE HAUT EN BAS est une approche incrémentale des tests
d'intégration où les composants en haut de la hiérarchie sont testés d'abord, avec les
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

composants de niveau inférieur simulés par des bouchons. Les composants testés sont
ensuite utilisés pour tester des composants de niveaux inférieurs. Le processus est répété
jusqu'à ce que les composants de plus bas niveau ont été testés
NÉCESSITE LA CONCEPTION D’UN NOMBRE IMPORTANT DE BOUCHONS POUR
REMPLACER LES COMPOSANTS NON ENCORE DÉVELOPPÉS

Niveau 1

Niveau 2 Niveau 2

Niveau 3 Niveau 3 Niveau 3 Niveau 3 Niveau 3

2.2.2 - TEST D'INTÉGRATION 140


TEST D’INTÉGRATION – INTÉGRATION CONTINUE
Plus la portée de l'intégration est vaste, plus il est difficile d’identifier le composant ou le système
responsable d’une défaillance :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Risque accru,
✓ Temps supplémentaire pour la correction.
➔ MISE EN PLACE DE L’INTÉGRATION CONTINUE
 Le logiciel est intégré composant par composant (intégration fonctionnelle),
 Devenue pratique courante,
 Inclut souvent des tests de régression automatisés, idéalement à plusieurs niveaux de test.
AVANTAGES
o Modifications testées immédiatement,
o Problèmes d'intégration sont détectés et réparés de façon continue,
o Une version logicielle est toujours disponible pour un test, une démonstration.

2.2.2 - TEST D'INTÉGRATION 141


TEST SYSTÈME
Tester un système intégré pour vérifier qu'il répond aux exigences spécifiées.
TEST SYSTÈME [Hetzel]
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TA

TS

TI

TC

2.2.3 - TEST SYSTÈME 142


TEST SYSTÈME - OBJECTIFS
Les tests système se concentrent sur le comportement et les capacités d'un système ou
d'un produit entier, en considérant souvent les tâches de bout en bout que le système
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

peut exécuter et les comportements non-fonctionnels qu'il présente pendant l'exécution


de ces tâches.
OBJECTIFS
✓ Réduire les risques
✓ Vérifier si les comportements fonctionnels et non-fonctionnels du système sont tels qu'ils ont été conçus et
spécifiés
✓ Valider que le système est complet et fonctionnera comme prévu
✓ Renforcer la confiance dans la qualité du système dans son ensemble
✓ Trouver des défauts
✓ Empêcher les défauts de passer à des niveaux de test plus élevés
✓ Vérification de la qualité des données
✓ Produit de l’information pour prendre des décisions de livraison
✓ Satisfaire aux exigences ou aux normes légales ou réglementaires

2.2.3 - TEST SYSTÈME 143


TEST SYSTÈME – BASES ET OBJET DE TEST
BASES DE TEST OBJET DE TEST
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓Spécifications des exigences système et ✓Applications


logicielles (fonctionnelles et non- ✓Systèmes Matériel/Logiciel
fonctionnelles)
✓Systèmes d’exploitation
✓Rapports d'analyse des risques
✓Système sous test (SUT – System Under
✓Cas d’utilisation Test)
✓Epics et User Stories ✓Configuration du système et données de
✓Modèles de comportement du système configuration

✓Diagrammes d’états
✓Manuels système et manuels d'utilisation

2.2.3 - TEST SYSTÈME 144


TEST SYSTÈME - DÉFAUTS ET DÉFAILLANCES TYPES
DÉFAUTS ET DÉFAILLANCES TYPES
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓Calculs incorrects
✓Comportement fonctionnel ou non-fonctionnel du système incorrect ou inattendu
✓Flux de contrôle et/ou de données incorrects au sein du système
✓Réalisation incorrecte et incomplète des tâches fonctionnelles de bout en bout
✓Incapacité du système à fonctionner correctement dans le ou les environnements de
production
✓Incapacité du système à fonctionner selon la description faite dans les manuels système et
utilisateur

2.2.3 - TEST SYSTÈME 145


TEST SYSTÈME - APPROCHES ET RESPONSABILITÉS SPÉCIFIQUES

APPROCHES ET RESPONSABILITÉS SPÉCIFIQUES


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓Les tests système devraient se concentrer sur le comportement global de bout en


bout du système dans son ensemble, à la fois fonctionnel et non-fonctionnel.
✓Les tests système doivent utiliser les techniques de test les plus appropriées pour
les aspects du système à tester.
✓Responsabilités le plus souvent : testeurs indépendants.
✓Implication en amont des testeurs dans l’affinement des User Stories ou dans les
activités de tests statiques (ex. revues) : aide à réduire l'incidence des défauts dans
les spécifications, qui peuvent conduire à un manque de compréhension ou à des
désaccords sur le comportement attendu du système => faux positifs, faux négatifs.

2.2.3 - TEST SYSTÈME 146


TEST D’ACCEPTATION
Test formel en rapport avec les besoins utilisateur, exigences et processus métier,
réalisé pour déterminer si un système satisfait ou non aux critères d’acceptation et
TEST D’ACCEPTATION
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

permettre aux utilisateurs, clients ou autres entités autorisées de déterminer


l’acceptation ou non du système. [ISO 24765]

TA

TS

TI

TC

2.2.4 - TEST D’ACCEPTATION 147


TEST D’ACCEPTATION – OBJECTIFS
Les tests d'acceptation, comme les tests système, se concentrent généralement sur le
comportement et les capacités d'un système ou d'un produit entier.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OBJECTIFS
✓Établir la confiance dans la qualité du système dans son ensemble
✓Valider que le système est complet et qu'il fonctionnera comme attendu
✓Vérifier que les comportements fonctionnels et non-fonctionnels du système sont tels que
spécifiés
✓Produit des informations permettant d'évaluer la disponibilité du système pour le
déploiement et l'utilisation par le client (utilisateur final)
✓Satisfaire aux exigences ou aux normes légales ou réglementaires.

Des défauts peuvent être trouvés pendant les tests d'acceptation, mais la découverte de défauts ne
constitue en général pas un objectif, et la découverte d'un nombre significatif de défauts pendant les tests
d'acceptation peut dans certains cas être considérée comme un risque majeur du projet.

2.2.4 - TEST D’ACCEPTATION 148


LES FORMES COMMUNES DE TESTS D’ACCEPTATION
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TEST D’ACCEPTATION
ACCEPTANCE TESTING

TEST D'ACCEPTATION
TEST D'ACCEPTATION TEST D'ACCEPTATION
CONTRACTUELLE ET TEST ALPHA ET BÊTA
UTILISATEUR OPÉRATIONNELLE
RÉGLEMENTAIRE
UAT – USER ACCEPTANCE TESTING OAT – OPERATIONAL ACCEPTANCE TESTING

2.2.4 - TEST D’ACCEPTATION 149


TESTS D’ACCEPTATION UTILISATEUR
TEST D’ACCEPTATION UTILISATEUR Tests d'acceptation effectués dans un environnement opérationnel réel
OU UAT POUR USER ACCEPTANCE ou simulé par les utilisateurs prévus en mettant l'accent sur leurs besoins,
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TESTING leurs exigences et leurs processus métier.

Les tests d'acceptation du système par les utilisateurs sont généralement axés sur la
validation de son aptitude à l’usage par les utilisateurs prévus dans un environnement
opérationnel réel ou simulé. L'objectif principal est de renforcer la confiance dans l’usage
du système pour répondre aux besoins des utilisateurs, satisfaire les exigences et exécuter
les processus métier avec un minimum de difficultés, de coûts et de risques.
OBJECTIFS DES TESTS D’ACCEPTATION UTILISATEUR
o L'exhaustivité de son contenu, o La conformité aux spécifications utilisateurs,
o Description des modes opératoires, o Décrire le fonctionnement des outils logiciels,
o Gestion des versions, o Décrire l'utilisation du logiciel.

2.2.4 - TEST D’ACCEPTATION 150


TESTS D’ACCEPTATION OPÉRATIONNELLE
Test opérationnel en phase de test d'acceptation, généralement
TEST D’ACCEPTATION OPÉRATIONNELLE effectué dans un environnement opérationnel (simulé) par
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OU TEST D’ACCEPTATION DE PRODUCTION l'exploitation et/ou le personnel de l'administration des systèmes


OU OAT pour OPERATIONAL ACCEPTANCE en se concentrant sur les aspects opérationnels, par exemple la
TESTING reprise (après incident), le comportement des ressources, la facilité
d’installation et la conformité technique
Ils sont effectués par le service d'exploitation ou le service d'administration du système dans un
environnement de production (simulé). Les tests se concentrent sur les aspects opérationnels et peuvent
inclure les éléments suivants :
✓ Tests de sauvegarde et de restauration ✓ Tâches de maintenance (correction anomalies résiduelles,
✓ Installation, désinstallation et mise à jour évolutions)
✓ Reprise après sinistre ✓ Tâches de chargement et de migration des données
✓ Gestion des utilisateurs (diffusion de l’application, gestion ✓ Vérification des vulnérabilités de sécurité
des droits) ✓ Tests de performance
OBJECTIFS DES TESTS D’ACCEPTATION OPÉRATIONNELLE
o Renforcer la confiance dans le fait que les opérateurs ou les administrateurs système peuvent maintenir le système en bon état
de fonctionnement pour les utilisateurs dans l'environnement opérationnel, même dans des conditions exceptionnelles ou
difficiles

2.2.4 - TEST D’ACCEPTATION 151


TESTS D’ACCEPTATION CONTRACTUELLE

Tests d'acceptation effectués pour vérifier si un système


TEST D’ACCEPTATION CONTRACTUELLE satisfait à ses exigences contractuelles.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Les TESTS D'ACCEPTATION CONTRACTUELLE sont effectués en fonction des critères d'acceptation d'un contrat pour
la production de logiciels sur mesure.
Les critères d'acceptation devraient être définis lorsque les parties conviennent du contrat.
✓ Engagement entre client et fournisseur.
✓ Les tests d'acceptation contractuelle sont souvent effectués par les utilisateurs ou par des testeurs
indépendants.

OBJECTIFS DES TESTS D’ACCEPTATION CONTRACTUELLE


o Renforcer la confiance dans l’atteinte de la conformité contractuelle.

2.2.4 - TEST D’ACCEPTATION 152


TESTS D’ACCEPTATION RÉGLEMENTAIRE

Tests d'acceptation effectués pour vérifier si un système est


TEST D’ACCEPTATION RÉGLEMENTAIRE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

conforme aux lois, politiques et règlements applicables.

Les TESTS D'ACCEPTATION RÉGLEMENTAIRE sont effectués par rapport à tous les règlements qui doivent être
respectés, comme les règlements gouvernementaux, légaux ou de sécurité.
✓ Standards liés à une activité (comptabilité, sécurité routière…)
✓ Textes législatifs (CNIL / RGPD...)
✓ Loi sur l’accès à tous l’information (Handicap / RGAA)
Les tests d'acceptation réglementaire sont souvent effectués par les utilisateurs ou par des testeurs
indépendants, les résultats étant parfois observés ou vérifiés par des organismes de réglementation.

OBJECTIFS DES TESTS D’ACCEPTATION RÉGLEMENTAIRE


o Renforcer la confiance dans l’atteinte de la conformité réglementaire.

2.2.4 - TEST D’ACCEPTATION 153


TESTS D’ACCEPTATION ALPHA ET BÊTA (1/2)
Les tests alpha et bêta sont généralement utilisés par les développeurs de logiciels
commerciaux sur étagère (COTS) qui souhaitent obtenir une évaluation des utilisateurs,
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

clients et/ou opérateurs potentiels ou existants avant que le produit logiciel ne soit mis
sur le marché.
LOGICIEL COMMERCIAL SUR ÉTAGÈRE Produit logiciel qui est développé pour le marché de façon
OU COTS POUR COMMERCIAL OFF-THE-SHELF générale, c'est-à-dire pour un grand nombre de clients, et qui
SOFTWARE est livré à de nombreux clients dans un format identique.

Test opérationnel réel ou simulé conduit dans l’environnement de test du


TEST D’ACCEPTATION ALPHA développement par des rôles en dehors de ceux de l’organisation en
charge du développement.

✓ effectués sur le site de l'organisation qui développe, non pas par l'équipe de développement, mais par des
clients potentiels ou existants, et/ou des opérateurs ou une équipe de test indépendante.

2.2.4 - TEST D’ACCEPTATION 154


TESTS D’ACCEPTATION ALPHA ET BÊTA (2/2)
TEST D’ACCEPTATION BÊTA Tests opérationnels simulés ou réels effectués sur un site externe, par
des rôles à l'extérieur de l'organisation de développement.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OU TEST TERRAIN

✓ effectués par des clients potentiels ou existants, et/ou des opérateurs sur leurs propres sites.

OBJECTIFS DES TESTS D’ACCEPTATION ALPHA ET BÊTA


o Renforcer la confiance des clients potentiels ou existants et/ou des opérateurs dans l’utilisation du système
dans des conditions normales et quotidiennes et dans l'environnement opérationnel pour atteindre leurs
objectifs avec un minimum de difficulté, de coût et de risque.
o Détecter des défauts liés aux conditions et aux environnements dans lesquels le système sera utilisé, en
particulier lorsque ces conditions et environnements sont difficiles à reproduire par l'équipe de
développement.

2.2.4 - TEST D’ACCEPTATION 155


TEST D’ACCEPTATION – BASES DE TEST

BASES DE TEST BASES DE TEST POUR TA OPÉRATIONNELLE


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓Processus métier ✓Procédures de sauvegarde et de restauration


✓Exigences utilisateur ou métier ✓Procédures de reprise après sinistre
✓Réglementations, contrats légaux et ✓Exigences non-fonctionnelles
normes
✓Documentation d'exploitation
✓Cas d’utilisation
✓Instructions de déploiement et d'installation
✓Exigences système
✓Objectifs de performance
✓Documentation système ou utilisateur
✓Ensembles de base de données
✓Procédures d'installation
✓Normes ou règlements de sécurité
✓Rapports d'analyse des risques

2.2.4 - TEST D’ACCEPTATION 156


TEST D’ACCEPTATION – OBJET DE TEST

OBJET DE TEST
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓Systèmes sous test


✓Configuration du système et données de configuration
✓Processus métier pour un système entièrement intégré
✓Systèmes de récupération et sites sensibles (pour les tests de continuité d'activité et de
reprise après sinistre)
✓Processus d'exploitation et de maintenance
✓Formulaires
✓Rapports
✓Données de production existantes et modifiées

2.2.4 - TEST D’ACCEPTATION 157


TEST D’ACCEPTATION - DÉFAUTS ET DÉFAILLANCES TYPES

DÉFAUTS ET DÉFAILLANCES TYPES


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓Les workflows du système ne répondent pas aux exigences métier ou utilisateurs


✓Les règles métier ne sont pas correctement implémentées
✓Le système ne satisfait pas aux exigences contractuelles ou réglementaires
✓Les défaillances non-fonctionnelles telles que les vulnérabilités de sécurité, le manque de
performance en cas de charges élevées, ou le mauvais fonctionnement sur une plate-forme
supportée

2.2.4 - TEST D’ACCEPTATION 158


TEST D’ACCEPTATION - APPROCHES ET RESPONSABILITÉS SPÉCIFIQUES

APPROCHES ET RESPONSABILITÉS SPÉCIFIQUES


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Responsabilités le plus souvent :


✓Clients
✓Utilisateurs métier
✓Product Owners
✓Exploitants d'un système
✓Autres parties prenantes impliquées

Le test d'acceptation est souvent considéré comme le dernier niveau de test dans un cycle de vie de
développement séquentiel, mais il peut aussi se produire à d'autres moments, par exemple :
✓ Les tests d'acceptation d'un produit logiciel COTS peuvent se produire lorsqu'il est installé ou intégré
✓ Le test d'acceptation d'une nouvelle amélioration fonctionnelle peut avoir lieu avant le test système

2.2.4 - TEST D’ACCEPTATION 159


TEST D’ACCEPTATION - APPROCHES ET RESPONSABILITÉS EN DÉVELOPPEMENT ITÉRATIF
Les tests d’acceptation peuvent s’effectuer :
1. Pendant une itération
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Exemple : vérifier une nouvelle fonctionnalité par rapport à ses critères d'acceptation.
2. A la fin de chaque itération
Exemple : valider qu'une nouvelle fonctionnalité satisfait les besoins des utilisateurs.
3. Après l’achèvement d’une itération.
Exemple: test alpha.
4. Après l’achèvement de plusieurs itérations.
Exemple : Test alpha.

1 3 4

Itération 1 Itération 2 Itération 3 Itération n

Tests d’Acceptation Utilisateur, Opérationnelle, Réglementaire, Contractuelle, Alpha & Bêta : en 2, 3 ou 4.

2.2.4 - TEST D’ACCEPTATION 160


2. TESTER PENDANT LE CYCLE DE VIE DU DÉVELOPPEMENT LOGICIEL

2.3 – TYPES DE TEST


OBJECTIF(S) DE CONNAISSANCE
❑ FL-2.3.1
(K2) Comparer les tests fonctionnels, non-fonctionnels et boîte-blanche
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ FL-2.3.2
(K1) Reconnaître que les tests fonctionnels, non-fonctionnels et boîte-blanche peuvent se
produire à n'importe quel niveau de test

❑ FL-2.3.3
(K2) Comparer les objectifs des tests de confirmation et des tests de régression

2.3 – TYPES DE TEST 162


TYPES DE TEST – DÉFINITION

Un type de test est un groupe d'activités de test basées sur des objectifs de test
TYPE DE TEST
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

spécifiques visant des caractéristiques spécifiques d'un composant ou d'un système.

Une cible particulière

2.3 – TYPES DE TEST 163


TYPES DE TEST – OBJECTIFS
Un type de test est focalisé sur un objectif de test particulier.
CES OBJECTIFS PEUVENT INCLURE :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

o Évaluer des caractéristiques de qualité fonctionnelle, telles que la complétude, l'exactitude


et la pertinence
o Évaluer des caractéristiques de qualité non-fonctionnelles, telles que la fiabilité, la
performance, la sécurité, la compatibilité et la facilité d'utilisation
o Évaluer si la structure ou l'architecture du composant ou du système est correcte, complète
et conforme aux spécifications
o Évaluer les effets des changements, tels que la confirmation de la correction de défauts
(tests de confirmation) et la recherche de changements non désirés résultant de
changements dans le logiciel ou l'environnement (tests de régression)

2.3 – TYPES DE TEST 164


TYPES DE TEST – NORME ISO 25010
ADÉQUATION FONCTIONNELLE PERFORMANCE RENDEMENT COMPATIBILITÉ UTILISABILITÉ
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

• Complétude • Temps de réponse • Coexistence • Intelligibilité


• Exactitude • Utilisation des • Interopérabilité • Apprentissage
• Aptitude à l’usage ressources • Opérabilité
• Protection contre les
erreurs
• Ergonomie
• Accessibilité

FIABILITÉ SÉCURITÉ MAINTENABILITÉ PORTABILITÉ

• Maturité • Confidentialité • Modularité • Adaptabilité


• Disponibilité • Intégrité • Réutilisabilité • Facilité d’installation
• Robustesse • Non rejet • Analysibilité • Interchangeabilité
• Récupérabilité • Responsabilité • Facilité de modification
• Authenticité • Testabilité

2.3 – TYPES DE TEST 165


TESTS FONCTIONNELS (1/2)
Test réalisé pour évaluer la conformité d'un composant ou d'un système aux
TEST FONCTIONNEL exigences fonctionnelles.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Les tests fonctionnels d'un système impliquent des tests qui évaluent les fonctionnalités que le
système devrait réaliser. Ce que le système doit faire
CAS
USER STORIES
D’UTILISATION

TA
SPÉCIFICATIONS
ÉPICS
FONCTIONNELLES
TS

TI
SPÉCIFICATIONS EXIGENCES NON
EXIGENCES
MÉTIER FONCTIONNELLES DOCUMENTÉES TC

2.3.1 - TESTS FONCTIONNELS 166


TESTS FONCTIONNELS (2/2)
Les tests fonctionnels d'un système impliquent des tests qui évaluent les fonctionnalités
que le système devrait réaliser.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

La couverture fonctionnelle est la mesure selon laquelle un certain type


d'élément fonctionnel a été exercé par des tests.
COUVERTURE FONCTIONNELLE
Elle est exprimée en pourcentage du ou des types d'éléments couverts.

COMPÉTENCES :
o Connaissance du problème métier particulier que le
logiciel résout
o Rôle particulier que joue le logiciel

2.3.1 - TESTS FONCTIONNELS 167


TESTS NON-FONCTIONNELS (1/2)

Test effectué pour évaluer la conformité d'un composant ou d'un


TEST NON-FONCTIONNEL système avec les exigences non fonctionnelles.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Pour mesurer les caractéristiques des systèmes et logiciels qui peuvent être quantifiées sur une échelle
variable, comme les temps de réponse.
Comment le système se comporte

USER STORIES
SPÉCIFICATIONS TA
ÉPICS NON
FONCTIONNELLES
TS

TI
SPÉCIFICATIONS
EXIGENCES NON- NON
EXIGENCES
FONCTIONNELLES DOCUMENTÉES
MÉTIER TC

2.3.2 - TESTS NON-FONCTIONNELS 168


TESTS NON-FONCTIONNELS (2/2)
Des techniques de boîte-noire peuvent être utilisées pour dériver des conditions de test et des
cas de test pour les tests non-fonctionnels.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

La mesure selon laquelle un certain type d'élément non-fonctionnel


a été exercé par des tests.
COUVERTURE NON-FONCTIONNELLE
Elle est exprimée en pourcentage du ou des types d'éléments
couverts.

COMPÉTENCES :
o Connaissance des faiblesses inhérentes à
une conception ou à une technologie
o Spécificité des utilisateurs

2.3.2 - TESTS NON-FONCTIONNELS 169


TESTS BOÎTE-BLANCHE (1/2)
Test basé sur une analyse de la structure interne du composant ou système.
TEST BOÎTE-BLANCHE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Synonymes : Test de boîtes transparentes, Test basé sur le code, Test de boîtes
(STRUCTUREL) de verre, Test de couverture logique, Test dirigé par la couverture logique, Test
structurel, Test basé sur la structure

COUVERTURE La mesure dans laquelle un certain type d'élément structurel a été exercé par
STRUCTURELLE des tests et est exprimée en pourcentage du type d'élément couvert
TESTS D’INTÉGRATION DES COMPOSANTS :
La couverture structurelle peut être mesurée en termes de TA
pourcentage d'interfaces exercées par les tests.
TS
TESTS DES COMPOSANTS :
La couverture du code est basée sur le pourcentage de TI
code du composant qui a été testé.
TC

2.3.3 – TESTS BOÎTE-BLANCHE 170


TESTS BOÎTE-BLANCHE (2/2)
COMPÉTENCES :
o Connaissance de la façon dont le code est construit (p. ex. utiliser des outils de
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

couverture de code)
o Connaissance de la façon dont les données sont stockées (p. ex. évaluer les requêtes
possibles dans les bases de données)
o Connaissance de la façon d'utiliser les outils de couverture et d'interpréter correctement
leurs résultats.

2.3.3 – TESTS BOÎTE-BLANCHE 171


TESTS LIÉS AUX CHANGEMENTS - INTRODUCTION

TEST DE CONFIRMATION Tests dynamiques effectués après la correction de défauts dans le but de
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OU RETEST confirmer que les défaillances causées par ces défauts ne se produisent plus.

Tests d’un programme préalablement testé, après une modification, pour


TEST DE RÉGRESSION s’assurer que des défauts n’ont pas été introduits ou découverts dans des
parties non modifiées du logiciel, comme suites des modifications effectuées.

TA

TS

TI

TC

2.3.4 - TESTS LIÉS AUX CHANGEMENTS 172


TESTS LIÉS AUX CHANGEMENTS – TEST DE CONFIRMATION
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

A minima, les étapes pour reproduire la(les) défaillance(s) causée(s) par le défaut
doivent être ré-exécutées sur la nouvelle version du logiciel.
Le but d'un test de confirmation est de confirmer que le défaut d'origine a été réparé
avec succès.
2.3.4 - TESTS LIÉS AUX CHANGEMENTS 173
TESTS LIÉS AUX CHANGEMENTS – TEST DE RÉGRESSION
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Les suites de tests de régression sont exécutées plusieurs fois et évoluent généralement
lentement, raison pour laquelle les tests de régression sont de bons candidats pour
l'automatisation. L'automatisation de ces tests devrait commencer tôt dans le projet.
Les tests de régression sont des tests visant à détecter des effets de bord involontaires
suite à une modification

2.3.4 - TESTS LIÉS AUX CHANGEMENTS 174


TESTS LIÉS AUX CHANGEMENTS – EN PHASE PROJET

Cycles de vie de développement itératif et incrémental (p. ex. en Agile) :


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

MODIFICATIONS
APPORTÉES AUX NOUVELLES
CARACTÉRISTIQUES CARACTÉRISTIQUES
EXISTANTES

REFACTORING
DU CODE
Tests de
confirmation

Tests de
régression
CHANGEMENTS FRÉQUENTS DU CODE

2.3.4 - TESTS LIÉS AUX CHANGEMENTS 175


TYPES DE TEST ET NIVEAUX DE TEST POUR UNE APPLICATION E-COMMERCE
Dans cet exemple nous allons prendre comme exemple le site de « CARREFOUR DRIVE ».
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

2.3.5 - TYPES DE TEST ET NIVEAUX DE TEST 176


LES TESTS FONCTIONNELS POUR UNE APPLICATION E-COMMERCE
TESTS FONCTIONNELS :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Pour les tests de composants


➢ Les tests sont conçus en fonction du code postal défini par l’utilisateur
✓ Pour les tests d'intégration de composants
➢ Les tests sont conçus en fonction de la façon dont les informations saisies au niveau de l'interface utilisateur sont transmises à
la couche métier. Par exemple, dans le cas du code postal c’est de vérifier que peut importe ce qui a été saisie : une réponse
est bien prévue (« 75000 » mais aussi « 75 » et encore « 7500 » ou « AAA »….)
✓ Pour les tests système
➢ Les tests sont conçus en fonction des créneaux disponibles pour le code postal et aussi pour le catalogue produit disponible.
✓ Pour les tests d'intégration au niveau système
➢ Les tests sont conçus en fonction de la façon dont le système utilise un micro-service externe pour vérifier la disponibilité du
produit pour le point drive choisi.
✓ Pour les tests d'acceptation
➢ Les tests sont conçus en fonction de la façon dont le système accepte de valider le panier (quantité suffisante ou à l’inverse
trop de produits).

2.3.5 - TYPES DE TEST ET NIVEAUX DE TEST 177


LES TESTS NON-FONCTIONNELS POUR UNE APPLICATION E-COMMERCE

TESTS NON-FONCTIONNELS :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Pour les tests de composants


➢ Les tests sont conçus pour évaluer le temps moyen d’affichage de la page d’accueil
✓ Pour les tests d'intégration de composants
➢ Les tests de sécurité sont conçus pour les vulnérabilités évaluer la taille critique d’un panier
✓ Pour les tests système
➢ Les tests de portabilité sont conçus pour vérifier si la couche de présentation fonctionne sur tous les navigateurs et appareils
mobiles supportés.
✓ Pour les tests d'intégration au niveau système
➢ Les tests de fiabilité sont conçus pour évaluer la robustesse du système lorsque le service de recherche produit ne répond
pas.
✓ Pour les tests d'acceptation
➢ Les tests d'utilisabilité sont conçus pour évaluer l'accessibilité du catalogue pour les personnes handicapées.
➢ Les tests de gestion de la confidentialité sont conçus pour prendre en compte les souhaits de l’utilisateur

2.3.5 - TYPES DE TEST ET NIVEAUX DE TEST 178


LES TESTS BOÎTE-BLANCHE POUR UNE APPLICATION E-COMMERCE
TESTS BOÎTE-BLANCHE :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Pour les tests de composants


➢ Les tests sont conçus pour obtenir une couverture complète de l’ensemble des instructions et des décisions pour les
composants qui ont une influence sur la sélection du magasin, afin de vérifier que toutes les combinaisons sont très bien
prises en compte ➔ « Code complet, Code complet mais inexistant, Code non conforme (alpha numérique de 5 chiffres)
✓ Pour les tests d'intégration de composants
➢ Les tests vont déterminer comment se comporte le système lorsque le composant de gestion du magasin est inopérant
✓ Pour les tests système
➢ Les tests sont conçus pour déterminer la couverture des pages Web depuis la transformation du panier jusqu’à la commande
définitive (choix du jour de livraison, moyen de paiement)
✓ Pour les tests d'intégration au niveau système
➢ Les tests sont conçus pour déterminer quels sont les produits qui seront affichés suite à la saisie d’un jeu de mots-clés via le
micro-service de recherche produit (vérification du paramétrage technique du micro-service de recherche).
✓ Pour les tests d'acceptation
➢ Les tests sont conçus pour vérifier que l’ensemble des services nécessaires à l’affichage d’un produit sont appelés dans le bon
ordre et avec une prise en charge cohérente des messages d’erreur techniques.

2.3.5 - TYPES DE TEST ET NIVEAUX DE TEST 179


LES LIÉS AUX CHANGEMENTS POUR UNE APPLICATION E-COMMERCE

TESTS LIÉS AUX CHANGEMENT :


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Pour les tests de composants


➢ Les tests de régression automatisés sont construits pour chaque composant et inclus dans le framework d’intégration
continue
✓ Pour les tests d'intégration de composants
➢ Les tests sont conçus pour confirmer les corrections des défauts liés à l'interface au fur et à mesure que ces corrections sont
intégrées dans le référentiel de code
✓ Pour les tests système
➢ Tous les tests du workflow du cycle complet d’achat de la connexion à la validation d’une commande vont être exécutés si l’un
des écrans a été impactés
✓ Pour les tests d'intégration au niveau système
➢ Les tests du système de gestion des disponibilités sont exécutées quotidiennement dans le cadre de la mise en place de
nouveaux points drive (entrepôts).
✓ Pour les tests d'acceptation
➢ Tous les tests échoués précédemment sont ré-exécutés après la correction d'un défaut constaté lors des tests d'acceptation.

2.3.5 - TYPES DE TEST ET NIVEAUX DE TEST 180


2. TESTER PENDANT LE CYCLE DE VIE DU DÉVELOPPEMENT LOGICIEL

2.4 TESTS DE MAINTENANCE


OBJECTIF(S) DE CONNAISSANCE
❑ FL-2.4.1
(K2) Résumer les événements déclencheurs des tests de maintenance
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ FL-2.4.2
(K2) Décrire le rôle de l'analyse d'impact dans les tests de maintenance

2.4 - TESTS DE MAINTENANCE 182


TESTS DE MAINTENANCE

Une fois déployés dans les environnements de production, les logiciels et les systèmes
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

doivent être maintenus.

Supprimer ou
Ajouter de
modifier des
nouvelles
fonctionnalités
fonctionnalités
déjà livrées
Performance

Corriger des Préserver ou Compatibilité


défauts améliorer les
découverts lors caractéristiques Fiabilité
de l'utilisation de qualité non-
opérationnelle Logiciels et fonctionnelles
systèmes Sécurité
maintenus Portabilité

2.4 - TESTS DE MAINTENANCE 183


TESTS DE MAINTENANCE

Test des modifications d’un système opérationnel ou de l’impact d’une


TEST DE MAINTENANCE modification d’environnement sur un système opérationnel.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

SUCCÈS DES
MODIFICATIONS
Versions planifiées

MODIFICATIONS
Corrections à chaud TESTS DE
MAINTENANCE
Versions non planifiées
VÉRIFIER LES EFFETS
SECONDAIRES POSSIBLES
(RÉGRESSIONS)

2.4 - TESTS DE MAINTENANCE 184


TESTS DE MAINTENANCE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

DEGRÉ DE RISQUE DU CHANGEMENT ETENDUE DES TESTS DE MAINTENANCE

TAILLE DU SYSTÈME EXISTANT


NIVEAUX DE TEST
TAILLE DU CHANGEMENT
TYPES DE TEST

2.4 - TESTS DE MAINTENANCE 185


FACTEURS DÉCLENCHEURS POUR LA MAINTENANCE

MODIFICATION MIGRATION DÉCLASSEMENT


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Application en fin de vie mise


Améliorations planifiées D'une plate-forme à une autre,
hors service
Changements correctifs et => tests opérationnels du => tester la migration ou
d'urgence nouvel environnement l'archivage des données
Changements de => tests de conversion de => tester les procédures de
l'environnement opérationnel données restauration / récupération
Mises à niveau de logiciels sur => Tests de régression pour
étagère (COTS) fonctionnalités restant en
Correctifs pour les défauts et service
les vulnérabilités

SYSTÈMES INTERNET DES OBJETS : les tests de maintenance peuvent être déclenchés par l'introduction d'objets
complètement nouveaux ou modifiés. Les tests de maintenance de ces systèmes mettent particulièrement
l'accent sur les tests d'intégration à différents niveaux et sur les aspects de sécurité, en particulier ceux
relatifs aux données personnelles.

2.4.1 FACTEURS DÉCLENCHEURS POUR LA MAINTENANCE 186


ANALYSE D'IMPACT POUR LA MAINTENANCE (1/2)
L'identification de tous les produits d’activités touchés par un changement, y
ANALYSE D’IMPACT incluant une estimation des ressources nécessaires pour accomplir le
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

changement [ISO 24765].

L'ANALYSE D'IMPACT évalue les changements qui ont été apportés pour une version de
maintenance afin d'identifier :
✓ les conséquences prévues ainsi que des effets secondaires attendus et possibles d'un
changement,
✓ les zones du système qui seront affectées par le changement,
✓ l'impact d'un changement sur les tests existants.
Elle peut être effectuée avant qu'un changement ne soit apporté, pour aider à
déterminer si le changement devrait être apporté en fonction des conséquences
potentielles dans d'autres parties du système.

2.4.2 ANALYSE D'IMPACT POUR LA MAINTENANCE 187


ANALYSE D'IMPACT POUR LA MAINTENANCE (2/2)
L'ANALYSE D'IMPACT peut être difficile si :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Les spécifications (p. ex., exigences métier, User Stories, architecture) sont obsolètes
ou manquantes
✓ Les cas de test ne sont pas documentés ou sont obsolètes
✓ La traçabilité bidirectionnelle entre les tests et les bases de test n'a pas été
maintenue
✓ Le support de l'outillage est faible ou inexistant
✓ Les personnes impliquées n'ont pas de connaissance du domaine et/ou du système
✓ Une attention insuffisante a été accordée à la maintenabilité du logiciel au cours du
développement

2.4.2 ANALYSE D'IMPACT POUR LA MAINTENANCE 188


ANALYSE D'IMPACT POUR LA MAINTENANCE - EXEMPLE
Exemple dans le cadre de la prise en compte d’une demande d’évolution.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Analyse
d’impact, Planification
Demande Estimation de la Développement, Mise en
Projet Livraison aux
d’évolution charge, production
Assignation au testeurs
développement

Capitaliser les
Analyse d’impact, Préparer les tests,
tests, Mettre à
Tests Évaluer les tests Valoriser et
jour le référentiel
de régression exécuter les tests
de test

2.4.2 ANALYSE D'IMPACT POUR LA MAINTENANCE 189


3. TESTS STATIQUES
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

3. TESTS STATIQUES
3.2 - PROCESSUS DE REVUE
3.1 - BASES DES TESTS STATIQUES
SOMMAIRE

191
3. TESTS STATIQUES

3.1 - BASES DES TESTS STATIQUES


OBJECTIF(S) DE CONNAISSANCE
❑ FL-3.1.1
(K1) Identifier les types de produits d'activité logiciels qui peuvent être examinés par les
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

différentes techniques de test statique

❑ FL-3.1.2
(K2) Utiliser des exemples pour décrire la valeur du test statique

❑ FL-3.1.3
(K2) Expliquer la différence entre les techniques statiques et dynamiques, en considérant les
objectifs, les types de défauts à identifier et le rôle de ces techniques dans le cycle de vie du
logiciel

3.1 BASES DES TESTS STATIQUES 193


TEST DYNAMIQUE VS TEST STATIQUE

Test qui nécessite l’exécution du logiciel d’un


TEST DYNAMIQUE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

composant ou système.

Tester un produit d’activités sans que le


TEST STATIQUE code soit exécuté.

3.1. BASES DES TESTS STATIQUES 194


BASES DES TESTS STATIQUES (1/2)
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TESTS STATIQUES

ANALYSE
REVUES ✓ SI critiques pour la sûreté,
STATIQUE ✓ Tests de sécurité,
✓ Systèmes automatisés de build / livraison,
Evaluation outillée
Examen manuel
du code ou ✓ …
des produits
d'autres produits
d’activités
d’activités Livraison en continu
Déploiement en continu

3.1. BASES DES TESTS STATIQUES 195


BASES DES TESTS STATIQUES (2/2)

Type de tests statiques au cours desquels un produit d’activités ou un


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

REVUE processus de travail est évalué par une ou plusieurs personnes afin de
détecter les problèmes et d'apporter des améliorations [IEEE 1028].

Processus d'évaluation d'un composant ou d'un système sans l'exécuter, en


ANALYSE STATIQUE fonction de sa forme, de sa structure, de son contenu ou de sa
documentation [ISO 24765].

3.1. BASES DES TESTS STATIQUES 196


PRODUITS D’ACTIVITÉS QUI PEUVENT ÊTRE EXAMINÉS PAR DES TESTS STATIQUES
LES SPÉCIFICATIONS, Y
COMPRIS LES EXIGENCES LES SPÉCIFICATIONS
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

LES ÉPICS, USER STORIES,


MÉTIER, LES EXIGENCES D'ARCHITECTURE ET DE
ET CRITÈRES D’ACCEPTATION
FONCTIONNELLES ET LES CONCEPTION
EXIGENCES DE SÉCURITÉ

LE TESTWARE, Y COMPRIS
LES PLANS DE TEST, LES CAS
LE CODE DE TEST, LES PROCÉDURES LES GUIDES UTILISATEUR
DE TEST ET LES SCRIPTS DE
TEST AUTOMATISÉS

LES MODÈLES, TELS QUE LES


LES CONTRATS, LES PLANS
DIAGRAMMES D'ACTIVITÉ,
DE PROJET, LES
LES PAGES WEB QUI PEUVENT ÊTRE UTILISÉS
CALENDRIERS ET LES
POUR LES TESTS BASÉS SUR
BUDGETS
DES MODÈLES

3.1.1 - PRODUITS D’ACTIVITÉS QUI PEUVENT ÊTRE EXAMINÉS PAR DES TESTS STATIQUES 197
BÉNÉFICES DES TESTS STATIQUES
1. Appliqués tôt dans le cycle de vie du développement du logiciel, les tests statiques permettent la détection en
BÉNÉFICES amont des défauts
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

2. Détection et correction plus efficace des défauts, avant l'exécution des tests dynamiques

3. Identification des défauts qui ne sont pas facilement décelables par des tests dynamiques

4. Prévention des défauts de conception ou de codage par la découverte d'incohérences, d'ambiguïtés, de


contradictions, d'omissions, d'inexactitudes et de redondances dans les exigences
5. Augmentation de la productivité du développement (par exemple, grâce à une meilleure conception, à un code
plus facile à maintenir)

6. Réduction des coûts et des délais de développement

7. Réduction des coûts et des délais des tests

8. Réduction du coût total de la qualité tout au long de la durée de vie du logiciel, grâce à la réduction du nombre
de défaillances plus tard dans le cycle de vie ou après la mise en service

9. Amélioration de la communication entre les membres de l'équipe au cours de la participation aux revues

3.1.2 - BÉNÉFICES DES TESTS STATIQUES 198


DIFFÉRENCES ENTRE LES TESTS STATIQUES ET DYNAMIQUES
Les tests statiques et dynamiques peuvent avoir les mêmes objectifs. Ils se complètent
mutuellement en trouvant différents types de défauts. Les principales distinctions sont les
suivantes :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TESTS STATIQUES TESTS DYNAMIQUES

Détectent directement les défauts dans les Identifient les défaillances causées par des défauts
produits d'activités lorsque le logiciel est exécuté

Difficulté de construire et d’exécuter un test


Peuvent permettre de trouver le défaut avec
dynamique qui mette en évidence un défaut
beaucoup moins d'efforts
difficile à atteindre

Peuvent être utilisés pour améliorer la cohérence Se concentrent généralement sur les
et la qualité interne des produits d'activités comportements visibles de l'extérieur

3.1.3 DIFFÉRENCES ENTRE LES TESTS STATIQUES ET DYNAMIQUES 199


LES DÉFAUTS CLASSIQUES DES TESTS STATIQUES
TYPE DE DÉFAUTS EXEMPLES
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Défauts dans les exigences Incohérences, ambiguïtés, contradictions, omissions, inexactitudes et redondances
Algorithmes ou structures de base de données inefficaces, taux de dépendance élevé,
Défauts dans la conception
faible cohésion
Variables avec des valeurs non définies, variables déclarées mais jamais utilisées, code
Défauts dans le code
inatteignable, code dupliqué
Ecarts par rapport aux normes Non-respect des règles de codage
Spécifications d'interface incorrectes Unités de mesure utilisées par le système appelant différentes de celles utilisées par le
système appelé
Vulnérabilités de sécurité Sensibilité aux débordements de la mémoire tampon
Lacunes ou inexactitudes dans la
traçabilité ou la couverture des bases de Des tests manquants pour un critère d'acceptation
test
Une modularité inadéquate, une mauvaise réutilisation des composants, un code difficile
La plupart des défauts de maintenabilité
à analyser et à modifier sans introduire de nouveaux défauts

HABITUELLEMENT PLUS FACILES ET MOINS COÛTEUX À TROUVER ET DONC À CORRIGER

3.1.3 DIFFÉRENCES ENTRE LES TESTS STATIQUES ET DYNAMIQUES 200


3. TESTS STATIQUES

3.2 - PROCESSUS DE REVUE


OBJECTIF(S) DE CONNAISSANCE
❑ FL-3.2.1
(K2) Résumer les activités du processus de revue de produits d'activité
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ FL-3.2.2
(K1) Identifier les différents rôles et responsabilités d'une revue formelle

❑ FL-3.2.3
(K2) Expliquer les différences entre les différents types de revue : revue informelle, relecture
technique, revue technique, et inspection

❑ FL-3.2.4
(K3) Appliquer une technique de revue sur un produit d'activités afin d'y trouver des défauts

❑ FL-3.2.5
(K2) Expliquer les facteurs contribuant au succès des revues

3.2 PROCESSUS DE REVUE 202


PROCESSUS DE REVUE

Une forme de revue qui suit un processus défini avec une documentation
REVUE FORMELLE formelle des résultats [ISO 20246].
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Les revues varient d’informelles à formelles

• Ne suivent pas un processus défini


• N'ont pas de résultats formels documentés.
INFORMELLES
Formalisation

• Participation de l'équipe
• Documentation des résultats de la revue
FORMELLES • Documentation des procédures pour la conduite de la revue

Norme ISO (ISO/CEI 20246) : descriptions plus détaillées du processus de revue

3.2 PROCESSUS DE REVUE 203


PROCESSUS DE REVUE DE PRODUITS D’ACTIVITÉS
Le processus de revue comprend les principales activités suivantes :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

1. Planification
• Définir le périmètre, qui comprend le but de la revue, les documents ou parties de
documents à revoir et les caractéristiques de qualité à évaluer
• Estimer l'effort et le temps requis
• Identifier les caractéristiques de la revue telles que le type de revue avec les rôles, les
activités et les checklists
• Sélectionner les personnes qui participeront à la revue et attribuer des rôles
• Définir des critères d'entrée et de sortie pour les types de revue plus formels (p. ex.
inspections)
• Vérifier que les critères d'entrée soient satisfaits (pour les types de revue plus formels)

3.2.1 – PROCESSUS DE REVUE DE PRODUITS D’ACTIVITÉS 204


PROCESSUS DE REVUE DE PRODUITS D’ACTIVITÉS

2. LANCEMENT DE LA REVUE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

• Distribuer le produit d'activités (physiquement ou par voie électronique) et d'autres


documents, comme des formulaires de saisie des défauts, des checklists et des produits
d'activités connexes
• Expliquer le périmètre, les objectifs, le processus, les rôles et les produits d'activités aux
participants
• Répondre à toutes les questions que les participants peuvent avoir au sujet de la revue

3. Revue individuelle (préparation individuelle)


• Revoir tout ou partie du produit d'activités
• Noter les défauts potentiels, les recommandations et les questions

3.2.1 – PROCESSUS DE REVUE DE PRODUITS D’ACTIVITÉS 205


PROCESSUS DE REVUE DE PRODUITS D’ACTIVITÉS
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

4. COMMUNICATION ET ANALYSE DES PROBLÈMES

• Communiquer les défauts potentiels identifiés (p. ex. lors d'une réunion de revue)
• Analyser les défauts potentiels, leur affecter un responsable et un statut
• Évaluer et documenter les caractéristiques de qualité
• Évaluer les résultats de la revue en fonction des critères de sortie pour prendre une
décision de revue (rejet ; changements majeurs nécessaires ; acceptation, éventuellement
avec des changements mineurs)

3.2.1 – PROCESSUS DE REVUE DE PRODUITS D’ACTIVITÉS 206


PROCESSUS DE REVUE DE PRODUITS D’ACTIVITÉS

5. CORRECTION ET PRODUCTION DE RAPPORTS


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

• PRODUIRE DES RAPPORTS DE DÉFAUTS POUR LES CONSTATATIONS QUI NÉCESSITENT DES CHANGEMENTS
• CORRIGER LES DÉFAUTS TROUVÉS (CORRECTION GÉNÉRALEMENT RÉALISÉE PAR L'AUTEUR) DANS LE PRODUIT
D'ACTIVITÉS REVU
• COMMUNIQUER LES DÉFAUTS À LA PERSONNE OU À L'ÉQUIPE CONCERNÉE (LORSQU'ILS SE TROUVENT DANS
UN PRODUIT D'ACTIVITÉS LIÉ AU PRODUIT D'ACTIVITÉS REVU)
• ENREGISTRER L'ÉTAT ACTUALISÉ DES DÉFAUTS (DANS LES REVUES FORMELLES), Y COMPRIS ÉVENTUELLEMENT
L'ACCORD DE L'AUTEUR DU COMMENTAIRE CONCERNÉ
• RECUEILLIR DES MÉTRIQUES (POUR LES TYPES DE REVUE PLUS FORMELS)
• VÉRIFIER QUE LES CRITÈRES DE SORTIE SONT SATISFAITS (POUR LES TYPES DE REVUE PLUS FORMELS)
• ACCEPTER LE PRODUIT D'ACTIVITÉS LORSQUE LES CRITÈRES DE SORTIE SONT SATISFAITS

3.2.1 – PROCESSUS DE REVUE DE PRODUITS D’ACTIVITÉS 207


RÔLES ET RESPONSABILITÉS DANS UNE REVUE FORMELLE
¤ Est responsable de la planification de la revue
¤ Experts du domaine, personnes
¤ Décide de la mise en œuvre des revues
travaillant sur le projet, intervenants ayant
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

¤ Affecte le personnel, le budget et le temps


un intérêt pour le produit d’activités,
¤ Vérifie le rapport coût-efficacité en continu
personnes ayant des compétences
Manager techniques ou métier spécifiques
¤ Prend la responsabilité générale de la revue ¤ Identifient les défauts potentiels du
¤ Décide qui sera impliqué et organise quand et où
produit d’activités à revoir
elle aura lieu
¤ Peuvent représenter différentes
perspectives (testeur, programmeur,
¤ Crée le produit d'activités revu Responsable utilisateur, opérateur, analyste métier,
¤ Corrige les défauts du produit d’activités revu (si de la revue expert en utilisabilité, etc.).
nécessaire)

Facilitateur Scribe
Auteur(s) Réviseur(s)
(modérateur) (rapporteur)

¤ Assure le bon déroulement des réunions de revue (quand elles ont lieu) ¤ Recueille les défauts potentiels découverts
¤ Fait la médiation, si nécessaire, entre les différents points de vue ¤ Enregistre les nouveaux défauts potentiels, les
¤ Est souvent la personne dont dépend le succès de la revue points en suspens et les décisions prises

3.2.2 – RÔLES ET RESPONSABILITÉS DANS UNE REVUE FORMELLE 208


TYPES DE REVUE (1/2)
Liste des quatre types de revues les plus courants et les caractéristiques qui leur sont
associées
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

REVUE INFORMELLE Un type de revue qui n’est pas basée sur une procédure formelle
(documentée) [ISO 20246].

RELECTURE TECHNIQUE Type de revue dans laquelle un auteur conduit la revue en parcourant
avec les participants un produit d’activités. Les participants posent des
OU RELECTURE TECHNIQUE questions et font des commentaires sur des problèmes possibles [ISO
STRUCTURÉE 20246].

3.2.3 - TYPES DE REVUE 209


TYPES DE REVUE (2/2)

Type d'examen officiel effectué par une équipe de personnel qualifié sur
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

REVUE TECHNIQUE le plan technique qui examine l'adéquation d'un produit d’activités à
l'usage pour l'usage auquel il est destiné et identifie les divergences par
rapport aux spécifications et aux normes [Gilb and Graham, IEEE 1028]

Un type de revue formelle visant à identifier les problèmes d'un produit


INSPECTION d’activités, qui fournit des mesures pour améliorer le processus de revue
et le processus de développement de logiciels [ISO 20246].

3.2.3 - TYPES DE REVUE 210


TYPES DE REVUE - REVUE INFORMELLE

REVUE INFORMELLE Par un collègue, en binôme, revue de pair


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OBJECTIF PRINCIPAL : détecter d’éventuels défauts


AUTRES OBJECTIFS POSSIBLES : générer de nouvelles idées ou solutions, résoudre
rapidement des problèmes mineurs
✓ Ne repose pas sur un processus formel (documenté)
✓ Peut ne pas comporter de réunion de revue
✓ Peut être effectué par un collègue de l'auteur ou par d'autres personnes
✓ Les résultats peuvent être documentés
✓ L'utilité varie selon les réviseurs
✓ L'utilisation de checklists est facultative
✓ Très couramment utilisé dans le développement Agile

3.2.3 - TYPES DE REVUE 211


TYPES DE REVUE - RELECTURE TECHNIQUE

RELECTURE TECHNIQUE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

PRINCIPAUX OBJECTIFS : trouver des défauts, améliorer le produit logiciel, envisager des
implémentations alternatives, évaluer la conformité aux normes et aux spécifications
AUTRES OBJECTIFS POSSIBLES : échange d'idées sur des techniques ou des variations de
style, formation des participants, obtention d'un consensus
✓ La préparation individuelle avant la réunion de revue est facultative
✓ La réunion de revue est généralement dirigée par l'auteur du produit d’activités
✓ Le rôle de scribe est obligatoire
✓ L'utilisation de checklists est facultative
✓ Peut prendre la forme de scénarios, d’essais à blanc ou de simulations
✓ Des rapports de défauts et des rapports de revue peuvent être produits
✓ Peut varier dans la pratique de plutôt informel à très formel

3.2.3 - TYPES DE REVUE 212


TYPES DE REVUE - REVUE TECHNIQUE

REVUE TECHNIQUE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

PRINCIPAUX OBJECTIFS : obtention d'un consensus, détection de défauts potentiels


AUTRES OBJECTIFS POSSIBLES : évaluer la qualité et renforcer la confiance dans le produit d’activités,
générer de nouvelles idées, motiver et permettre aux auteurs d'améliorer les produits d’activités
futurs, envisager des implémentations alternatives
✓ Les réviseurs doivent être des pairs techniques de l'auteur et des experts techniques dans la
même discipline ou dans d'autres disciplines
✓ Une préparation individuelle avant la réunion de revue est requise
✓ Réunion de revue facultative, de préférence dirigée par un facilitateur formé (généralement
pas l'auteur)
✓ Le rôle de scribe est obligatoire, de préférence pas l'auteur
✓ L'utilisation de checklists est facultative
✓ Des rapports de défauts et des rapports de revue sont généralement produits

3.2.3 - TYPES DE REVUE 213


TYPES DE REVUE - INSPECTION (1/2)

INSPECTION (1/2)
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

PRINCIPAUX OBJECTIFS : détecter les défauts potentiels, évaluer la qualité et renforcer la confiance
dans le produit d’activités, prévenir de futurs défauts similaires par l'apprentissage de l'auteur
et l'analyse des causes racines
AUTRES OBJECTIFS POSSIBLES : motiver et permettre aux auteurs d'améliorer les futurs produits
d’activités et le processus de développement de logiciels, parvenir à un consensus
✓ Suit un processus défini avec des résultats formels documentés, basé sur des règles et des
checklists
✓ Utilise des rôles clairement définis, comme ceux spécifiés à la section 3.2.2 qui sont
obligatoires, et peut inclure un lecteur spécialisé (qui lit le produit d’activités à haute voix
pendant la réunion de revue)
✓ Une préparation individuelle avant la réunion de revue est requise

3.2.3 - TYPES DE REVUE 214


TYPES DE REVUE - INSPECTION (2/2)

INSPECTION (2/2)
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Les réviseurs sont soit des pairs de l'auteur, soit des experts dans d'autres disciplines
pertinentes pour le produit d’activités concerné
✓ Des critères d'entrée et de sortie spécifiés sont utilisés
✓ Le rôle de scribe est obligatoire
✓ La réunion de revue est dirigée par un facilitateur formé (pas l'auteur)
✓ L'auteur ne peut pas agir à titre de responsable de la revue, de lecteur ou de scribe
✓ Des rapports de défauts et des rapports de revue sont produits
✓ Des métriques sont collectées et utilisées pour améliorer l'ensemble du processus de
développement logiciel, y compris le processus d'inspection

3.2.3 - TYPES DE REVUE 215


APPLICATION DES TECHNIQUES DE REVUE
Il existe un ensemble de techniques de revue qui peuvent être appliquées au cours de l'activité de
revue individuelle (c.-à-d., préparation individuelle) pour découvrir des défauts :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Revue Ad Hoc

Revue basée sur des scénarios

Revue basée sur une checklist

Revue basée sur des rôles

Lecture basée sur la perspective

3.2.4 - APPLICATION DES TECHNIQUES DE REVUE 216


REVUE AD HOC
Technique de revue réalisée par des examinateurs indépendants de manière
REVUE AD HOC informelle, sans processus structuré. [ISO 20246]
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TECHNIQUE DE REVUE : AD HOC


✓ Les réviseurs reçoivent peu ou pas de directives sur la façon dont cette tâche devrait être accomplie.
✓ Les réviseurs examinent généralement le produit d’activités de façon séquentielle, en identifiant et en
documentant les problèmes au fur et à mesure qu'ils les rencontrent.
✓ La révision ad hoc est une technique couramment utilisée qui nécessite peu de préparation.
✓ Cette technique dépend fortement des compétences des réviseurs et peut donner lieu à des constats qui
font double emploi car signalés par différents réviseurs.

3.2.4 - APPLICATION DES TECHNIQUES DE REVUE 217


REVUE BASÉE SUR UNE CHECKLIST
Une technique de conception de tests basée sur l'expérience selon laquelle le
REVUE BASÉE SUR testeur expérimenté utilise une liste de haut niveau d'éléments à noter, à vérifier, ou
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

UNE CHECKLIST à se rappeler, ou un ensemble de règles ou de critères en fonction desquels un


produit doit être vérifié.

TECHNIQUE DE REVUE : BASÉE SUR LES CHECKLISTS


✓ C’est une technique systématique, pour laquelle les réviseurs détectent les problèmes sur la base de
checklist qui sont distribuées au début de la revue (par exemple, par le facilitateur).
✓ Une checklist consiste en une série de questions basées sur des défauts potentiels, qui peuvent être issus
de l'expérience.
✓ Les checklists devraient être spécifiques au type de produit d’activités examiné et devraient être mises à
jour régulièrement pour couvrir les types de problèmes qui ont été omis lors de revues précédentes.
✓ Le principal avantage de la technique basée sur les checklists est la couverture systématique des types de
défauts courants. Il faut prendre soin de ne pas simplement suivre la checklist lors de la revue
individuelle, mais aussi de rechercher des défauts en dehors de la checklist.

3.2.4 - APPLICATION DES TECHNIQUES DE REVUE 218


REVUE BASÉE SUR DES SCÉNARIOS

REVUE BASÉE SUR Technique de revue où la revue est guidée par la capacité du produit du travail à
réaliser des scénarios spécifiques. [ISO 20246]
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

DES SCÉNARIOS

TECHNIQUE DE REVUE : SCÉNARIOS ET ESSAIS À BLANC


✓ Les réviseurs reçoivent un guide structuré sur la façon de lire le produit d’activités.
✓ Une approche fondée sur des scénarios aide les réviseurs à effectuer des "essais à blanc" sur le produit
d’activités en fonction de l'utilisation prévue du produit d’activités (si le produit d’activités est documenté
dans un format approprié, comme les cas d'utilisation par exemple).
✓ Ces scénarios permettent aux réviseurs d’être mieux guidés sur la façon d'identifier des types de défauts
spécifiques qu’avec uniquement les éléments d’une checklist.
✓ Comme pour les revues basées sur des checklists, afin de ne pas manquer certains types de défauts (p.
ex., des caractéristiques manquantes), les réviseurs ne devraient pas être limités aux scénarios
documentés.

3.2.4 - APPLICATION DES TECHNIQUES DE REVUE 219


REVUE BASÉE SUR DES RÔLES

REVUE BASÉE SUR Technique de revue où les réviseurs évaluent un produit d’activités du point de vue
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

DES RÔLES des différents rôles des intervenants. [ISO 20246]

TECHNIQUE DE REVUE : BASÉE SUR LES RÔLES


✓ Une revue basée sur les rôles est une technique par laquelle les réviseurs évaluent le produit d’activités
du point de vue de rôles individuels des parties prenantes.
✓ Les rôles typiques comprennent des types d'utilisateurs finaux spécifiques (expérimentés,
inexpérimentés, seniors, enfants, etc.) et des rôles spécifiques dans l'organisation (administrateur
utilisateur, administrateur système, testeur de performance, etc.).

3.2.4 - APPLICATION DES TECHNIQUES DE REVUE 220


LECTURE BASÉE SUR LA PERSPECTIVE
Technique de revue par laquelle les réviseurs évaluent le produit du travail à partir
LECTURE BASÉE SUR de différents points de vue. [ISO 20246]
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

LA PERSPECTIVE
Synonyme : revue basée sur la perspective

TECHNIQUE DE REVUE : BASÉE SUR LA PERSPECTIVE


✓ Dans une lecture basée sur la perspective les réviseurs adoptent différents points de vue des parties prenantes dans le cadre
d'une revue individuelle.
✓ Les points de vue habituels des parties prenantes comprennent l'utilisateur final, le marketing, le concepteur, le testeur ou
les opérations.
✓ L'utilisation de différents points de vue des parties prenantes permet d'approfondir la revue individuelle avec moins de
doublons de défauts entre les réviseurs.
✓ Elle exige également que les réviseurs essaient d'utiliser le produit d’activités revu pour produire le produit qu'ils en
tireraient.
✓ De plus on s'attend à ce que des checklists soient utilisées.
✓ C’est la technique générale la plus efficace pour revoir des exigences et des produits d’activités techniques. Un facteur clé de
succès est l'inclusion et la prise en compte appropriée de différents points de vue des parties prenantes, en fonction des
risques.

3.2.4 - APPLICATION DES TECHNIQUES DE REVUE 221


APPLICATION DES TECHNIQUES DE REVUE (1/3)
ILLUSTRATION N°1
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Un testeur doit spécifier des tests d’intégration de composants. Les tests sont basés sur des spécifications
techniques complexes. Il souhaite s’assurer de l’exactitude et de la cohérence de ses spécifications de test.
Quel type de revue et quelle technique pourrait-il utiliser ?

3.2.4 – APPLICATION DES TECHNIQUES DE REVUE 222


APPLICATION DES TECHNIQUES DE REVUE (2/3)
ILLUSTRATION N°2
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Un projet (cycle de développement modèle en V) doit développer une nouvelle application d’achats de
produits sur internet. Des testeurs devant spécifier leurs tests système ont effectué plusieurs revues
informelles avec les analystes fonctionnels sur les spécifications fonctionnelles liées aux domaines métiers
de la logistique et des achats. Il ont remonté au responsable de test trois problèmes majeurs récurrents qui
ne sont pas résolus : incohérence des exigences notamment avec d’autres domaines métiers, exigences
non testables, non respect des normes de spécification des exigences fonctionnelles imposées par la
direction qualité.
Quel type de revue et quelle technique pourraient être mis en place afin d’analyser les spécifications
fonctionnelles des différents domaines métiers impactés, et ainsi éviter que ces problèmes ne se
propagent davantage aux autres spécifications fonctionnelles restant à écrire ?

3.2.4 – APPLICATION DES TECHNIQUES DE REVUE 223


APPLICATION DES TECHNIQUES DE REVUE (3/3)
ILLUSTRATION N°3
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Dans une équipe Agile, un testeur souhaite faire relire ses premiers cas de test par un testeur plus
expérimenté afin de vérifier s’ils sont bien spécifiés et leur cohérence par rapport aux autres cas de test
écrits par les autres testeurs et les développeurs.
Quel type de revue et quelle technique pourrait-il utiliser ?

3.2.4 – APPLICATION DES TECHNIQUES DE REVUE 224


FACTEURS DE RÉUSSITE DES REVUES
Facteurs de réussite organisationnels
• Chaque revue a des objectifs clairs, définis lors de la planification de la revue et utilisés
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

comme critères de sortie mesurables


• Le type de revue est choisi en fonction des objectifs, du type et du niveau des produits
d’activités logiciels, mais aussi en tenant compte des participants
• Toutes les techniques de revue utilisées, telles que la revue basée sur les checklists ou sur
les rôles, sont appropriées pour l'identification efficace des défauts dans le produit
d’activités à revoir
• Toutes les checklists utilisées couvrent les principaux risques et sont actualisées
• Les documents volumineux sont rédigés et révisés en petits morceaux, de sorte que le
contrôle de la qualité est réalisé en fournissant aux auteurs un feed-back précoce et
fréquent sur les défauts
• Les participants ont suffisamment de temps pour préparer
• Les revues sont planifiées avec un délai de notification suffisant
• Le management appuie le processus de revue (p. ex. en intégrant suffisamment de temps
pour les activités de revue dans les échéanciers des projets)

3.2.5 - FACTEURS DE RÉUSSITE DES REVUES 225


FACTEURS DE RÉUSSITE DES REVUES

Facteurs de succès liés aux participants aux revues (1/2)


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

• Le choix des bonnes personnes contribue à l'atteinte des objectifs de la revue, par
exemple, des personnes ayant des compétences ou des perspectives différentes, qui
peuvent utiliser le document comme intrant de leurs activités
• Les testeurs sont considérés comme des réviseurs appréciés qui contribuent à la revue et
aussi apprennent à propos du produit d’activités revu, ce qui leur permet de produire des
tests plus efficaces et de préparer ces tests plus tôt
• Les participants consacrent suffisamment de temps et d'attention aux détails
• Les revues sont effectuées sur de petits morceaux, de sorte que les réviseurs ne perdent
pas leur concentration pendant la revue individuelle et/ou la réunion de revue (quand
elle a lieu)
• Les défauts trouvés sont identifiés, compris et traités avec objectivité
• La réunion est bien gérée, de sorte que les participants considèrent qu'il s'agit d'une
utilisation efficace de leur temps

3.2.5 - FACTEURS DE RÉUSSITE DES REVUES 226


FACTEURS DE RÉUSSITE DES REVUES
Facteurs de succès liés aux participants aux revues (2/2)
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

• La revue est menée dans un climat de confiance ; le résultat ne sera pas utilisé pour
l'évaluation des participants
• Les participants évitent le langage corporel et les comportements qui pourraient indiquer
l'ennui, l'exaspération ou l'hostilité envers les autres participants
• Une formation adéquate est fournie, en particulier pour les types de revue plus formels
tels que les inspections
• Une culture de l'apprentissage et de l'amélioration des processus est encouragée

3.2.5 - FACTEURS DE RÉUSSITE DES REVUES 227


4 - TECHNIQUES DE TEST
SOMMAIRE

4.1 - CATÉGORIES DE TECHNIQUES DE TEST


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

4.2 - TECHNIQUES DE TEST BOÎTE-NOIRE


4.3 - TECHNIQUES DE TEST BOÎTE-BLANCHE
4.4 - TECHNIQUES DE TEST BASÉES SUR L'EXPÉRIENCE

4. TECHNIQUES DE TEST 229


4 - TECHNIQUES DE TEST

4.1 - CATÉGORIES DE TECHNIQUES DE TEST


OBJECTIF(S) DE CONNAISSANCE
❑ FL-4.1.1
(K2) Expliquer les caractéristiques, les points communs et différences entre les techniques de
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

test boîte-noire, boîte-blanche et basées sur l'expérience

4.1 CATÉGORIES DE TECHNIQUES DE TEST 231


CATÉGORIES DE TECHNIQUES DE TEST

L'objectif d'une TECHNIQUE DE TEST est d'aider à identifier les conditions de test, les cas de
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

test et les données de test.


Basée sur
l’expérience

Boîte
blanche

Boîte noire

TECHNIQUE DE TEST Procédure utilisée pour dériver et/ou sélectionner les cas de test.

4.1 CATÉGORIES DE TECHNIQUES DE TEST 232


CHOIX DES TECHNIQUES DE TEST
Le choix des techniques de test à utiliser dépend d'un certain nombre de facteurs :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Type de composant / système Types de risque Temps et budget

Complexité du composant / Modèle de cycle de vie du


Objectifs du test
système développement logiciel

Normes réglementaires Documentation disponible Utilisation prévue du logiciel

Connaissances et compétences Expérience antérieure de l'utilisation


Exigences client ou contractuelles
des testeurs des techniques de test

Types de défauts attendus dans le


Niveaux de risque Outils disponibles
composant ou le système

✓ Applicables à certains niveaux de test ou à tous les niveaux de test


✓ Généralement combinées pour la création des cas de test
✓ Peut varier de très informel à très formel (selon contexte, contraintes de temps, etc.)

4.1.1 CHOIX DES TECHNIQUES DE TEST 233


CATÉGORIES DE TECHNIQUES DE TEST ET LEURS CARACTÉRISTIQUES

TECHNIQUE DE TEST BOÎTE-NOIRE Procédure documentée pour élaborer et sélectionner des cas de tests
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OU TECHNIQUE BOÎTE NOIRE basés sur une analyse des spécifications, soit fonctionnelles soit non-
OU TECHNIQUE BASÉE SUR LES fonctionnelles, d’un composant ou système sans faire référence à ses
SPÉCIFICATIONS structures internes.

TECHNIQUE DE TEST BOÎTE-


BLANCHE Procédure permettant de dériver et/ou de sélectionner des cas de
OU TECHNIQUE DE TEST STRUCTUREL test sur la base d'une analyse de la structure interne d'un composant
OU TECHNIQUE DE TEST BASÉ SUR LA ou d'un système.
STRUCTURE

TECHNIQUE DE TEST BASÉE SUR Procédure pour obtenir et/ou sélectionner des cas de test basée sur
L’EXPÉRIENCE l'expérience du testeur, sa connaissance et son intuition.
OU TECHNIQUE BASÉE SUR L'EXPÉRIENCE

4.1.2 CATÉGORIES DE TECHNIQUES DE TEST ET LEURS CARACTÉRISTIQUES 234


TECHNIQUES DE TEST BOÎTE NOIRE
Les TECHNIQUES DE TEST BOÎTE NOIRE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ sont aussi appelées TECHNIQUES COMPORTEMENTALES ou TECHNIQUES BASÉES SUR LE


COMPORTEMENT
✓ sont basées sur une analyse de la base de test appropriée
✓ sont applicables aux tests fonctionnels et non-fonctionnels
✓ se concentrent sur les entrées et sorties de l'objet de test sans référence à sa
structure interne
Base de test Input

✓ Conditions de test
Techniques
✓ Cas de test
Boîte noire ✓ Données de test
✓ Couverture base de test

Output

4.1.2 CATÉGORIES DE TECHNIQUES DE TEST ET LEURS CARACTÉRISTIQUES 235


TECHNIQUES DE TEST BOÎTE BLANCHE
Les TECHNIQUES DE TEST BOÎTE BLANCHE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ sont aussi appelées TECHNIQUES STRUCTURELLES ou TECHNIQUES BASÉES SUR LA


STRUCTURE
✓ sont basées sur une analyse de l'architecture, de la conception détaillée, de la
structure interne ou du code de l'objet de test
✓ se concentrent sur la structure et le traitement à l'intérieur de l'objet de test
Objet de test

✓ Conditions de test
Techniques ✓ Cas de test
Boîte ✓ Données de test
blanche
✓ Couverture structure

4.1.2 CATÉGORIES DE TECHNIQUES DE TEST ET LEURS CARACTÉRISTIQUES 236


TECHNIQUES DE TEST BASÉES SUR L’EXPÉRIENCE
Les TECHNIQUES DE TEST BASÉES SUR L’EXPÉRIENCE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ tirent parti de l'expérience des développeurs, des testeurs et des utilisateurs


pour concevoir, implémenter et exécuter des tests
✓ sont souvent combinées à des techniques de test boîte-noire et boîte blanche.

✓ Concevoir les tests


✓ Conditions de test
Techniques ✓ Cas de test
Basées sur ✓ Données de test
l’expérience
✓ Implémenter les tests
✓ Exécuter les tests

4.1.2 CATÉGORIES DE TECHNIQUES DE TEST ET LEURS CARACTÉRISTIQUES 237


4. TECHNIQUES DE TEST

4.2 - TECHNIQUES DE TEST BOÎTE-NOIRE


OBJECTIF(S) DE CONNAISSANCE
❑ FL-4.2.1
(K3) Appliquer la technique des partitions d'équivalence pour produire des cas de test à partir
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

d'exigences données

❑ FL-4.2.2
(K3) Appliquer l'analyse des valeurs limites pour produire des cas de test à partir d'exigences données

❑ FL-4.2.3
(K3) Appliquer le test de tables de décision pour produire des cas de test à partir d'exigences données

❑ FL-4.2.4
(K3) Appliquer le test des transitions d'état pour produire des cas de test à partir d'exigences données

❑ FL-4.2.5
(K2) Expliquer comment produire des cas de test à partir d'un cas d'utilisation

4.2 TECHNIQUES DE TEST BOÎTE-NOIRE 239


TECHNIQUES DE TEST BOÎTE-NOIRE
Rappel du PRINCIPE SUR LES TESTS N°2 :
➢ LES TESTS EXHAUSTIFS SONT IMPOSSIBLES ➔ FOCALISER LES EFFORTS DE TEST
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Pour maintenir une couverture par les tests dans les meilleures conditions et dans
l'objectif de limiter le nombre de tests, l'application des techniques boîte-noire suivantes
est nécessaire :

Techniques boîte-noire
Analyse des Test des
Partitions Test de tables Test des cas
valeurs transitions
d'équivalence de décision d'utilisation
limites d'état

4.2 TECHNIQUES DE TEST BOÎTE-NOIRE 240


PARTITIONS D'ÉQUIVALENCE - DÉFINITION

PARTITION D’ÉQUIVALENCE Une portion d’un domaine d’entrée ou de sortie pour


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

laquelle le comportement d’un composant ou système est


OU CLASSE D’ÉQUIVALENCE
supposé être le même, basé sur ces spécifications.
Les PARTITIONS D'ÉQUIVALENCE divisent les données en partitions (également connues sous le
nom de CLASSES D'ÉQUIVALENCE) de telle sorte que tous les éléments d'une partition donnée
sont supposés être traités de la même manière.

Il convient ensuite d'identifier les tests nécessaires pour


COUVRIR TOUTES LES PARTITIONS D'ÉQUIVALENCE.

Il y a des partitions d'équivalence pour les valeurs


VALIDES et INVALIDES.

4.2.1 PARTITIONS D'ÉQUIVALENCE 241


PARTITIONS D'ÉQUIVALENCE - DÉMARCHE
Démarche pour identifier les cas de test à concevoir à partir d’une exigence :
1. Identifier dans l’exigence les données d’entrée par domaine.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

2. Pour chaque domaine, segmenter les données d’entrée par groupes (partitions) donnant les
mêmes résultats (données de sortie), aussi bien pour les valeurs valides que pour les valeurs
invalides.
3. Sélectionner une valeur de donnée par partition : une valeur de donnée d’entrée pour chaque
cas de test.
✓Chaque valeur doit appartenir à une et une seule partition d'équivalence

Toutes les valeurs d’une même partition ont une


forte probabilité de révéler les mêmes défaillances
4.2.1 PARTITIONS D'ÉQUIVALENCE 242
PARTITIONS D'ÉQUIVALENCE – VALIDES ET INVALIDES
Partitions d’équivalences valides / invalides
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

➢ Les VALEURS VALIDES sont des valeurs qui doivent être acceptées par le composant ou le
système.
→ Une partition d'équivalence contenant des valeurs valides est appelée "PARTITION
D'ÉQUIVALENCE VALIDE".

➢ Les VALEURS INVALIDES sont des valeurs qui doivent être rejetées par le composant ou le
système.
→ Une partition d'équivalence contenant des valeurs invalides est appelée "PARTITION
D'ÉQUIVALENCE INVALIDE".

4.2.1 PARTITIONS D'ÉQUIVALENCE 243


PARTITIONS D'ÉQUIVALENCE - PRINCIPES
➢ Les partitions d'équivalence sont applicables à tous les niveaux de test
➢ Les partitions peuvent être identifiées pour tout élément de données lié à l'objet de
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

test :
✓ les entrées,
✓ les sorties,
✓ les valeurs internes. Exemple : valeurs possibles d’un paramètre.
✓ les valeurs liées au temps. Exemple : les dates ; avant ou après un événement.
✓ les paramètres d'interface. Exemple : les composants intégrés testés pendant les tests d'intégration.
➢ Toute partition peut être divisée en sous-partitions si nécessaire
➢ Partitions d'équivalence invalides : elles doivent être testées individuellement, c'est-à-
dire qu'elles ne doivent pas être combinées avec d'autres partitions d'équivalence
invalides, afin de s'assurer que les défaillances ne sont pas masquées.
✓ Les défaillances peuvent être masquées lorsque plusieurs défaillances surviennent en même temps,
mais qu'une seule est visible, ce qui fait que les autres défaillances ne sont pas détectées.

4.2.1 PARTITIONS D'ÉQUIVALENCE 244


PARTITIONS D'ÉQUIVALENCE - EXEMPLE
Soit une exigence portant sur le calcul du taux d’imposition. Selon le niveau de revenus, le
taux d’imposition est différent :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

1. Jusqu’à 20.000 € inclus, la valeur du taux est de 2 % ;


2. Au-delà de 20.000 € et jusqu’à 35.000 € inclus, la valeur du taux est de 5 % ;
3. Au-delà à 35.000 €, la valeur du taux est de 9 %.

> 20.000 €
REVENUS Inférieurs à 0 0 à 20.000 € > 35.000 €
à 35.000 €

Taux Rejet 2% 5% 9%

Partitions en ]-∞.. -1] [0..20.000] [20 001..35.000] [35.001..+∞[


entrée Invalide Valide Valide Valide
Sélection d’une
-100 10.000 28.000 55.000
valeur par test

4.2.1 PARTITIONS D'ÉQUIVALENCE 245


PARTITIONS D'ÉQUIVALENCE - COUVERTURE
Couverture des partitions d’équivalence par les tests :
➢ Pour obtenir une couverture de 100%, les cas de test doivent couvrir toutes les partitions
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

identifiées (y compris les partitions invalides) en utilisant au moins une valeur de chaque
partition.
➢ Couverture mesurée = nombre de partitions d'équivalence testées par au moins une valeur,
divisé par le nombre total de partitions d'équivalence identifiées (exprimé en pourcentage).
Exemple :
> 20.000 €
REVENUS Inférieurs à 0 0 à 20.000 € > 35.000 €
à 35.000 €
Partitions en ]-∞.. -1] [0..20.000] [20 001..35.000] [35.001..+∞[
entrée Invalide Valide Valide Valide

Cas de test créés -100 X 21.000, 28.000 55.000

→ Couverture des partitions d’équivalence de 75 % (de 66 % pour les classes valides uniquement)

4.2.1 PARTITIONS D'ÉQUIVALENCE 246


PARTITIONS D'ÉQUIVALENCE – EXERCICE 1
Le prix de location d’un véhicule dépend de la durée de la location en jours :
1. De 1 à 6 jours inclus,
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

2. De 7 à 14 jours inclus,
3. De 15 à 30 jours inclus
4. Au-delà de 30 jours.

Q1 : quelles sont les partitions d’équivalence valides et invalides en entrée à identifier ?

Q2 : quel est le nombre minimum de cas de test requis pour couvrir toutes les partitions
d’équivalence valides ?

4.2.1 PARTITIONS D'ÉQUIVALENCE 247


PARTITIONS D'ÉQUIVALENCE – EXERCICE 2
Le prix de location d’un véhicule dépend de la durée de la location en jours et de la
distance parcourue :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Durée (en jours) : Distance (en km) :


1. De 1 à 6 jours inclus, 1. De 0 à 100 km inclus,
2. De 7 à 14 jours inclus, 2. De 101 à 200 km inclus,
3. De 15 à 30 jours inclus 3. Au-delà de 200 km.
4. Au-delà de 30 jours.
Q1 : quelles sont les partitions d’équivalence valides et invalides en entrée à identifier ?
Q2 : quels cas de test minimum sont requis pour couvrir toutes les partitions d’équivalence
valides ?
Q3 : quelle est la couverture de l’ensemble des partitions d’équivalence obtenue (avec les cas de
test obtenus précédemment) ?
Q4 : quels cas de test minimum sont requis pour couvrir toutes les partitions d’équivalence ?

4.2.1 PARTITIONS D'ÉQUIVALENCE 248


ANALYSE DES VALEURS LIMITES - DÉFINITION

Une technique de conception de tests boîte noire dans


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

ANALYSE DES VALEURS LIMITES laquelle les cas de tests sont conçus sur la base des valeurs
limites.

L'ANALYSE DES VALEURS LIMITES est une extension des partitions d'équivalence, mais ne peut
être utilisée que lorsque la partition est ordonnée, composée de données numériques ou
séquentielles.
Les valeurs minimale et maximale (ou première et dernière valeurs) d'une partition sont
ses VALEURS LIMITES.

4.2.2 ANALYSE DES VALEURS LIMITES 249


ANALYSE DES VALEURS LIMITES - DÉMARCHE
Démarche pour identifier les cas de test à concevoir à partir d’une exigence :
1. Identifier les partitions d’équivalence valides et invalides.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

2. Pour chaque partition d’équivalence, identifier les 2 valeurs limites par limite de la partition :
pour la limite minimum (A et B) et pour la limite maximum (E et F) de la partition.
3. Chaque valeur limite est utilisée pour un cas de test. Ce qui devrait produire jusqu’à 4 cas test
par partition d’équivalence.
4. Variante : identifier 3 valeurs limites par limite : les valeurs en-dessous, sur et juste au-dessus
de la limite (ajout C et D). Ce qui devrait produire jusqu’à 6 cas de test par partition.
Partition d’équivalence
MIN MAX
...... A B C ...... D E F ......

A B C D E F
VL en-dessous VL sur la VL au-dessus VL en-dessous VL sur la limite VL au-dessus de
de la limite MIN limite MIN de la limite MIN de la limite MAX MAX la limite MAX

4.2.2 ANALYSE DES VALEURS LIMITES 250


ANALYSE DES VALEURS LIMITES - PRINCIPES
➢ L'analyse des valeurs limites peut être appliquée à tous les niveaux de test.
➢ Le comportement aux limites des partitions d'équivalence est plus susceptible d'être
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

incorrect que le comportement à l'intérieur des partitions.


➢ Il est important de se rappeler que les limites spécifiées et implémentées peuvent être
décalées vers des positions supérieures ou inférieures à leurs valeurs prévues, être
oubliées où être complétées avec des limites supplémentaires non souhaitées. L'analyse
et le test des valeurs limites permettront de détecter presque tous ces défauts en
forçant le logiciel à exhiber des comportements pour une partition autre que celle à
laquelle la valeur limite devrait appartenir.
➢ Cette technique est généralement utilisée pour tester les exigences qui nécessitent une
série de valeurs numériques (y compris les dates et les heures).

4.2.2 ANALYSE DES VALEURS LIMITES 251


ANALYSE DES VALEURS LIMITES - EXEMPLE
> 20.000 €
REVENUS Inférieurs à 0 0 à 20.000 € > 35.000 €
à 35.000 €
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Taux Rejet 2% 5% 9%
Partitions en ]-∞.. -1] [0..20.000] [20 001..35.000] [35.001..+∞[
entrée Invalide Valide Valide Valide
Valeurs limites
dans la partition -1 0 et 20.000 20.001 et 35.000 35.001
(B et E)
Valeurs limites
hors partition 0 -1 et 20.001 20.000 et 35.001 35.000
(A et F)
Ajouts pour
variante 3 valeurs
-2 1 et 19.999 20.002 et 34.999 35.002
par limite
(C et D)

4.2.2 ANALYSE DES VALEURS LIMITES 252


ANALYSE DES VALEURS LIMITES - COUVERTURE
Couverture des limites d'une partition par les tests :
➢ Couverture des limites d'une partition = nombre de valeurs limites testées, divisé par le
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

nombre total de valeurs limites identifiées (exprimé en pourcentage).


Exemple : pour une analyse des valeurs limites à 2 valeurs par limite

> 20.000 €
REVENUS Inférieurs à 0 0 à 20.000 € > 35.000 €
à 35.000 €
Partitions en ]-∞.. -1] [0..20.000] [20 001..35.000] [35.001..+∞[
entrée Invalide Valide Valide Valide
Cas de test créés
-1, 0 -1, 0 20.001, 35.000 35.000
(VL utilisées)
Total VL -1, 0, 20.000, 20.000, 20.001,
-1, 0 35.000, 35.001
identifiées 20.001 35.000, 35.001
→ Couverture des limites des partitions de 66,6 % (idem pour les classes valides uniquement)

4.2.2 ANALYSE DES VALEURS LIMITES 253


ANALYSE DES VALEURS LIMITES – EXERCICE 1
Le prix de location d’un véhicule dépend de la durée de la location en jours (on suppose
qu’il est impossible d’obtenir des valeurs inférieures à 0) :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

1. De 1 à 6 jours inclus,
2. De 7 à 14 jours inclus,
3. De 15 à 30 jours inclus
4. Au-delà de 30 jours.

Q1 : quelles sont les valeurs limites en entrée à identifier par une analyse des valeurs
limites à deux valeurs par limite ?

Q2 : quelles sont les valeurs limites en entrée à identifier par une analyse des valeurs
limites à trois valeurs par limite ?

4.2.2 ANALYSE DES VALEURS LIMITES 254


ANALYSE DES VALEURS LIMITES – EXERCICE 2
Un outil de mesure accepte des valeurs entières (les valeurs non entières sont
impossibles) pour toute mesure se terminant par 1, 2 ou 3, pour une amplitude des
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

valeurs possibles à mesurer allant de 0 à 30. Les mesures acceptées sont donc 1, 2, 3, 11,
12, 13, 21, 22, 23 ; toutes les autres sont rejetées par le système (0, 4, 5,… , 9, 10, 14, 15,
… , 30)

Q1 : quelles sont les valeurs limites en entrée à identifier par une analyse des valeurs
limites à deux valeurs par limite pour les partitions valides et invalides ?

Q2 : quelles sont les valeurs limites en entrée à identifier par une analyse des valeurs
limites à trois valeurs par limite pour les partitions valides et invalides ?

4.2.2 ANALYSE DES VALEURS LIMITES 255


TEST DE TABLES DE DÉCISION - DÉFINITION
Une technique de conception des tests boîte noire dans
laquelle les cas de tests sont conçus pour exécuter les
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TEST PAR TABLES DE DÉCISIONS


combinaisons d’entrées et/ou de stimuli (causes) présentes
dans une table de décision [Egler63]
TABLE DE DÉCISION Un tableau utilisé pour montrer des ensembles de conditions et les
OU TABLE DE DÉCISION CAUSE-EFFET actions qui en résultent.

Le TEST DE TABLES DE DÉCISION est l’une des techniques de test combinatoire qui sont utiles
pour tester la mise en œuvre des exigences du système qui spécifient comment
différentes combinaisons de conditions donnent des résultats différents.
Les tables de décision sont un bon moyen pour répertorier les règles métier complexes
qu'un système doit mettre en œuvre.

4.2.3 TEST DE TABLES DE DÉCISION 256


TEST DE TABLES DE DÉCISION - DÉMARCHE
Démarche pour identifier les cas de test à concevoir à partir des exigences :
1. Identifier les CONDITIONS (souvent des entrées) et les ACTIONS RÉSULTANTES (souvent des sorties)
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

du système.
2. Identifier toutes les combinaisons possibles de conditions et le nombre de RÈGLES DE DÉCISION
en découlant.
Exemple de calcul du nombre de règles de décision :
Si vous avez des individus des deux sexes, regroupés en trois groupes d'âge et en trois niveaux de
revenus, 18 règles de décision (2 x 3 x 3) sont théoriquement possibles.
3. Construire la table de décision constituée de lignes en haut avec les conditions et en bas avec
les actions.
4. Chaque colonne correspond à une règle de décision qui définit une combinaison unique de
conditions qui aboutit à l'exécution des actions associées à cette règle.
5. Éventuellement réduire la table en supprimant des colonnes :
• contenant des combinaisons impossibles de conditions,
• contenant des combinaisons de conditions possibles mais irréalisables,
• qui testent des combinaisons de conditions qui n'affectent pas le résultat.
6. Concevoir au moins un cas type par colonne (règle de décision) dans la table.

4.2.3 TEST DE TABLES DE DÉCISION 257


TEST DE TABLES DE DÉCISION - PRINCIPES
➢ Force de la technique de test utilisant les tables de décision :
✓ permet d’identifier toutes les combinaisons importantes de conditions, dont
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

certaines pourraient sinon être négligées.


✓ permet également de trouver des lacunes dans les exigences.

➢ Cette technique peut être appliquée


✓ à toutes les situations dans lesquelles le comportement du logiciel dépend d'une
combinaison de conditions,
✓ à n'importe quel niveau de test.

4.2.3 TEST DE TABLES DE DÉCISION 258


TEST DE TABLES DE DÉCISION – EXEMPLE 1
Un assureur de véhicules détermine s’il accepte d’assurer un client, et à quel tarif.
CONDITIONS R1 R2 R3 R4 R5 R6 R7 R8
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Nombre d'accidents > N 0 1 0 1 0 1 0 1


Type de véhicule = {luxe, autre} 0 0 1 1 0 0 1 1
Age du véhicule > M 0 0 0 0 1 1 1 1

ACTIONS
→ Message « refus d'assurance »
X X X X
→ Retour au menu principal
→ Ok pour assurer
→ Sélection du taux standard
X
→ Vérification du tarif
→ Affichage des informations générales
→ Ok pour assurer
→ Sélection du taux spécial
X X X
→ Vérification du tarif
→ Affichage des informations générales

4.2.3 TEST DE TABLES DE DÉCISION 259


TEST DE TABLES DE DÉCISION – EXEMPLE 2
Calcul de la réduction du tarif de billets en transport ferroviaire.
CONDITIONS R1 R2 R3 R4 R5 R6 R7 R8
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

C1 : Avec des enfants F V F V F V F V


C2 : Nombre d’enfants > 2 F F V V F F V V
C3 : En première classe - F F F - V V V

ACTIONS

→ Pas de réduction X X X

→ Réduction de 20% X X

→ Réduction de 50% X

✓ Suppression des colonnes R3 et R7 car la combinaison C1 Fausse et C2 Vraie est impossible.


✓ Quand les conditions C1 et C2 sont faussent, la valeur de la condition C3 n’affecte pas le résultat
➢ Les colonnes R1 et R5 peuvent être fusionnées car elles représentent la même règle de décision.
✓ 5 cas de test suffisent pour les règles de décision R1, R2, R4, R6, R8.

4.2.3 TEST DE TABLES DE DÉCISION 260


TEST DE TABLES DE DÉCISION - COUVERTURE
COUVERTURE pour le test de tables de décision :
➢ La couverture minimale courante pour le test de tables de décision est d'avoir au
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

moins un cas type par règle de décision dans la table.


➢ Il s'agit généralement de couvrir toutes les combinaisons de conditions.
➢ Couverture = nombre de règles de décision testées par au moins un cas de test, divisé
par le nombre total de règles de décision (exprimé en pourcentage)
Exemple : déclenchement automatique de le fermeture des volets via programmateur :
CONDITIONS R1 R2 R3 R4
C1 : Programmation faite N O N O
C2 : Heure atteinte N N O O
ACTIONS
→ Déclencher fermeture des volets N N N O
Cas créés :
Cas 1 : C1 fausse et C2 fausse Cas 2 : C1 vraie et C2 vraie Cas 3 : C1 fausse et C2 vraie
→ Couverture de la table de décision de 75 % par les cas de test

4.2.3 TEST DE TABLES DE DÉCISION 261


TEST DE TABLES DE DÉCISION – EXERCICE
Un logiciel bancaire doit déterminer si l’autorisation de crédit est possible et le taux
d’emprunt. La spécification fonctionnelle établit les exigences suivantes pour un couple :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Si les revenus annuels du couple sont supérieurs à 48.000 € /an alors


Si le couple est propriétaire alors
Si la propriété est estimée à plus de 250.000 €
alors autorisation de crédit à 2%
Sinon autorisation de crédit à 3%
Sinon
Autorisation de crédit à 4%
Sinon
Crédit non autorisé.
Q1 : combien de cas de test sont nécessaires pour couvrir 100% des règles de décision
après réduction de la table de décision ?

4.2.3 TEST DE TABLES DE DÉCISION 262


TEST DES TRANSITIONS D'ÉTAT - DÉFINITION
Une technique de test de boîte-noire utilisant un
diagramme états-transitions ou une table d'état pour
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TEST DES TRANSITIONS D'ÉTAT


dériver des cas de test afin d'évaluer si l'élément de test
OU TEST DE MACHINES À ÉTATS FINIS
exécute avec succès des transitions valides et bloque les
transitions invalides

TRANSITION D’ÉTAT Une transition entre deux états d’un composant ou système.

Les composants ou les systèmes peuvent réagir différemment à un événement en


fonction des conditions présentes ou de leur historique (par exemple, les événements qui
se sont produits depuis l'initialisation du système).
L'historique antérieur peut être résumé à l'aide du concept D'ÉTATS. Un DIAGRAMME DE
TRANSITIONS D'ÉTAT (OU DIAGRAMME ÉTATS-TRANSITIONS) montre les états possibles du logiciel, ainsi
que la façon dont le logiciel entre, sort et évolue entre ces états.

4.2.4 TEST DES TRANSITIONS D'ÉTAT 263


TEST DES TRANSITIONS D'ÉTAT – PRINCIPES (1/2)
Il existe deux façon de représenter les états et les transitions :
➢ Un TABLEAU DE TRANSITION D'ÉTAT montre toutes les transitions valides et les transitions
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

potentiellement invalides entre les états, ainsi que les événements, les conditions de
garde et les actions résultantes pour les transitions valides.
➢ Les DIAGRAMMES DE TRANSITION D'ÉTATS ne montrent normalement que les transitions
valides et excluent les transitions invalides :
✓ Une transition est déclenchée par un ÉVÉNEMENT (par exemple, l'entrée d'une valeur par l'utilisateur
dans un champ).
✓ L'événement entraîne une TRANSITION.
✓ Si le même événement peut entraîner deux transitions différentes ou plus à partir d'un même état,
cet événement peut être qualifié par une CONDITION DE GARDE.
✓ Le changement d'état peut entraîner une ACTION du logiciel (par exemple, l'affichage du résultat d'un
calcul ou d'un message d'erreur).

4.2.4 TEST DES TRANSITIONS D'ÉTAT 264


TEST DES TRANSITIONS D'ÉTAT - PRINCIPES (2/2)
➢ Les tests peuvent être conçus :
✓ pour couvrir une séquence de plusieurs états,
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ pour exercer tous les états,


✓ pour exercer toutes les transitions,
✓ pour exercer des séquences spécifiques de transitions,
✓ pour tester des transitions invalides.
➢ Le test de transitions d'état est utilisé :
✓ pour les applications basées sur des menus,
✓ couramment dans l'industrie du logiciel embarqué,
✓ à la modélisation d'un scénario métier ayant des états spécifiques,
✓ pour tester la navigation à l'écran
✓ pour le cycle de vie d’objets (automates, objets de gestion, etc.)
➢ Le concept d’état est abstrait, il peut représenter quelques lignes de code ou un
processus métier entier.

4.2.4 TEST DES TRANSITIONS D'ÉTAT 265


TEST DES TRANSITIONS D'ÉTAT - DÉMARCHE
➢ Analyse de la base de test (exigence, spécification, User Story) :
✓ Identifier les différents états,
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Pour chaque état, identifier les actions possibles dans cet état, leurs conditions et
leurs conséquences (changement d'état).
✓ Concevoir le diagramme de transition d’états plutôt pour chercher à couvrir toutes
les transitions valides.
✓ Concevoir le tableau de transition d’états plutôt pour chercher à couvrir toutes les
transitions valides et invalides.

➢ Concevoir les tests :


✓ Au moins un test par transition (plus si nécessaire ; différentes profondeurs
possibles de 1 à N transitions couvertes),
✓ Des tests pour les chemins d'intérêt non couverts (transitions invalides).

4.2.4 TEST DES TRANSITIONS D'ÉTAT 266


TEST DES TRANSITIONS D'ÉTAT – EXEMPLE 1
Exemple de DIAGRAMME DE TRANSITION D’ÉTATS pour un distributeur de boissons instantanées
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Nœud initial Etat

Evénement

Action

Condition de garde

Condition

Transition

4.2.4 TEST DES TRANSITIONS D'ÉTAT 267


TEST DES TRANSITIONS D'ÉTAT – EXEMPLE 2 (1/2)
Exemple de DIAGRAMME DE TRANSITION D’ÉTATS pour un lavage automatique de véhicule
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

démarrer

4.2.4 TEST DES TRANSITIONS D'ÉTAT 268


TEST DES TRANSITIONS D'ÉTAT – EXEMPLE 2 (2/2)
Exemple de TABLEAU DE TRANSITION D'ÉTAT (lavage automatique de véhicule)
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Etat final >


Lavage Séchage Lustrage Attente Fin
Etat initial
˅

Début démarrer

Lavage after(4min) arrêt d’urgence

Séchage after(2min) arrêt d’urgence

after(2min)
Lustrage
arrêt d’urgence

Attente reprise reprise after(2min)

4.2.4 TEST DES TRANSITIONS D'ÉTAT 269


TEST DES TRANSITIONS D'ÉTAT – COUVERTURE
➢ COUVERTURE = nombre d'états ou de transitions identifiés testés, divisé par le nombre
total d'états ou de transitions identifiés dans l'objet de test (exprimé en pourcentage).
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Exemple : cas de test pour couvrir 100% des transitions valides (lavage automatique de
véhicule) :
Cas de
1 2 3 4 5 6 7 8 9 10
test >

Etat
début lavage séchage lustrage lavage séchage attente attente attente lustrage
initial

arrêt arrêt arrêt


Entrée démarrer after(4min) after(2min) after(2min)
d’urgence d’urgence
reprise reprise after(2min)
d’urgence

Etat
final lavage séchage lustrage fin attente attente lavage séchage fin fin
attendu

4.2.4 TEST DES TRANSITIONS D'ÉTAT 270


TEST DES TRANSITIONS D'ÉTAT – EXERCICE
➢ On doit tester la gestion de l’alarme (sonnerie) d’un réveil.
✓ Lorsque le réveil est allumé (action Power ON), le réveil affiche l’heure et l’alarme est OFF
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

(état S2-Affichage heure).


✓ L’action Power OFF permet d’éteindre le réveil (état S1-Réveil OFF) quelque soit son état de
fonctionnement.
✓ L’action Alarme ON permet de programmer l’heure de sonnerie et activer l’alarme (état S3-
Alarme programmée).
✓ Quand l’heure de sonnerie est atteinte, le réveil déclenche la sonnerie (état S4-Sonnerie).
✓ L’action Stop permet d’arrêter la sonnerie (retour à l’état S3-Alarme programmée).
✓ L’action Alarme OFF permet de déprogrammer l’alarme (retour à l ’état S2-Affichage heure).
➢ Q1 : combien de cas de test faut-il pour couvrir 100% des transitions valides (1 cas de test = 1
transition) ?
➢ Q2 : combien de cas de test faut-il pour couvrir 100% des transitions valides et invalides (1 cas
de test = 1 transition) ? NB : on ignore les transitions invalides qui bouclent sur le même état.

4.2.4 TEST DES TRANSITIONS D'ÉTAT 271


TEST DES CAS D'UTILISATION - DÉFINITION
TEST DES CAS D'UTILISATION
Technique de test boîte noire selon laquelle les cas de tests
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OU TESTS DE SCÉNARIOS
sont conçus pour exécuter des scénarios de cas d’utilisation.
OU TESTS DE SCÉNARIOS UTILISATEURS

Séquence de transactions dans un dialogue entre un acteur et un


composant ou un système avec un résultat concret. L'acteur peut être un
CAS D’UTILISATION utilisateur ou tout ce qui peut échanger des informations avec le
système.

Les tests peuvent être dérivés de CAS D'UTILISATION. Les cas d’utilisation sont une façon
spécifique de concevoir les interactions avec le logiciel pour représenter des exigences.
Les cas d'utilisation sont associés à des ACTEURS (utilisateurs humains, matériel externe ou
autres composants ou systèmes) et à des SUJETS (le composant ou système auquel le cas
d'utilisation est appliqué).

4.2.5 TEST DES CAS D'UTILISATION 272


TEST DES CAS D'UTILISATION – PRINCIPES
➢ Chaque cas d'utilisation spécifie un comportement qu'un sujet peut accomplir en collaboration
avec un ou plusieurs acteurs (UML 2.5.1 2017).
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

➢ Un cas d'utilisation peut être décrit par des interactions et des activités, ainsi que par des
préconditions, des post conditions et du langage naturel.
➢ Les interactions entre les acteurs et le sujet peuvent :
✓ entraîner des changements dans l'état du sujet.
✓ être représentées graphiquement par des flux de travail, des diagrammes d'activités ou des
modèles de processus métier.
➢ Un cas d'utilisation peut inclure des variations possibles de son comportement de base, y
compris un comportement exceptionnel et la gestion des erreurs (réponse du système et
récupération à la suite d'erreurs de programmation, au niveau de l'application et de
communication, par exemple, entraînant un message d'erreur).
➢ Les tests sont conçus pour exercer les comportements définis (comportement de base,
exceptionnel ou alternatif, et traitement des erreurs)

4.2.5 TEST DES CAS D'UTILISATION 273


TEST DES CAS D'UTILISATION – DÉMARCHE
Démarche pour identifier les cas de test à concevoir à partir des exigences :
1. Analyser les exigences dans la base de test
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

2. Identifier les acteurs


3. Identifier les sujets (ou étapes)
4. Construire un diagramme de cas d’utilisation au besoin
5. Dériver les cas de test pour :
1. Les comportements de base (cas nominaux),
2. Eventuellement les comportements alternatifs (cas exceptionnels ou alternatifs),
3. Eventuellement les traitements des erreurs.

4.2.5 TEST DES CAS D'UTILISATION 274


TEST DES CAS D'UTILISATION – EXEMPLE 1
Exemple de diagramme de cas d’utilisation :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Frontière du système
Borne interactive d’une banque
Nom du système

Retirer argent

Acteur
Effectuer
Cas d’utilisation
Client virement

Association Consulter
comptes

4.2.5 TEST DES CAS D'UTILISATION 275


TEST DES CAS D'UTILISATION – EXEMPLE 2 (1/2)
Exemple d’exigences pour un site de réservation de chambres d’hôtel :
1. Le site Internet doit proposer un système de réservation de chambres d’hôtel. Pour
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

cela, un client fournit les informations utiles et nécessaires via un formulaire de


réservation.
2. Après avoir vérifié les informations saisies, le système propose au client les chambres
disponibles au sein des hôtels partenaires.
3. Le client choisit une chambre, se connecte à son compte puis fournit les informations
bancaires pour réserver la chambre.
4. Le système, après avoir pré-réservé la chambre auprès du système d’information de
l’hôtel concerné, demande l’autorisation à la banque pour finaliser le paiement et la
réservation.
5. Une fois la réservation finalisée, le système confirme la réservation auprès de l’hôtel
et envoie un mail de confirmation au client.

4.2.5 TEST DES CAS D'UTILISATION 276


TEST DES CAS D'UTILISATION – EXEMPLE 2 (2/2)
Comportements exceptionnels / gestion des erreurs :
2a – Il manque des informations : retour à l’étape 1
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

3a – Il n’y a pas de disponibilités : retour à l’étape 1


4a – Le client souhaite modifier sa demande : retour à
l’étape 1
5a – Le client saisit des identifiants incorrects :
proposer à nouveau la page de connexion
6a – Le client annule le paiement : retour à l’étape 1
7a – Le SI de l’hôtel est injoignable : retour à l’étape 1
8a – Banque injoignable : retour à l’étape 1 et
déclencher cas d’utilisation « Annuler pré-
réservation »
8b – La banque refuse le paiement : retour à l’étape 6
8c – En cas de non-paiement au bout d’une heure :
retour à l’étape 1 et déclencher cas d’utilisation
« Annuler pré-réservation »
9a - Le SI de l’hôtel est injoignable : poursuivre
traitement client avec l’étape 10 et déclencher « Hôtel
injoignable – Confirmation chambre »

4.2.5 TEST DES CAS D'UTILISATION 277


TEST DES CAS D'UTILISATION – COUVERTURE
COUVERTURE pour le test des cas d’utilisation :
➢ La couverture minimale d’un cas d’utilisation consiste à avoir au moins un cas de test
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

pour le principal chemin possible, et un cas de test pour chaque chemin ou flux
alternatif.
➢ Les CHEMINS ALTERNATIFS incluent les chemins concernant les exceptions et les
défaillances. Les chemins alternatifs sont parfois considérés comme des extensions du
chemin principal.
➢ Couverture = pourcentage des comportements de cas d'utilisation testés divisé par le
nombre total des comportements du cas d'utilisation.
Exemple : site de réservation de chambres d’hôtel
1. Cas de test 1 pour le comportement de base : étapes 1 à 10
2. Cas de test 2 pour un comportement alternatif « La banque refuse le paiement » :
étapes 1 à 7, 8b, 6 à 10.
→ Couverture : 2 / 11 cas possibles = 18 %

4.2.5 TEST DES CAS D'UTILISATION 278


4. TECHNIQUES DE TEST

4.3 - TECHNIQUES DE TEST BOÎTE-BLANCHE


OBJECTIF(S) DE CONNAISSANCE
❑ FL-4.3.1
(K2) Expliquer la couverture des instructions
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ FL-4.3.2
(K2) Expliquer la couverture des décisions

❑ FL-4.3.3
(K2) Expliquer l’intérêt de la couverture des instructions et des décisions

4.3 TECHNIQUES DE TEST BOÎTE-BLANCHE 280


TECHNIQUES DE TEST BOÎTE-BLANCHE
Les TECHNIQUES DE TEST BOÎTE BLANCHE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

➢ sont basées sur la structure interne de l'objet de test : une analyse de l'architecture,
de la conception détaillée, de la structure interne ou du code de l'objet de test.
➢ peuvent être utilisées à tous les niveaux de test.

Ne sont étudiées dans le syllabus que les deux techniques liées au code qui sont le plus
souvent utilisées au niveau du test des composants :
1. TEST DES INSTRUCTIONS
2. TEST DES DÉCISIONS

N.B. : il existe des techniques plus avancées qui sont utilisées dans des contextes
critiques pour la sûreté, critiques pour la mission ou à fort besoin de fiabilité, et visant à
obtenir une couverture plus complète.

4.3 TECHNIQUES DE TEST BOÎTE-BLANCHE 281


TEST ET COUVERTURE DES INSTRUCTIONS
Une technique de conception de tests boîte-blanche dans
TESTS DES INSTRUCTIONS laquelle les cas de tests sont conçus pour exécuter des
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

instructions.
INSTRUCTION
Une entité dans un langage de programmation, qui est
OU INSTRUCTION DANS LE CODE typiquement la plus petite unité indivisible d’exécution.
SOURCE

Une instruction qui, quand elle est compilée, est traduite en


code objet, et sera exécutée de façon procédurale quand le
INSTRUCTION EXÉCUTABLE
programme s’exécute et peut effectuer une action sur des
données ou le déroulement du programme.

Le test des instructions exerce les instructions exécutables dans le code.

4.3.1 - TEST ET COUVERTURE DES INSTRUCTIONS 282


TEST ET COUVERTURE DES INSTRUCTIONS
Un élément d’un programme est dit être exercé par un cas
de test quand les valeurs d’entrée causent l’exécution de cet
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

EXERCÉ
élément, tel qu’une instruction, décision ou autre élément de
structure.
Une méthode d’analyse qui détermine quelles parties du
logiciel ont été exécutées (couvertes) par une suite de tests
COUVERTURE DU CODE
et quelles parties ne l’ont pas été, p.ex. couverture des
instructions, des décisions ou des conditions..
COUVERTURE DES Le pourcentage des instructions exécutables qui ont été
INSTRUCTIONS exécutées par une suite de tests.

La COUVERTURE est mesurée comme le nombre d'instructions exécutées par les tests, divisé
par le nombre total d'instructions exécutables dans l'objet de test, généralement exprimé
en pourcentage.

4.3.1 - TEST ET COUVERTURE DES INSTRUCTIONS 283


TEST ET COUVERTURE DES INSTRUCTIONS
Exemple d’algorithme ou peudo-code d’une partie d’un programme :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Instruction1
1. Instruction1
2. IF condition1 THEN
C1
3. Instruction2 Vrai Faux
4. ELSE
5. Instruction3 Instruction2 Instruction3

6. ENDIF
7. instruction4
Instruction4

Diagramme de flux de contrôle

4.3.1 - TEST ET COUVERTURE DES INSTRUCTIONS 284


TEST ET COUVERTURE DES INSTRUCTIONS
Pour couvrir 100% des instruction il faut passer au moins une fois sur chaque instruction :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

1. Instruction1 Instruction1
2. IF condition1 THEN
3. Instruction2
4. ELSE C1
Vrai Faux
5. Instruction3
6. ENDIF Instruction2 Instruction3
7. instruction4

Dans cet exemple il faut 2 cas de test Instruction4


pour couvrir 100% des instructions.
Le cas 1 seul ne couvre que 75% des CHEMIN DU CAS DE TEST 1 CHEMIN DU CAS DE TEST 2
instructions (idem cas 2).

4.3.1 - TEST ET COUVERTURE DES INSTRUCTIONS 285


TEST ET COUVERTURE DES DÉCISIONS
Type d'instruction dans lequel le choix entre deux ou
DÉCISION plusieurs résultats possibles contrôle l'ensemble des actions
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

qui en résulte [ISO 29119].


Le résultat d'une décision qui détermine la prochaine
RÉSULTAT DE DÉCISION
instruction à exécuter.
Une technique de conception de tests boîte blanche selon
TEST DE DÉCISION laquelle les cas de tests sont conçus pour exécuter les
résultats de décisions.

Le test des décisions exerce les décisions dans le code et teste le code qui est exécuté
sur la base des résultats des décisions.
Pour cela, les cas de test suivent les FLUX DE CONTRÔLE qui se produisent à partir d'un POINT
DE DÉCISION : par exemple, pour une instruction IF, un pour le résultat VRAI et un pour le
résultat FAUX.

4.3.2 - TEST ET COUVERTURE DES DÉCISIONS 286


TEST ET COUVERTURE DES DÉCISIONS

COUVERTURE DES DÉCISIONS La couverture des résultats des décisions.


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

La COUVERTURE est mesurée comme le nombre de résultats


de décision exécutés par les tests, divisé par le nombre total
Instruction1
de résultats de décision dans l'objet de test (pourcentage).

Dans cet exemple il faut 2 cas de test pour C1


couvrir 100% des décisions. Vrai Faux

Instruction2 Instruction3
Le cas 1 seul ne couvre que 50% des
résultats de décision (VRAI).
Instruction4
Le cas 2 seul ne couvre que 50% des
résultats de décision (FAUX). CHEMIN DU CAS DE TEST 1 CHEMIN DU CAS DE TEST 2

4.3.2 - TEST ET COUVERTURE DES DÉCISIONS 287


TEST ET COUVERTURE DES DÉCISIONS
Il existe d’autres types de POINT DE DÉCISION que le IF.
Par exemple :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Boucles : TANT QUE (WHILE), Résultats de décision multiples : CASE


POUR i allant de 1 à n FAIRE (FOR …
DO), etc. I1
I1

A D
C1
C1
Vrai Faux B C

I2 I5
I2
I3 I4

I3

4.3.2 - TEST ET COUVERTURE DES DÉCISIONS 288


APPORT DES TESTS DES INSTRUCTIONS ET DÉCISIONS

➢ Lorsque la COUVERTURE À 100% DES INSTRUCTIONS est atteinte :


➢ elle garantit que toutes les instructions exécutables du code ont été testées au
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

moins une fois,


➢ mais elle ne garantit pas que toutes les décisions ont été testées.
➢ La COUVERTURE DES INSTRUCTIONS aide à trouver des défauts dans les parties du code
qui n'ont pas été exercées par d'autres tests.

➢ Lorsque la COUVERTURE À 100 % DES DÉCISIONS est atteinte :


➢ tous les résultats des décisions sont exécutés, ce qui comprend le test du résultat
VRAI et aussi du résultat FAUX, même lorsqu'il n'y a pas d'instruction FALSE
explicite.
➢ La COUVERTURE DES DÉCISIONS aide à trouver des défauts dans le code lorsque d'autres
tests n'ont pas couvert à la fois les résultats vrais et les résultats faux des décisions.
4.3.3 - APPORT DES TESTS DES INSTRUCTIONS ET DÉCISIONS 289
APPORT DES TESTS DES INSTRUCTIONS ET DÉCISIONS

1. IF condition1 THEN
CHEMIN DU CAS DE TEST 1 CHEMIN DU CAS DE TEST 2
2. Instruction1
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

3. ENDIF C1
Vrai Faux
4. Instruction2
5. IF condition2 THEN I1
6. Instruction3
7. ENDIF
I2
Dans cet exemple, il ne faut qu’1 seul cas de test
pour couvrir 100% des instructions : CAS 1.
C2
Par contre il faut 2 cas de test pour couvrir 100% Vrai Faux
des résultats de décision (CAS 1 et CAS 2).
I3

4.3.3 - APPORT DES TESTS DES INSTRUCTIONS ET DÉCISIONS 290


APPORT DES TESTS DES INSTRUCTIONS ET DÉCISIONS

LA COUVERTURE À 100 % DES DÉCISIONS GARANTIT UNE COUVERTURE À 100 % DES


INSTRUCTIONS (MAIS PAS L'INVERSE).
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Autrement dit :
NOMBRE DE CAS DE TEST POUR COUVRIR 100 % DES DÉCISIONS ≥ NOMBRE DE CAS DE TEST POUR
COUVRIR 100 % DES INSTRUCTIONS (MAIS PAS L'INVERSE).

Des deux techniques de test boîte-blanche présentées, le test des instructions peut
fournir une couverture du code moindre que le test des décisions.

4.3.3 - APPORT DES TESTS DES INSTRUCTIONS ET DÉCISIONS 291


4. TECHNIQUES DE TEST

4.4 - TECHNIQUES DE TEST BASÉES SUR L'EXPÉRIENCE


OBJECTIF(S) DE CONNAISSANCE
❑ FL-4.4.1
(K2) Expliquer l'estimation d’erreur
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ FL-4.4.2
(K2) Expliquer le test exploratoire

❑ FL-4.4.3
(K2) Expliquer le test basé sur des checklists

4.4 TECHNIQUES DE TEST BASÉES SUR L'EXPÉRIENCE 293


TECHNIQUES DE TEST BASÉES SUR L'EXPÉRIENCE
TECHNIQUES DE TEST BASÉES SUR L'EXPÉRIENCE : les cas de test sont basés sur
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Des compétences des testeurs ou utilisateurs,


✓ De l'intuition,
✓ De l'expérience : avec des applications et technologies similaires.
Avantages
• Permettent d'identifier des tests spécifiques difficilement
identifiables par les techniques formelles plus systématiques
(boîte noire, boîte blanche)
• Complètent donc les méthodes formelles

Inconvénients
• Leur efficacité très variable en fonction des compétences et de
l'expérience des testeurs
• La couverture peut être difficile à évaluer et peut ne pas être
mesurable avec ces techniques

4.4 TECHNIQUES DE TEST BASÉES SUR L'EXPÉRIENCE 294


TECHNIQUES DE TEST BASÉES SUR L'EXPÉRIENCE
DÉCOUVERTE DES DÉFAUTS :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

100

90

80

70
Taux de défauts découverts

60

50 Defauts détectés Novice


Defauts détectés Expért
40 Defauts détectés Expert + exploratoire

30

20

10

0
0 20 40 60 80 100
Temps

4.4 TECHNIQUES DE TEST BASÉES SUR L'EXPÉRIENCE 295


ESTIMATION D’ERREUR
Technique de test qui consiste à dériver les tests sur la base
de la connaissance des défaillances passées ou de la
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

ESTIMATION D’ERREUR
connaissance générale des modes de défaillance [ISO
29119].

L'ESTIMATION D'ERREUR est une technique utilisée pour anticiper les erreurs, les défauts et
les défaillances, sur la base des connaissances du testeur, y compris :
✓ Comment l'application a fonctionné antérieurement
✓ Quels types d'erreurs les développeurs ont tendance à faire
✓ Les défaillances qui se sont produites dans d'autres applications

4.4.1 - ESTIMATION D’ERREUR 296


ESTIMATION D’ERREUR
Une APPROCHE MÉTHODIQUE de la technique par estimation d’erreur
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Concevoir des tests qui


Créer une liste d'erreurs, de
exposeront ces défaillances
défauts et de défaillances
et les défauts qui les ont
possibles
causées

Connaissances
Listes
Données sur générales sur
d'erreurs, de
Expérience les défauts et les causes des
défauts et de
les défaillances défaillances
défaillances
logicielles

4.4.1 - ESTIMATION D’ERREUR 297


ESTIMATION D’ERREUR - EXEMPLE
Erreurs
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

• Préparation de jeux de données pas suffisamment représentatifs


pour les cas d’exception et la volumétrie
• Expérience du testeur pour estimer le résultat attendu du
montant de la facture

Défauts
• Maintenabilité du programme complexe de calcul de la facture
(respect du standard Cellule Qualité)
• Absence d’exigences des cas d’exception (expatrié, domiciles
pultiples, tarifs spéciaux)

Défaillances
• Ecart de 1 centime d’euro dans le montant total de la facture
(erreur d’arrondi)
• Temps de calcul du programme de facturation pour une
facturation mensuelle à grande échelle

4.4.1 - ESTIMATION D’ERREUR 298


TESTS EXPLORATOIRES
Une approche des tests par laquelle les testeurs conçoivent et exécutent
dynamiquement des tests en fonction de leurs connaissances, de
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TESTS EXPLORATOIRES l'exploration de l'élément testé et des résultats des tests précédents
|ISO 29119].

Pendant l’exécution, des tests informels sont dynamiquement

Conçus Exécutés Enregistrés Evalués

• en apprendre davantage sur le composant ou le


Résultats des système
• créer des tests pour les parties prenantes qui
tests utilisés pour pourraient avoir besoin de plus de tests

4.4.2 - TESTS EXPLORATOIRES 299


TESTS EXPLORATOIRES
Les TESTS EXPLORATOIRES sont parfois réalisés en utilisant des SESSIONS DE TEST
pour structurer l'activité
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Utilisation d’une CHARTE DE TEST


comprenant les objectifs du
test pour guider les tests
FICHES DE SESSION DE TEST
pour documenter les
Effectués dans étapes suivies et les
un temps défini constatations réalisées

4.4.2 - TESTS EXPLORATOIRES 300


TESTS EXPLORATOIRES
Sont le plus utiles quand il y a
• peu de spécifications ou des spécifications inadéquates
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

• des contraintes de temps importantes sur les tests


• pour compléter d'autres techniques de test plus formelles

Mauvais motifs
• Réduction des coûts
• Réduction des charges

Les tests exploratoires


✓ sont étroitement associés aux STRATÉGIES DE TEST RÉACTIVES (§5.2.2).
✓ peuvent inclure l'utilisation d'autres techniques boîte-noire, boîte-blanche et
basées sur l'expérience
4.4.2 - TESTS EXPLORATOIRES 301
TESTS BASÉS SUR DES CHECKLISTS
Une technique de conception de tests basée sur l'expérience selon
laquelle le testeur expérimenté utilise une liste de haut niveau
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TEST BASÉ SUR UNE CHECKLIST d'éléments à noter, à vérifier, ou à se rappeler, ou un ensemble de règles
ou de critères en fonction desquels un produit doit être vérifié.
Dans les tests basés sur des checklists, les testeurs conçoivent, implémentent et
exécutent des tests pour couvrir les conditions de test figurant dans une CHECKLIST.

Au cours de l'analyse
• Création nouvelle checklist Checklist construite sur la base de
• Ou modification checklist existante
• Ou utilisation checklist existante La compréhension
La connaissance
du pourquoi et du
de ce qui est
L’expérience comment des
important pour
défaillances
l'utilisateur
logicielles

4.4.3 - TESTS BASÉS SUR DES CHECKLISTS 302


TESTS BASÉS SUR DES CHECKLISTS
Des CHECKLISTS peuvent être créées pour prendre en charge différents types de tests :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ tests fonctionnels
✓ non-fonctionnels
✓ boîte blanche
En l'absence de cas de tests détaillés les tests basés sur des checklists peuvent fournir
✓ des lignes directrices
✓ un certain degré de cohérence
Comme il s'agit de listes de haut niveau, il est probable qu'il y ait une certaine variabilité
dans les tests réels, ce qui pourrait entraîner
✓ une plus grande couverture des tests
✓ mais une reproductibilité plus faible

4.4.3 - TESTS BASÉS SUR DES CHECKLISTS 303


TESTS BASÉS SUR DES CHECKLISTS - EXEMPLE

Fonctionnalités
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

• Chaque user story doit avoir au moins 2 critères d’acceptation


• Pour chaque entité gérée par le système, vérifier la présence de fonctions de création,
consultation, modification, suppression
• Pour chaque fonctionnalité fortement critique, vérifier la présence d’exigences de
performance

Utilisabilité
• Chaque fenêtre applicative doit respecter les normes citées dans le plan de test dédié à
l’utilisabilité
Spécification des tests
• Chaque cas de test doit comporter un objectif, des prérequis, des post-requis, être codifié
selon la norme décrite dans le plan de test maître

4.4.3 - TESTS BASÉS SUR DES CHECKLISTS 304


5 – GESTION DES TESTS
SOMMAIRE

5.1 - ORGANISATION DES TESTS


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

5.2 - PLANIFICATION ET ESTIMATION DES TESTS


5.3 - PILOTAGE ET CONTRÔLE DES TESTS
5.4 - GESTION DE CONFIGURATION
5.5 - RISQUES ET TESTS
5.6 - GESTION DES DÉFAUTS

5. LA GESTION DES TESTS 306


5 - GESTION DES TESTS

5.1 – ORGANISATION DES TESTS


OBJECTIF(S) DE CONNAISSANCE
❑ FL-5.1.1
(K2) Expliquer les bénéfices et inconvénients du test indépendant
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ FL-5.1.2
(K1) Identifier les tâches d'un Test Manager et d'un testeur

5.1 - ORGANISATION DES TESTS 308


AVANT QUI PRENAIT EN CHARGE LES ACTIVITÉS DE TEST ?

Historiquement, les tests étaient réduits à l' « EXÉCUTION DES TESTS » !


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Les RESSOURCES « DISPONIBLES » du projet étaient mises à contribution. Ces


ressources étaient très variées :
✓Développeurs,
✓Stagiaires,
✓Utilisateurs,
✓D'autres ressources du projet qui étaient disponibles,
✓Voir des ressources de l'organisation hors projet,
✓…
L'EFFICACITÉ des tests étaient donc DISCUTABLE selon le degré :
✓ De professionnalisation des ressources,
✓ D'indépendance.

5.1 - ORGANISATION DES TESTS 309


INDÉPENDANCE DE L'ÉQUIPE DE TEST (1/3)
Différents NIVEAUX D'INDÉPENDANCE d'une équipe de test :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Interne Projet : DÉVELOPPEUR

Interne Projet : RESSOURCE ALLOUÉE

Interne Organisation : ÉQUIPE TEST DE L'ORGANISATION

Interne Organisation : ÉQUIPE INDÉPENDANTE APPARTENANT À


L’ORGANISATION MÉTIER OU UTILISATEURS

Externe : SOUS-TRAITANCE SUR SITE OU HORS-SITE

Un certain degré d'indépendance rend souvent le testeur plus efficace.


L'indépendance ne remplace cependant pas la connaissance, et les
développeurs peuvent aussi trouver efficacement de nombreux défauts
dans leur propre code

5.1.1 - INDÉPENDANCE DES TESTS 310


INDÉPENDANCE DE L'ÉQUIPE DE TEST (2/3)
Pour la plupart des projets, il est généralement préférable d'avoir plusieurs niveaux de
test, certains de ces niveaux étant gérés par des testeurs indépendants.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Les développeurs devraient participer aux tests, en particulier aux niveaux inférieurs, afin
d'exercer un contrôle sur la qualité de leur propre travail.
TA
Testeurs indépendants TS
TI
TC
Développeurs

La façon dont l'indépendance des tests est mise en œuvre varie en fonction du modèle
de cycle de vie de développement logiciel
En développement Agile :
- les testeurs peuvent faire partie d'une équipe de développement ou d’une plus grande équipe de test
indépendante
- les Product Owners peuvent effectuer des tests d'acceptation pour valider les User Stories à la fin d’itérations

5.1.1 - INDÉPENDANCE DES TESTS 311


INDÉPENDANCE DE L'ÉQUIPE DE TEST (3/3)
Tableau synthétisant les avantages et les inconvénients
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

AVANTAGES INCONVÉNIENTS
❖ Détecter des types de défaillances différents par ❖ Les développeurs peuvent perdre le sens des
rapport aux développeurs en raison de leurs responsabilités vis-à-vis de la qualité
connaissances propres, de leurs approches ❖ Les testeurs peuvent être isolés de l'équipe de
techniques et de biais différents développement, ce qui entraîne un manque de
❖ Un testeur indépendant peut vérifier, contester ou collaboration, des retards dans la communication
réfuter les hypothèses formulées par les parties des retours d'information à l'équipe de
prenantes (Impartialité) développement ou une relation conflictuelle avec
❖ Une disponibilité plus forte (garantie contractuelle) l'équipe de développement
❖ Les testeurs indépendants peuvent être considérés
comme un goulot d'étranglement ou être rendus
responsables des retards dans la sortie de la version
❖ Les testeurs indépendants peuvent ne pas disposer
de certaines informations importantes
Tirer parti des avantages de l'indépendance des tests tout en évitant les inconvénients.
5.1.1 - INDÉPENDANCE DES TESTS 312
LA COMPOSITION D’UNE ÉQUIPE DE TESTS
Personne responsable de la gestion de projet des activités et des
ressources de test et de l'évaluation d'un objet de test. La personne qui
TEST MANAGER
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

dirige, contrôle, gère l’organisation et règle l’évaluation d’un objet de


test.
➢ Le TEST MANAGER porte la responsabilité globale du processus de test et de la bonne conduite des
activités de test. La gestion des tests peut être réalisée par un Test Manager professionnel ou par
un chef de projet, un responsable du développement ou un responsable de l'assurance qualité.
➢ Dans le cadre de projets de grandes envergures, dans lesquels ont pourra retrouver plusieurs
équipes de test, le Test Manager pourra nommer un TEST LEADER par équipe qui sera à son tour
garant des activités du Test Manager qui lui seront déléguées (au cas par cas).

Un professionnel qualifié qui participe aux tests d'un composant ou d'un


TESTEUR système.
➢ Les testeurs mettent en œuvre un plan de test pour concevoir les tests, préparer les données de
tests, exécuter les tests, s'assurer que le résultat de l'exécution correspond au résultat attendu et
générer un rapport de défaut dans le cas contraire.

5.1.2 - TÂCHES D’UN TEST MANAGER ET D’UN TESTEUR 313


LES TÂCHES DU TEST MANAGER (1/2)
Au quotidien, les TÂCHES DU TEST MANAGER sont :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

PLANIFIER | PILOTER | CONTRÔLER


PLANIFIER
✓ Développer ou revoir la stratégie de test, la politique de test de l’organisation
✓ Planifier les activités de test en fonction du contexte, des objectifs et des risques du test
✓ Sélectionner des approches de test, estimer le coût, le temps et l'effort du test, l’acquisition des
ressources, la définition des niveaux de test et des cycles de test, la planification de la gestion des défauts
✓ Rédiger et mettre à jour le(s) plan(s) de test
✓ Coordonner le(s) plan(s) de test avec les chefs de projet, les Product Owners et autres parties prenantes
✓ Partager différents aspects des tests avec d'autres activités du projet. Ex : la planification de l'intégration
✓ Aider la mise en place du système de gestion des défauts, à la gestion de la configuration des testware
✓ Introduire les métriques pour mesurer l’avancement des tests et évaluer la qualité des tests et du produit
✓ Accompagner la sélection et la mise en œuvre des outils de test, recommander le budget pour la
sélection des outils, apporter un accompagnement continu à l'utilisation des outils
✓ Décider de l'implémentation du ou des environnements de test

5.1.2 - TÂCHES D’UN TEST MANAGER ET D’UN TESTEUR 314


LES TÂCHES DU TEST MANAGER (2/2)
PILOTER
✓ Lancer l'analyse, la conception, l'implémentation et l'exécution des tests, suivre l'avancement et les
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

résultats des tests


✓ Vérifier le statut des critères de sortie (ou de la définition du terminé)
✓ Préparer et fournir des rapports d'avancement des tests et des rapports de synthèse des tests basés sur
les informations recueillies
✓ Coordonner la mise en œuvre des environnements
✓ Promouvoir et soutenir les testeurs, l'équipe de test et le métier du test au sein de l'organisation
✓ Développer les compétences et les carrières des testeurs

CONTRÔLER
✓ Adapter la planification en fonction des résultats et de l'avancement des tests et prendre toutes les
mesures nécessaires au contrôle des test
✓ Apporter son point de vue aux autres acteurs du projet

5.1.2 - TÂCHES D’UN TEST MANAGER ET D’UN TESTEUR 315


LES TÂCHES DU TESTEUR (1/3)
Au quotidien, les TÂCHES DU TESTEUR sont :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

ANALYSER | CONCEVOIR | IMPLÉMENTER | EXÉCUTER

ANALYSER
✓ Revoir et contribuer aux plans de test
✓ Analyser, revoir et évaluer les exigences, les User Stories et les critères d'acceptation, les spécifications et
les modèles (c.-à-d. les bases de test) vis à vis de leur testabilité
✓ Identifier et documenter les conditions de test

CONCEVOIR
✓ Concevoir et implémenter les cas de test et les procédures de test
✓ Saisir la traçabilité entre les cas de test, les conditions de test et les bases de test
✓ Automatiser les tests selon les besoins (peut être porté par un développeur ou un expert en
automatisation des tests)
✓ Revoir des tests développés par d'autres

5.1.2 - TÂCHES D’UN TEST MANAGER ET D’UN TESTEUR 316


LES TÂCHES DU TESTEUR (2/3)

IMPLÉMENTER
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ Préparer et obtenir les données de test


✓ Concevoir, configurer et vérifier le ou les environnement(s) de test, souvent en se coordonnant avec
l'administration système et réseau
✓ Utiliser les outils appropriés pour faciliter le processus de test
✓ Créer le planning détaillé d'exécution des tests

EXÉCUTER
✓ Exécuter des tests, évaluer les résultats et documenter les écarts par rapport aux résultats attendus
✓ Evaluer les caractéristiques non-fonctionnelles telles que la performance, la fiabilité, l’utilisabilité, la
sécurité, la compatibilité et la portabilité

5.1.2 - TÂCHES D’UN TEST MANAGER ET D’UN TESTEUR 317


LES TÂCHES DU TESTEUR (3/3)
Les personnes qui travaillent à l'analyse des tests, à la conception des tests, à des types de
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

tests spécifiques ou à l'automatisation des tests peuvent être des spécialistes dans ces
rôles. En fonction des risques produit et projet, et du modèle de cycle de vie du
développement logiciel choisi, différentes personnes peuvent assumer le rôle de testeur
à différents niveaux de test. Exemple :

Exploitation / administration TA Analyste métier , experts domaine, utilisateurs


Testeurs indépendants TS
TI
Développeurs
TC

5.1.2 - TÂCHES D’UN TEST MANAGER ET D’UN TESTEUR 318


5 - GESTION DES TESTS

5.2 – PLANIFICATION ET ESTIMATION DES TESTS


OBJECTIF(S) DE CONNAISSANCE
❑ FL-5.2.1
(K2) Résumer l'objectif et le contenu d'un plan de test
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ FL-5.2.2
(K2) Expliquer les différences entre plusieurs stratégies de test

❑ FL-5.2.3
(K2) Donner des exemples de critères d'entrée et de critères de sortie possibles

❑ FL-5.2.4
(K3) Appliquer les informations de priorité et de dépendances techniques et logiques pour ordonnancer
l'exécution d'un ensemble donné de cas de test

❑ FL-5.2.5
(K1) Identifier des facteurs qui influencent l'effort relatif au test

❑ FL-5.2.6
(K2) Expliquer les différences entre deux techniques d'estimation : la technique basée sur des métriques
et la technique basée sur l'expertise

5.2 – ESTIMATION ET PLANIFICATION DU TEST 320


ENJEUX ET ACTIVITÉS DE LA PLANIFICATION
QUESTIONS ENJEUX ACTIVITÉS DE PLANIFICATION
❑ Périmètre des tests
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

o Déterminer le périmètre, les objectifs et les risques des tests


QUOI ?
❑ Objectifs des tests o Prendre des décisions sur ce qu’il faut tester

❑ Ressources impliquées o Assigner des personnes et autres ressources


QUI ?
❑ Organisation de l'équipe o Assigner rôles et responsabilités dans l’équipe, aux parties prenantes

o Définir l'approche générale des tests


❑ Stratégie de test
COMMENT ? OÙ ? o Définir l’approche par niveau de test et type de test
❑ Approche des tests
o Sélectionner les métriques pour le pilotage et le contrôle des tests

❑ Planning o Intégrer les activités de test dans le cycle de vie du logiciel


QUAND ?
❑ Tâches o Définir les critères d’entrée et de sortie

❑ Environnements o Définir les environnements de test nécessaires


AVEC ?
❑ Outils o Prévoir quels outils utiliser

o Budgéter les activités de test


❑ Budget
COMBIEN ? o Déterminer le niveau de détail et la structure de la documentation
❑ Documentation
des tests

5.2.1 - OBJET ET CONTENU D'UN PLAN DE TEST 321


LA PLANIFICATION
La PLANIFICATION est influencée par la politique et la stratégie de test de l'organisation, les
cycles de vie du développement et les méthodes utilisées (voir section 2.1), l'étendue des
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

tests, les objectifs, les risques, les contraintes, la criticité, la testabilité et la disponibilité
des ressources.
La planification se doit d’être validée et documentée dans un PLAN DE TEST.
Le PLAN DE TEST :
✓ décrit les activités de test pour des projets de développement et de maintenance.
✓ ses caractéristiques importantes sont détaillées dans la norme IEEE-29119.
La planification peut être documentée :
✓ dans un PLAN DE TEST MAÎTRE (global pour le projet)
✓ dans des PLANS DE TEST SÉPARÉS pour des niveaux de test, tels que les tests système et les
tests d'acceptation, ou pour des types de test séparés, tels que les tests d'utilisabilité
et les tests de performance.

5.2.1 - OBJET ET CONTENU D'UN PLAN DE TEST 322


L’ÉVOLUTION DU PLAN DE TEST

La PLANIFICATION des tests est une activité continue et s'effectue tout au long du cycle de
vie du produit (jusqu’en maintenance incluse).
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Par conséquent le PLAN DE TEST doit faire l'objet d'un contrôle et d'une amélioration
continue :
✓ Au fur et à mesure que le projet et la planification des tests progressent, davantage
d'informations deviennent disponibles et plus de détails peuvent être inclus dans le
plan de test.
✓ Des retours d'information sur les activités de test devraient être utilisés pour identifier
les risques qui évoluent afin que la planification puisse être ajustée.

5.2.1 - OBJET ET CONTENU D'UN PLAN DE TEST 323


LE CONTENU ATTENDU DU PLAN DE TEST
LE PLAN DE TEST DOIT :
✓ Préciser l’approche générale des tests
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

➢ Périmètre, objectifs des tests


➢ Le(s) environnement(s) de test,
➢ La documentation avec le niveau de détail attendu
✓ Les rôles et périmètres d’intervention des testeurs, des observateurs
✓ Un planning général d’intervention par phase et préciser les moyens nécessaires afin
d’établir une projection budgétaire
✓ Définir le cadre du pilotage de l’activité du test
✓ Moyens de reporting : métriques, contrôles
✓ Mettre en place une gestion des risques et plan d’actions

5.2.1 - OBJET ET CONTENU D'UN PLAN DE TEST 324


CONTENU D’UN PLAN DE TEST
A titre d’exemple, ce que la norme ISO/IEC/IEEE 29119-3 peu proposer comme contenu du plan
de test :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

1. Identifiant du plan de test


2. Introduction
3. Composants à tester
4. Caractéristiques à tester
5. Caractéristiques à ne pas tester
6. Approche
7. Critères de passage/d'échec des composants
8. Critères de suspension et exigences de continuation
9. Livrables de test
10. Tâches de test
11. Besoin en environnements
12. Responsabilités
13. Ressources et besoins de formation
14. Calendrier (planning) : activités de test soit à des dates particulières (p. ex., en développement
séquentiel) ou dans le contexte de chaque itération (p. ex., en développement itératif)
15. Risques et hypothèses
16. Approbations

5.2.1 - OBJET ET CONTENU D'UN PLAN DE TEST 325


EXEMPLE DE CONTENU D’UN PLAN DE TEST SYNTHÉTIQUE
Exemple de format « One page » du plan de test utilisable notamment en
développement Agile :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

5.2.1 - OBJET ET CONTENU D'UN PLAN DE TEST 326


STRATÉGIE DE TEST - DÉFINITION

STRATÉGIE DE TEST Documentation qui exprime les exigences génériques pour tester dans le cadre
d'un ou de plusieurs projets exécutés au sein d'une organisation, fournissant des
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OU STRATÉGIE DE TEST détails sur la façon dont les tests doivent être effectués, et qui est alignée sur la
ORGANISATIONNEL politique de test [ISO 29119].

POLITIQUE DE TEST Document de haut niveau décrivant les principes, approches et objectifs
majeurs de l’organisation concernant l’activité de test.
Les raisons pour lesquelles une stratégie de test est nécessaire sont :
✓ EXHAUSTIVITÉ IMPOSSIBLE DES TESTS du fait de la combinaison exponentielle
de cas que cela représente. ➔ Effort de test d'un logiciel infini
✓ RÉDUCTION DE L'EFFORT DE TEST.
Elle dépend du contexte du projet :
✓ Criticité métier, budget projet,
✓ Disponibilité et/ou compétences des ressources (technologie)…

5.2.2 - STRATÉGIE DE TEST ET APPROCHE DE TEST 327


DIFFÉRENTS TYPES DE STRATÉGIE DE TEST
TYPE DE STRATÉGIE PRINCIPE
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

ANALYTIQUE o Basé sur un facteur (exigences, risques)

o Tests conçus à partir d'un modèle d'un aspect requis du produit : fonction, processus métier,
BASÉE SUR LES MODÈLES structure interne, caractéristique non-fonctionnelle

MÉTHODIQUE o Repose sur l'utilisation systématique d'un ensemble prédéfini de tests ou de conditions de test
CONFORME À UN PROCESSUS OU
o L'analyse, la conception et l'implémentation de tests basés sur des règles et normes externes
CONFORME À UNE NORME
o Dicté par les recommandations, les conseils ou les instructions des parties prenantes, des
DIRIGÉE (OU CONSULTATIVE) experts du domaine métier ou des experts techniques, qui peuvent se trouver en dehors de
l'équipe de test ou de l'organisation elle-même
o Motivé par le désir d'éviter la régression au niveau des fonctionnalités existantes
ANTI-RÉGRESSIONS o Comprend la réutilisation des testware existants (en particulier les cas de test et les données de
test), une forte automatisation des tests de régression et des suites de test standard
o Test est adapté aux composants ou systèmes testés en réaction aux événements se produisant
pendant l'exécution des tests, plutôt que pré-planifié
RÉACTIVE
o Tests conçus, implémentés, exécutés immédiatement en réponse aux informations obtenues à
partir des résultats de tests antérieurs.

5.2.2 - STRATÉGIE DE TEST ET APPROCHE DE TEST 328


PERTINENCE D’UNE STRATÉGIE DE TEST
Une stratégie de test PERTINENTE est souvent créée
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

en COMBINANT plusieurs de ces types de stratégies de test

Tests basés Tests plus


Tests
sur les efficaces
exploratoires
risques lorsqu'ils
(stratégie
(stratégie sont utilisés
réactive)
analytique) ensemble

L'ajustement de la stratégie est basé sur :


✓ les décisions prises en fonction de la complexité et des objectifs du projet
✓ du type de produit développé
✓ de l'analyse des risques produit

5.2.2 - STRATÉGIE DE TEST ET APPROCHE DE TEST 329


APPROCHE DE TEST - DÉFINITION

APPROCHE DU TEST L’implémentation de la stratégie de test pour un projet spécifique.


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Alors que la stratégie de test fournit une description générale du processus de test,
l’APPROCHE DE TEST ajuste la stratégie de test pour un projet ou une version particulière.
L'APPROCHE DE TEST doit permettre de :
✓ Sélectionner :
➢ les TECHNIQUES DE TEST à utiliser,
➢ les NIVEAUX DE TEST et les types de test à couvrir,
✓ Définir les CRITÈRES D’ENTRÉE ET DE SORTIE (ou définition du prêt et définition du
terminé)

5.2.2 - STRATÉGIE DE TEST ET APPROCHE DE TEST 330


CHOIX D’UNE APPROCHE DE TEST
L'APPROCHE DE TEST choisie dépend :
✓ du contexte
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ de facteurs tels que les risques, la sécurité, les ressources et les compétences
disponibles
✓ la technologie
✓ la nature du système
✓ les objectifs des tests
✓ les réglementations

Exemple : L'approche de test sur un projet avec une Exemple : L'approche de test pour un projet avec un
nouvelle technologie logiciel commercial sur étagère (nature du système)
➔ Complexité du système
➔ Risque sur la maîtrise de la technologie ➔ Effort de test sur le paramétrage du système

5.2.2 - STRATÉGIE DE TEST ET APPROCHE DE TEST 331


SYNTHÈSE STRATÉGIE / APPROCHE / PLAN DE TEST

Entreprise Politique de
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

test

Entreprise Stratégie de
test

Plan de test Plan de test


Projets maître
(Projet 1)
maître
(Projet 2)

Plan de test Plan de test Plan de test Plan de test


d’intégration système d’acceptation d’utilisabilité

5.2.2 - STRATÉGIE DE TEST ET APPROCHE DE TEST 332


CRITÈRES D'ENTRÉE ET DE SORTIE D’UNE ACTIVITÉ DE TEST

CRITÈRES D’ENTRÉE L'ensemble des conditions pour le démarrage formel d'une tâche définie [Gilb
and Graham].
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OU DÉFINITION DU PRÊT

CRITÈRES DE SORTIE
OU DÉFINITION DU
TERMINÉ
L'ensemble des conditions pour la complétion formelle d'une tâche définie [Gilb
OU CRITÈRES
and Graham].
D'ACHÈVEMENT
OU CRITÈRES
D'ACHÈVEMENT DES TESTS

Afin d'exercer un contrôle efficace sur la qualité du logiciel et des tests, il est conseillé d'avoir des
critères qui définissent quand une activité de test donnée doit commencer et quand l'activité est
terminée.
Les critères d'entrée et de sortie devraient être définis pour chaque niveau et type de test, et
différeront en fonction des objectifs de test.

5.2.3 - CRITÈRES D'ENTRÉE ET DE SORTIE 333


CRITÈRES D'ENTRÉE ET DE SORTIE D’UNE ACTIVITÉ DE TEST

LES CRITÈRES D'ENTRÉE ET DE SORTIE HABITUELS INCLUENT :


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

CRITÈRES D’ENTRÉE – DISPONIBILITÉ DE : CRITÈRES DE SORTIE :


❑ Exigences testables, User Stories et/ou ❑ Les tests planifiés ont été exécutés
modèles ❑ Un niveau défini de couverture (par exemple
❑ Éléments de test qui ont satisfait aux des exigences) a été atteint

NIVEAU DE TEST
TYPE DE TEST
critères de sortie pour tous les niveaux ❑ Le nombre de défauts non résolus est limité à
de test précédents ce qui a été défini
❑ Environnement de test ❑ Le nombre estimé de défauts restants est
❑ Outils de test nécessaires suffisamment faible
❑ Données de test et autres ressources ❑ Les niveaux évalués de fiabilité, de
nécessaires performance, d'utilisabilité, de sécurité et
autres caractéristiques qualité pertinentes
sont suffisants

CONDITIONS DE DÉMARRAGE CONDITIONS DE FIN

5.2.3 - CRITÈRES D'ENTRÉE ET DE SORTIE 334


CRITÈRES D'ENTRÉE PAR NIVEAU DE TEST

Exemples par niveau de test (modèle de développement séquentiel) :


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

NIVEAU DE TEST ACTIVITÉ CRITÈRES D’ENTRÉE


Conception de test o Spécifications conception détaillée approuvées
TEST DE COMPOSANT
Exécution des tests o Harnais de test disponible et testé
Conception de test o Spécifications conception générale approuvées
TEST D'INTÉGRATION o Environnement d'intégration opérationnel
Exécution des tests
o Code exécutable intégré
Conception de test o Spécifications des exigences logiciel approuvées
TEST SYSTÈME
Exécution des tests o Environnement système opérationnel
Conception de test o Spécifications des exigences métier validées
TEST D’ACCEPTATION o Environnement d’acceptation iso-production
Exécution des tests
opérationnel

5.2.3 - CRITÈRES D'ENTRÉE ET DE SORTIE 335


CRITÈRES DE SORTIE PAR NIVEAU DE TEST

Exemples par niveau de test (modèle de développement séquentiel) :


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

NIVEAU DE TEST ACTIVITÉ CRITÈRES DE SORTIE


Conception de test o Couverture des instructions à 100%
TEST DE COMPOSANT
Exécution des tests o 80% des composants testés avec succès
Conception de test o Couverture de 90% des composants (selon priorités)
TEST D'INTÉGRATION
Exécution des tests o 100% des interfaces de forte criticité sont en succès
o Spécifications des test système des domaines métier
Conception de test
TEST SYSTÈME comptabilité et finances validées
Exécution des tests o 0 anomalie résiduelle de sévérité bloquante
Conception de test o 100% des processus métier critiques couverts
TEST D’ACCEPTATION o 100% des exigences critiques en succès
Exécution des tests
o 0 anomalie résiduelle de sévérité bloquante et majeure

5.2.3 - CRITÈRES D'ENTRÉE ET DE SORTIE 336


CRITÈRES D'ENTRÉE ET DE SORTIE D’UNE ACTIVITÉ DE TEST

Même si les critères de sortie ne sont pas satisfaits, il est également courant que les
activités de test soient réduites en raison :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

✓ du budget dépensé
✓ du temps prévu
✓ de la pression pour mettre le produit sur le marché

Il peut être acceptable de mettre fin aux tests dans de telles circonstances, si les parties
prenantes du projet et les responsables métier ont revu et accepté le risque de mettre en
production sans autres tests.

5.2.3 - CRITÈRES D'ENTRÉE ET DE SORTIE 337


CALENDRIER D’EXÉCUTION DES TESTS - PRÉSENTATION

CALENDRIER D’EXÉCUTION DES Un ordonnancement de l'exécution des suites de tests au sein d'un cycle
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

TESTS de test.

Exécution du processus de test sur une version unique et identifiable d’un


CYCLE DE TEST objet de test.

Un CALENDRIER D’EXÉCUTION DES TESTS définit l'ordre dans lequel les SUITES DE TEST
doivent être exécutées.
✓ Les cas de test conçus sont ordonnés dans les procédures de test
(potentiellement automatisées)
✓ Les procédures de test sont assemblées en suites de test
✓ Les suites de test peuvent être organisées selon un calendrier d’exécution

5.2.4 - CALENDRIER D'EXÉCUTION DES TESTS 338


CALENDRIER D’EXÉCUTION DES TESTS - FACTEURS
Le calendrier d’exécution des tests devrait tenir compte de plusieurs facteurs
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Tests de
confirmation

Tests de
Dépendances
régression

Calendrier Séquence la plus


Ordre de efficace pour
priorité d’exécution l’exécution des
des tests tests

5.2.4 - CALENDRIER D'EXÉCUTION DES TESTS 339


CALENDRIER D’EXÉCUTION DES TESTS - FACTEURS
Idéalement, les cas de test devraient être exécutés en fonction de leur NIVEAU DE PRIORITÉ,
généralement en exécutant en premier les cas de test ayant la priorité la plus élevée.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Cependant, cette pratique peut ne pas fonctionner si les cas de test ont des dépendances
ou si les caractéristiques testées ont des dépendances.

➢ Si un cas de test avec une priorité plus élevée dépend d'un cas de test avec une priorité
plus faible, le cas de test de priorité plus faible doit être exécuté en premier.

➢ De même, s'il existe des dépendances entre les cas de test, il faut les ordonner de
façon appropriée, indépendamment de leurs priorités relatives.

5.2.4 - CALENDRIER D'EXÉCUTION DES TESTS 340


CALENDRIER D’EXÉCUTION DES TESTS – EXEMPLE 1

Couverture des conditions de test Dépendance des Ordre d’exécution


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

de priorité Px cas de test

Condition de
Cas 1 Cas 2 Cas 2
test 1 - P1

Condition de
Cas 2 Cas 1 Cas 3 Cas 1
test 2 – P2

Cas 3 Cas 3

L’ordre d’exécution des tests tient compte


➢ des priorités des conditions de test (P1 plus prioritaire que P2)
➢ de la dépendance des cas de tests (les cas 1 et cas 3 dépendent du cas 2)

5.2.4 - CALENDRIER D'EXÉCUTION DES TESTS 341


CALENDRIER D’EXÉCUTION DES TESTS – EXEMPLE 2

Couverture des conditions de test Anomalies Dépendance des Ordre d’exécution


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

de priorité Px Priorisées cas de test

Condition de
Cas 1 TR Cas 2 Cas 2
test 1 - P1

Condition de Ano1
Cas 2 Cas 1 Cas 3 Cas 3
test 2 – P2 P2

Ano2
Cas 3 Cas 1
P1

L’ordre d’exécution des tests tient compte


➢ des priorités des conditions de test, de la dépendance des cas de tests
➢ de la priorité des anomalies à corriger et à confirmer (priorité anomalie 2 P1 > anomalie 1 P2)
➢ test de régression à exécuter (sur le cas 1)

5.2.4 - CALENDRIER D'EXÉCUTION DES TESTS 342


CALENDRIER D’EXÉCUTION DES TESTS – EXEMPLE 3

Couverture des exigences Dépendance des Ordre d’exécution


exigences
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Cas 5
Exigence 1 Cas 1
Exigence 4
Cas 2 Cas 6

Exigence 2 Exigence 3
Exigence 2 Cas 3 Cas 3

Exigence 3 Cas 4 Exigence 1 Cas 4

Exigence 4 Cas 5
Cas 1
Cas 6
Cas 2

➢ L’ordre d’exécution des tests tient compte des dépendances des exigences

5.2.4 - CALENDRIER D'EXÉCUTION DES TESTS 343


CALENDRIER D’EXÉCUTION DES TESTS – EXERCICE
Couverture des exigences
Dépendance des Ordre d’exécution
Et dépendance des cas de test exigences
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Exigence 1 Cas 1
Exigence 2
Exigence 2 Cas 2

Exigence 3 Cas 3
Exigence 5 Exigence 1 ?
Exigence 4 Cas 4
Exigence 3
Cas 5
Exigence 4
Exigence 5 Cas 6

➢ L’ordre d’exécution des tests tient compte des dépendances des exigences et des cas de test

5.2.4 - CALENDRIER D'EXÉCUTION DES TESTS 344


EFFORT DE TEST - ESTIMATION
Approximation calculée d’un résultat lié à divers aspects du test (ex. : effort
ESTIMATION DES TESTS accompli, date d’achèvement, coûts induits, nombre de cas de test, etc.) qui est
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

utilisable malgré des données d’entrée incomplètes, incertaines ou altérées.

L'ESTIMATION DE L'EFFORT DE TEST consiste à évaluer la charge des tests nécessaire lors la
planification pour atteindre les objectifs de test d'un projet, d'une version ou d'une
itération particulière.
Pour faciliter la gestion des activités de test :
✓ Estimer la charge AU PLUS TÔT,
✓ Faire une estimation FIABLE,
✓ Prendre en compte TOUTES LES ACTIVITÉS liées aux tests

L'estimation de l'effort de test est d'autant plus importante à


définir que l'activité de test est perçue comme un PROCESSUS
COÛTEUX.

5.2.5 - FACTEURS INFLUENÇANT L'EFFORT DE TEST 345


EFFORT DE TEST – ESTIMATION & FACTEURS INFLUENÇANT (1/3)
Les facteurs qui influencent l’effort de test peuvent inclure :
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

CARACTÉRISTIQUES CARACTÉRISTIQUES
DU PROCESSUS DE LIÉES AUX
DÉVELOPPEMENT PERSONNES

CARACTÉRISTIQUES RÉSULTATS DES


DU PRODUIT TESTS

EFFORT DE TEST

5.2.5 - FACTEURS INFLUENÇANT L'EFFORT DE TEST 346


EFFORT DE TEST – ESTIMATION & FACTEURS INFLUENÇANT (2/3)

Les facteurs qui influencent l'effort de test :


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

CARACTÉRISTIQUES DU PRODUIT CARACTÉRISTIQUES DU PROCESSUS DE


✓ Les risques associés au produit DÉVELOPPEMENT
✓ La qualité des bases de test ✓ La stabilité et la maturité de l'organisation
✓ La taille du produit ✓ Le modèle de développement utilisé
✓ La complexité du domaine métier du produit ✓ L'approche de test
✓ Les exigences relatives aux caractéristiques de ✓ Les outils utilisés
qualité (p. ex., sécurité, fiabilité) ✓ Le processus de test
✓ Le niveau de détail requis pour la documentation ✓ La pression des délais
des tests
✓ Les exigences en matière de conformité juridique
et réglementaire

5.2.5 - FACTEURS INFLUENÇANT L'EFFORT DE TEST 347


EFFORT DE TEST – ESTIMATION & FACTEURS INFLUENÇANT (3/3)

Les facteurs qui influencent l'effort de test :


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

CARACTÉRISTIQUES LIÉES AUX PERSONNES RÉSULTATS DES TESTS


✓ Les compétences et l'expérience des personnes ✓ Le nombre et la sévérité des défauts trouvés
impliquées, en particulier avec des projets et des
✓ La quantité nécessaire de travail à refaire
produits similaires (par exemple, connaissance du
domaine)
✓ La cohésion et le leadership de l'équipe

5.2.5 - FACTEURS INFLUENÇANT L'EFFORT DE TEST 348


EFFORT DE TEST - 2 TECHNIQUES D'ESTIMATION

DEUX TECHNIQUES D'ESTIMATION DE L’EFFORT DE TEST LES PLUS UTILISÉES


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

ESTIMATION BASÉE SUR LES MÉTRIQUES ESTIMATION BASÉE SUR L’EXPERTISE

✓ On utilise le retour d'expérience des anciens


projets ayant les mêmes caractéristiques ou des ✓ On utilise la connaissance des experts pour
caractéristiques proches (volumétrie, technologie,
charges de développement…) établir une estimation de charge pour chaque
tâche
Exemples de Technique d’estimation :
Exemples de Technique d’estimation :
- Les BURNDOWN CHARTS, Basé sur le recueil de l’effort
- Les MODÈLES DE CORRECTION DES DÉFAUTS, basé sur le - Le PLANNING POKER, basé sur le consensus
retour d’expérience sur les défauts - Le WIDEBAND DELPHI, basé sur des experts

5.2.6 - TECHNIQUES D'ESTIMATION DES TESTS 349


5 - GESTION DES TESTS

5.3 – PILOTAGE ET CONTRÔLE DES TESTS


OBJECTIF(S) DE CONNAISSANCE
❑ FL-5.3.1
(K1) Se souvenir des métriques utilisées pour les tests
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

❑ FL-5.3.2
(K2) Résumer les objectifs, contenus et destinataires des rapports de test

5.3 - PILOTAGE ET CONTRÔLE DES TESTS 351


PILOTAGE ET CONTRÔLE DES TESTS - OBJECTIFS
PILOTAGE DES TESTS
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

➢ Le but du PILOTAGE DES TESTS est de recueillir des informations et de fournir un retour
et de la visibilité sur les activités de test.
➢ Les informations à suivre
✓ peuvent être collectées manuellement ou automatiquement
✓ utilisées pour évaluer L'AVANCEMENT DU TEST
✓ utilisées pour mesurer si les CRITÈRES DE SORTIE du test sont satisfaits
✓ projet Agile : utilisées pour connaître l’avancement des tâches de test associées à
la définition du terminé
EXEMPLES
RESPECT DES OBJECTIFS DE COUVERTURE, DES RISQUES PRODUIT, DES EXIGENCES, DES CRITÈRES D'ACCEPTATION

5.3 – PILOTAGE ET CONTRÔLE DES TESTS 352


PILOTAGE ET CONTRÔLE DES TESTS - OBJECTIFS
CONTRÔLE DES TESTS
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

➢ Le CONTRÔLE DES TESTS décrit toutes les mesures correctives ou d'orientation prises à
la suite de l'information et des métriques recueillies et (éventuellement) rapportées.
➢ Les actions peuvent couvrir toutes les activités de test et peuvent affecter toute
autre activité du cycle de vie du logiciel.
➢ Exemples d'actions de contrôle des tests :
✓ Re-prioriser les tests lorsqu'un risque identifié se produit (p. ex. logiciel livré en
retard)
✓ Modifier le calendrier des tests en raison de la disponibilité ou de l'indisponibilité
d'un environnement de test ou d'autres ressources
✓ Réévaluer si un élément de test répond à un critère d'entrée ou de sortie à cause
d'une modification

5.3 – PILOTAGE ET CONTRÔLE DES TESTS 353


MÉTRIQUES UTILISÉES POUR LES TESTS
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Avancement par rapport au calendrier et


au budget prévus

Qualité actuelle de l'objet de test


Métriques Evaluation

Pertinence de l’approche de test

Efficacité des activités de test par rapport


aux objectifs

5.3.1 - MÉTRIQUES UTILISÉES POUR LES TESTS 354


MÉTRIQUES UTILISÉES POUR LES TESTS

Métriques les plus couramment utilisées


Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Pourcentage du temps de travail prévu réalisé pour la préparation des cas de test (ou le pourcentage des cas de test
prévus implémentés)
Pourcentage du travail prévu réalisé pour la préparation de l'environnement de test

Exécution des cas de test. Exemples : nombre de cas de test exécutés/non exécutés, cas de test réussis/échoués, et/ou
conditions de test réussies/échouées
Informations sur les défauts. Exemples : densité des défauts, défauts trouvés et corrigés, taux de défaillance et
résultats des tests de confirmation
Couverture des exigences, des User Stories, des critères d'acceptation, des risques ou du code par les tests

Degré d'achèvement des tâches, affectation et utilisation des ressources, et temps passé

Coût des tests, y compris en comparaison avec le bénéfice apporté par la découverte des défauts supplémentaires ou
le coût par rapport au bénéfice de l'exécution de tests supplémentaires

5.3.1 - MÉTRIQUES UTILISÉES POUR LES TESTS 355


MÉTRIQUES UTILISÉES POUR LES TESTS - DÉFINITIONS

DENSITÉ DE DÉFAUTS Le nombre de défauts par unité de mesure d'un produit d’activité [ISO 24765].
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

OU DENSITÉ DE FAUTES Exemples : nombre de défauts par composant, par épic.

Rapport entre le nombre de défaillances d'une catégorie donnée et une unité de


mesure donnée [ISO 24765]
TAUX DE DÉFAILLANCE
Exemples : défaillances par unité de temps, par nombre de transactions, par
nombre d'exécutions.

5.3.1 - MÉTRIQUES UTILISÉES POUR LES TESTS 356


BUTS DES RAPPORTS DE TEST

RAPPORT DE TEST Documentation résumant les activités et les résultats des tests
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Le but du RAPPORT DE TEST est de synthétiser et de communiquer les informations sur


l'activité de test, à la fois pendant et à la fin d'une activité de test.
Rapport de
test

Rapport Rapport de
d’avancement synthèse

Activité de test

5.3.2 - BUTS, CONTENU ET DESTINATAIRES DES RAPPORTS DE TEST 357


RAPPORTS DE TEST - DÉFINITION
RAPPORT
D’AVANCEMENT DE TEST Un rapport de test produit à intervalles réguliers sur l'état d'avancement des
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

activités de test par rapport à une base de référence, aux risques et aux
OU RAPPORT SUR LE STATUT solutions alternatives nécessitant une décision.
DES TESTS

Au cours du pilotage et du contrôle des tests, le Test Manager publie régulièrement des
rapports d'avancement de test pour les parties prenantes.

RAPPORT DE SYNTHÈSE
DE TEST Un rapport de test qui fournit une évaluation des éléments de test en
comparaison avec les critères de sortie [ISO 29119].
OU RAPPORT DE TEST

Lorsque les critères de sortie sont atteints, le Test Manager fournit le rapport de synthèse
de test. Ce rapport fournit un résumé des tests réalisés, sur la base du dernier rapport
d'avancement de test et de toute autre information pertinente.

5.3.2 - BUTS, CONTENU ET DESTINATAIRES DES RAPPORTS DE TEST 358


CONTENU DES RAPPORTS DE TEST

Rapport d’avancement de test


Rapport de synthèse de test
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Récapitulatif des tests réalisés


Le statut des activités de test et l’avancement par
rapport au plan de test Informations sur le déroulement de la période de test

Ecarts par rapport au plan, y compris les écarts par rapport au calendrier,
à la durée ou à l'effort consacré aux activités de test
Les facteurs qui freinent l'avancement
Statut des tests et de la qualité du produit par rapport aux critères de
sortie ou à la définition du terminé

Facteurs ayant bloqué ou bloquant l’avancement


Les tests prévus pour la prochaine période de suivi
Métriques sur les défauts, les cas de test, la couverture de test,
l’avancement de l'activité et la consommation de ressources

La qualité de l'objet de test Risques résiduels

Produits d'activités de test réutilisables

5.3.2 - BUTS, CONTENU ET DESTINATAIRES DES RAPPORTS DE TEST 359


RAPPORT D’AVANCEMENT DE TEST
Le RAPPORT D’AVANCEMENT DE TEST est un document produit régulièrement en anticipation
du RAPPORT DE SYNTHÈSE DE TEST.
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Il précise les ACTIVITÉS et ÉVÉNEMENTS : ANTICIPATION et RÉACTIVITÉ


❑ Les dates de début et fin de période ➢ Modification de planning suite à des
❑ La description de l'exécution arrêts…
❑ Les résultats observés
❑ Les informations sur les environnements RÉAJUSTEMENT DE L'EFFORT DE TEST
❑ Evénements perturbateurs ➢ Changement des priorités en fonction
❑ Les risques relevés et avérés de nouveaux risques…
❑ Les écarts observés
❑ Les Incidents détectés. RESPECT DES ENGAGEMENTS
➢ Appliquer les critères d'arrêt définis
dans le Plan de Test en fonction de
nouveaux risques…

5.3.2 - RÉSUMER LES OBJECTIFS, CONTENUS ET DESTINATAIRES DES RAPPORTS DE TEST 360
RAPPORT DE SYNTHÈSE DE TEST – AMÉLIORATION CONTINUE
ANALYSES DÉDUITES DU RAPPORT DE SYNTHÈSE DE TEST
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Le rapport de synthèse de test doit fournir des éléments pour l'amélioration continue de
l'efficacité des tests.
À partir de ce rapport, un certain nombre d'analyses peuvent être déduites comme par
exemple :
❑ L'analyse de la DENSITÉ DES DÉFAUTS permet de focaliser l'effort des tests dans les
zones les plus propices à des défauts
❑ L'analyse du TAUX DE DÉFAILLANCE permet de mieux estimer la charge de test

Le rapport de synthèse de test


est à la charge du Test
Manager

5.3.2 - RÉSUMER LES OBJECTIFS, CONTENUS ET DESTINATAIRES DES RAPPORTS DE TEST 361
FACTEURS INFLUENÇANT LE CONTENU DES RAPPORTS DE TEST
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Cycle de vie du
Exigences
développement
organisationnelles
logiciel

Audience du
Projet
rapport
Contenu
Rapport
de Test

5.3.2 - BUTS, CONTENU ET DESTINATAIRES DES RAPPORTS DE TEST 362


FACTEURS INFLUENÇANT LE CONTENU DES RAPPORTS DE TEST - EXEMPLES

Mise à jour
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Rapport de test
Tableau des
rapide du logiciel inclus dans : tâches

Rapports plus
détaillés et
plus rigoureux
Récapitulatif
de défauts

Rapports moins
détaillés et moins
rigoureux
Burndown
chart
Projet complexe avec de
nombreuses parties prenantes
Ou projet réglementé

5.3.2 - BUTS, CONTENU ET DESTINATAIRES DES RAPPORTS DE TEST 363


FACTEURS INFLUENÇANT LE CONTENU DES RAPPORTS DE TEST - EXEMPLES

Parties prenantes Destinataire


technique
Reproduction interdite sans autorisation écrite de FITEC & Océane Consulting Testing Services . Copyright 2019

Destinataires Rapport de haut


niveau Equipe de test
21 01 - Facturation Contractuelle
22
02 - Calcul
20 03 - PAR
04 - Pilotage
18

16

Nombre d'anomalies
13
14

12

10
7 7
8 6

6
3 3
4
2

3- A re-tester MOA