Préparation à la

certification
ISTQB Foundation
Level
Mme : Mouna ACHOUR née GHARBI

Syllabus 2018
Introduction
Let’s start with the first set of slides
ISTQB

3
ISTQB Foundation Level

4
 ISTQB Foundation Level Exam
26
Pas de Réponses 1 seule
Examen 40 correctes réponse
marque
60 mn Questions pour correcte/
negartive question
réussir

Nombre De Questions Par Chapitre

Total
Ch. 1 Ch. 2 Ch. 3 Ch. 4 Ch. 5 Ch. 6

8 5 5 11 9 2 40

K1: se souvenir;
K2: comprendre; Nombre De Questions Par K Level
Total
K3: utiliser; K1 K2 K3 K4
K4: analyser 20 12 8 40
5
Contenue du cours :

I. Fondamentaux des tests

II. Tester pendant le cycle de
vie du développement logiciel
III. Tests statiques
IV. Techniques de test
V. Gestion des tests
VI. Outils de support aux tests
6
1
Fondamentaux
des tests
 Fondamentaux des tests
Termes : couverture, débogage, défaut, erreur, défaillance, qualité, assurance qualité, cause racine, analyse de test, base de
test, cas de test, clôture des tests, condition de test, contrôle des tests, données de test, conception des tests, exécution des
tests, planning de l’exécution des tests, implémentation des tests, pilotage des tests, objet de test, objectif de test, oracle de
test, planification des tests, procédure de test, suite de test, test, testware, traçabilité, validation, vérification

1. Que sont les tests ?

2. Pourquoi les tests sont-ils nécessaires ?
3. Les 7 Principes généraux des tests
4. Processus de test
5. La psychologie des tests

8
 Que sont les tests ?
Les tests logiciels sont un moyen d'évaluer la qualité du logiciel et de réduire le risque de
défaillance du logiciel en cours de fonctionnement.

Certains tests impliquent l'exécution du composant ou du système testé. Ces tests sont
appelés tests dynamiques. D'autres tests n'impliquent pas l'exécution du composant ou
du système testé ; de tels tests sont appelés tests statiques.

Validation : confirmation par l’examen et la fourniture de preuves objectives que les

exigences, pour un usage ou une application voulue, ont été remplies. [ISO 9000]

Vérification : confirmation par l’examen et la fourniture de preuves objectives que des

exigences spécifiées ont été remplies. [ISO 9000]

9
 Que sont les tests ?
Objectifs des tests
· Évaluer les produits d’activités.
· Vérifier si toutes les exigences spécifiées ont été satisfaites
· Valider si l'objet de test est complet et fonctionne comme attendu
· Construire la confiance dans le niveau de qualité de l'objet de test
· Trouver et prévenir des défaillances et défauts
· Fournir suffisamment d'information aux parties prenantes pour la prise de décision
· Réduire le niveau de risque d'une qualité logicielle
· Se conformer aux exigences ou aux normes contractuelles, légales ou réglementaires

Les objectifs de test peuvent varier en fonction du contexte du composant ou du système

testé, du niveau de test et du modèle de cycle de vie de développement logiciel.
10
 Que sont les tests ?
Différence entre Test et débogage

 Le débogage est l'activité de développement qui trouve, analyse et corrige des

défauts.
 le test de confirmation vérifie si les corrections apportées ont résolu les défauts.

Dans certains cas, les testeurs sont responsables du test initial et du test de confirmation
final, tandis que les développeurs se chargent du débogage et du test des composants
concernés.

NB : Dans le développement Agile et dans d'autres cycles de vie, les testeurs peuvent
être impliqués dans le débogage et le test des composants. 11
Pourquoi les tests sont-ils nécessaires ?
Contribution des tests au succès

12
 Pourquoi les tests sont-ils nécessaires ?
Assurance qualité et test

Assurance qualité Test

(Contrôle qualité)
Mise en place d'une approche préventive de la Mise en place d'une approche curative de la
qualité. qualité.
* Respect des processus adéquats ce qui contribue à la *Assurer que les exigences fonctionnels et non
prévention des défauts. fonctionnels sont satisfait .
* L'analyse des causes racines pour détecter et
éliminer les causes des défauts. Le contrôle qualité combine diverses activités, y compris des
* L'application des résultats des réunions de activités de test, qui contribuent à l'atteinte de niveaux de qualité
rétrospective pour améliorer les processus. adéquats. Les activités de test font partie du processus global de
développement ou de maintenance du logiciel

La gestion de la qualité comprend toutes les activités qui dirigent et contrôlent une organisation en matière
de qualité.
13
 Pourquoi les tests sont-ils nécessaires ?
Erreurs, défauts et défaillances

 Les faux positifs peuvent se produire en raison d'erreurs dans la façon dont les tests ont
été exécutés, ou en raison de défauts dans les données de test, l'environnement de test, ou
d'autres testware, ou pour d'autres raisons.
Les faux positifs sont signalés comme des défauts, mais ne sont en réalité pas des défauts.
 Les faux négatifs : sont des tests qui ne détectent pas les défauts qu'ils auraient dû
détecter.

14
 Pourquoi les tests sont-ils nécessaires ?
Défauts, causes racines et effets

Les causes racines des défauts sont les premières actions ou conditions qui ont contribué à la
création des défauts.

 Les contraintes de temps

 La faillibilité humaine
 L’inexpérience ou le manque de compétence des participants au projet
 Une mauvaise communication entre les participants au projet
 La complexité du code, de la conception, de l'architecture, du problème sous-jacent à résoudre, et/ou des technologies
utilisées
 Les malentendus sur les interfaces intra-système et inter-système, en particulier lorsque de telles interfaces intra-système et
inter-système sont très nombreuses
 Des technologies nouvelles, peu connues
 Conditions environnementales. 15
 7 principes sur les tests
1. Les tests montrent la présence de défauts, pas leur absence

2. Les tests exhaustifs sont impossibles

3. Tester tôt économise du temps et de l’argent

4. Regroupement des défauts

5. Paradoxe du pesticide

6. Les tests dépendent du contexte

7. L’absence d’erreurs est une illusion 16

Processus de test
Activités et taches de test

17
 Processus de test
Le processus de test dans le contexte

Les facteurs qui influencent le processus de test :

· Le modèle de cycle de vie du développement logiciel et les méthodologies de 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, entre autres :
-Les budgets et ressources
-Les délais
-La complexité
-Les exigences contractuelles et réglementaires
· Les politiques et pratiques organisationnelles
18
· Les normes internes et externes requises
 Processus de test
Activités et taches de test

Planification des tests

La planification des tests implique de définir les objectifs du test et l'approche retenue pour atteindre
les objectifs du test dans le respect des contraintes imposées par le contexte.

Pilotage et contrôle des tests

la comparaison régulière de l’avancement réel par rapport au plan de test à l'aide des métriques de
pilotage définies dans le plan de test.
Le contrôle des tests consiste à prendre les mesures nécessaires pour satisfaire aux objectifs du
plan de test (qui peut être mis à jour au fil du temps). Le pilotage et le contrôle des tests se basent
sur l'évaluation des critères de sortie
19
 Processus de test
Activités et taches de test
Analyse de test : "quoi tester"

Analyser les bases de test pour identifier les caractéristiques testables et définir les conditions de test
associées.
L'analyse de test comprend les principales activités suivantes :
 Analyser les bases de test
 Evaluer les bases de test et des éléments de test pour identifier des défauts de différents types,
 Identifier les caractéristiques et les ensembles de caractéristiques à tester
 Définir et prioriser les conditions de test pour chaque caractéristique (fonctionnelles, non-
fonctionnelles et structurelles, facteurs métier et techniques, niveaux de risque)
 Capturer la traçabilité bidirectionnelle entre les bases de test et les conditions de test

20
 Processus de test
Activités et taches de test
Conception des tests : « comment tester ? »
les conditions de test sont déclinées en cas de test de haut niveau et autres testware.

La conception des tests comprend les activités principales suivantes :

· 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

21
 Processus de test
Activités et taches de test
Implémentation des tests : « Est-ce que tout est en place pour exécuter les tests ? ».

Créer et/ou compléter le testware nécessaire à l'exécution des tests , y compris l'ordonnancement des cas de
test en procédures de test.

L'implémentation des tests comprend les activités principales suivantes :

 Développer et prioriser les procédures de test et créer des scripts de test automatisés.
 Créer des suites de tests à partir des procédures de test et des scripts de tests automatisés.
 Positionner les suites de tests dans un calendrier d'exécution des tests.
 Construire l'environnement de test (harnais de test, la virtualisation des services, les simulateurs ..)
 Préparer les données 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. 22
 Processus de test
Activités et taches de test
Exécution des tests
les suites de tests sont exécutées conformément au calendrier d'exécution des tests.

L'exécution des tests comprend les activités principales suivantes :

 Enregistrer les IDs et les versions des éléments de l'objet et des outils de test et des testware.
 Exécuter les tests manuellement et/ou automatiques.
 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 (suite:anomalie, test corrigé, test de confirmation, test de régression)
 Vérifier et mettre à jour la traçabilité bidirectionnelle entre les bases de test, les conditions de test, les cas
23
de test, les procédures de test et les résultats des tests.
 Processus de test
Activités et taches de test
Clôture des tests

Collecter les données des activités de test terminées afin de consolider l'expérience, les testware et toute
autre information pertinente. Les activités de clôture des tests ont lieu à des jalons du projet; qu'une itération
de projet Agile est terminée; qu'un niveau de test ou qu'une maintenance est terminée.

La clôture des tests comprend les activités principales suivantes :

 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, les données, l'infrastructure de test et autres.
 Remettre le testware aux équipes de maintenance, équipes de projet ou à d'autres parties.
 Analyser les leçons apprises et utiliser l'information recueillie pour améliorer le processus de test 24
Processus de test
Les produits d’activités du test

25
 Processus de test
Traçabilité entre les bases de test et les produits d’activités du test
Une bonne traçabilité facilite :

 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

26
 La psychologie des tests
Psychologie humaine et test
 Commencer par la collaboration plutôt que par la confrontation . Rappeler à tous l'objectif commun d'une meilleure
qualité des systèmes.

 Mettre l'accent sur les bénéfices du test. Par exemple, pour les auteurs, l'information sur les défauts peut les aider à
améliorer leurs produits d’activités et leurs compétences. Pour l'organisation, les défauts trouvés et corrigés durant
les tests permettront d'économiser du temps et de l'argent et de réduire le risque global pour la qualité du produit.

 Communiquer les résultats des tests et d'autres constats d'une manière neutre et axée sur les faits, sans critiquer la
personne qui a créé l’item défectueux. Rédiger des rapports objectifs et factuels sur les défauts et les constats des
revues.

 Essayer de comprendre ce que ressent l'autre personne et les raisons pour lesquelles elle peut réagir négativement
à l'information.

27
 Confirmer que l'autre personne a compris ce qui a été dit et vice versa.
 La psychologie des tests
Etat d’esprit des testeurs et des développeurs
L'objectif premier du développement est de concevoir et de construire un produit.
les objectifs du test comprennent la vérification et la validation du produit, la détection des défauts avant
la livraison.
 L’union de ces points de vue permet d'atteindre un niveau plus élevé de qualité des produits.

L'état d'esprit d'un testeur devrait inclure : la curiosité, un pessimisme professionnel, un œil critique,
l'attention aux détails et une motivation pour de bonnes et positives communications et relations

L'état d'esprit d'un développeur peut inclure certains éléments de l'état d'esprit d'un testeur.
Avec le bon état d'esprit, les développeurs sont capables de tester leur propre code.

28
 Tester pendant le
2 cycle de vie du
développement
logiciel
 Tester pendant le cycle de vie
du développement
Termes : couverture, test d'acceptation, test alpha, test bêta, logiciel commercial sur étagère (COTS), test d'intégration de
composants, test de composants, test de confirmation, test d'acceptation contractuelle, test fonctionnel, analyse d'impact, test
d'intégration, test de maintenance, test non-fonctionnel, test d'acceptation opérationnelle, test de régression, test d'acceptation
réglementaire, modèle de développement séquentiel, test d'intégration de systèmes, test système, bases de test, cas de test,
environnement de test, niveau de test, objet de test, objectif de test, type de test, test d'acceptation utilisateur, test boîte
blanche.

1. Les modèles de développement logiciel

2. Niveaux de test
3. Types de test
4. Tests de maintenance

30
 Les modèles de développement logiciel
Développement de logiciel et tests logiciels
 Chaque modèles de cycle de développement de logiciels nécessite une approches de test.
Pour chaque activité de développement, il y a une activité de test correspondante.
 L'analyse et la conception et les revus des tests pour un niveau de test donné commencent au cours de
l'activité de développement correspondante ; dès que des versions préliminaires sont disponibles.
 Quel que soit le modèle de cycle de développement logiciel choisi, 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 ».

les modèles de cycle de vie de développement de logiciels courants comme suit :

 Modèles de développement séquentiel

 Modèles de développement itératif et incrémental

31
 Les modèles de développement logiciel

32
 Les modèles de développement logiciel
Développement de logiciel et tests logiciels

Le modèle en V : intègre le processus de test tout au long du processus de développement, en

appliquant le principe de « Tester tôt ». De plus, le modèle en V inclut des niveaux de test associés
à chaque phase de développement correspondante 33
Les modèles de développement logiciel
Développement de logiciel et tests logiciels

Modèle en cascade: les activités de

développement (p. ex. analyse des
exigences, conception, codage, test) sont
réalisées l'une après l'autre. Dans ce
modèle, les activités de test ont seulement
lieu une fois que toutes les autres activités
de développement sont terminées.

34
 Les modèles de développement logiciel
Développement de logiciel et tests logiciels
· Spiral (ou par prototypage) : il s'agit de créer Rational Unified Process : chaque itération a tendance à
des incréments expérimentaux. être relativement longue , et les incréments de
caractéristiques sont proportionnellement importants, de
l’ordre de deux ou trois groupes de caractéristiques
connexes.

35
 Les modèles de développement logiciel
Développement de logiciel et tests logiciels
· Scrum : chaque itération a tendance à être relativement courte (p. ex., heures, jours ou quelques
semaines), et les incréments de caractéristiques sont proportionnellement petits, de l’ordre de quelques
améliorations et/ou deux ou trois nouvelles caractéristiques.

· Kanban : mis en oeuvre avec des itérations de durée fixe ou non, pouvant soit livrer à la fin une
seule amélioration ou caractéristique, soit regrouper des groupes de caractéristiques pour les
36
livrer en une fois.
 Niveaux de test
Les niveaux de test utilisés dans ce syllabus sont les suivants :

37
Niveaux de test
Test de composants

38
Niveaux de test
Test d'intégration

39
 Niveaux de test
Test d'intégration

L’intégration "big bang" des composants: veut dire que l'intégration de tous les composants ou
systèmes s’effectue en une seule étape.

L’intégration incrémentale des composants veut dire que l'intégration se fait par petit nombre de
composants.

Une analyse de risque des interfaces les plus complexes peut aider à focaliser les tests d'intégration.

40
Niveaux de test
Test système

41
Niveaux de test
Test d'acceptation

42
Niveaux de test
Test d'acceptation

43
 Types de test
Tests fonctionnels / Tests non fonctionnels

44
 Types de test
Tests boîte-blanche / Tests de confirmation / Tests de régression
Tests boîte-blanche : des tests basés sur la structure ou l'implémentation interne du système. La
structure interne peut comprendre le code, l'architecture, les flux de travail et/ou les flux de données au
sein du système
Tests liés aux changements : Lorsque des modifications sont apportées à un système, que ce soit pour
corriger un défaut ou en raison
d'une fonctionnalité nouvelle ou modifiée, des tests devraient être effectués pour confirmer que les
modifications ont corrigé le défaut ou implémenté la fonctionnalité correctement, et n'ont pas causé de
conséquences préjudiciables inattendues.
• Test de confirmation : les cas de test qui ont échoué en raison du défaut
• Tests de régression : Tester si une correction a accidentellement affecté le comportement d'autres
parties du code
45
Des tests de confirmation et de régression sont effectués à tous les niveaux de test.
 Tests de maintenance
Une fois déployés dans les environnements de production, les logiciels et les systèmes doivent être
maintenus.
Des changements dans les logiciels et les systèmes livrés pour ;
 Corriger des défauts découverts lors de l'utilisation opérationnelle
 Ajouter de nouvelles fonctionnalités, soit pour supprimer ou modifier des fonctionnalités déjà
livrées.
Des tests de maintenance devraient être effectués pour :
 évaluer le succès avec lequel les modifications ont été apportées
 vérifier les effets secondaires possibles.

La maintenance est également nécessaire pour préserver ou améliorer les caractéristiques de qualité
non fonctionnelles en particulier la performance, la compatibilité, la fiabilité, la sécurité et la portabilité.
46
3
Tests
statiques
 Tests statiques
Termes : revue ad hoc, revue basée sur des check-lists, test dynamique, revue formelle, revue informelle, inspection, relecture
basée sur la perspective, revue, revue basée sur les rôles, revue basée sur des scénarios, analyse statique, test statique,
revue technique, relecture technique.

1. Bases des tests statiques

2. Processus de revue

48
 Tests statiques
Bases des tests statiques
Presque tous les produits d'activités peuvent être examinés à l'aide de tests statiques (revues et/ou
analyses statiques), par exemple :
· Les spécifications : les exigences métier, les exigences fonctionnelles et les exigences de sécurité
· Les épics, User Stories, et critères d’acceptation
· Les spécifications d'architecture et de conception
· Le code
· Le testware ; les plans de test, les cas de test, les procédures de test et les scripts de test automatisés
· Les guides utilisateur
· Les pages Web
· Les contrats, les plans de projet, les calendriers et les budgets
· Les modèles, tels que les diagrammes d'activité, qui peuvent être utilisés pour les tests basés sur des
modèles 49
 Tests statiques
Bénéfices des tests statiques
· Détection et correction plus efficace des défauts, avant l'exécution des tests dynamiques
· Identification des défauts qui ne sont pas facilement décelables par des tests dynamiques
· 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
· Augmentation de la productivité du développement (par exemple, grâce à une meilleure conception, à
un code plus facile à maintenir)
· Réduction des coûts et des délais de développement
· Réduction des coûts et des délais des tests
· Réduction du coût total de la qualité tout au long de la durée de vie du logiciel (réduction du nombre de
défaillances plus tard dans le cycle de vie)
· Amélioration de la communication entre les membres de l'équipe au cours de la participation aux revues
50
 Tests statiques
Les defauts des tests statiques
· Défauts dans les exigences (p. ex. incohérences, ambiguïtés, contradictions, omissions,inexactitudes et
redondances)
· Défauts dans la conception (p. ex. algorithmes ou structures de base de données inefficaces,
taux de dépendance élevé, faible cohésion)
· Défauts dans le code (p. ex. variables avec des valeurs non définies, variables déclarées mais
jamais utilisées, code inatteignable, code dupliqué)
· Ecarts par rapport aux normes (p. ex. non-respect des règles de codage)
· Spécifications d'interface incorrectes (p. ex. 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é (p. ex. sensibilité aux débordements de la mémoire tampon)
· Lacunes ou inexactitudes dans la traçabilité ou la couverture des bases de test (p. ex., des tests
manquants pour un critère d'acceptation)
51
** Code mort : code inatteignable
 Tests statiques
Processus de revue
· Définir le périmètre et estimer l'effort et le temps requis
· Identifier les caractéristiques de la revue ; type de revue avec les rôles, les activités et les checklists
Planification · Sélectionner les personnes 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

Lancement de la revue · Distribuer le produit d'activités revu.

· Expliquer le périmètre, les objectifs, le processus, les rôles et les produits d'activités aux participants
· Revoir tout ou partie du produit d'activités
Revue individuelle
· Noter les défauts potentiels, les recommandations et les questions
· Communiquer les défauts potentiels identifiés
· Analyser les défauts potentiels, leur affecter un responsable et un statut
Communication et
· Évaluer et documenter les caractéristiques de qualité
analyse des problèmes
· É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, avec ou sans des changements mineurs)
· Produire des rapports de défauts et les communiquer a la personne ou à l'équipe concernée.
· Corriger les défauts trouvés (correction généralement réalisée par l'auteur) dans le produit d'activités
revu.
Correction et
· Enregistrer l'état actualisé des défauts (dans les revues formelles)
production de rapports
· 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 52
 Tests statiques
Techniques de revue individuelle

Ad hoc : les réviseurs reçoivent peu ou pas de directives sur la façon dont cette
Tâche devrait être accomplie. Elle dépend fortement des compétences des réviseurs.
Basée sur les check-lists : Une technique systématique, pour laquelle les réviseurs détectent
les problèmes sur la base de check-list.
Scénarios et essais à blanc : 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 son utilisation prévue.
Basée sur les rôles : les réviseurs évaluent le produit d’activités du point de vue de rôles
individuels des parties prenantes.
Basée sur la perspective : les réviseurs adoptent différents points de vue des parties prenantes
dans le cadre d'une revue individuelle.

53
 Tests statiques
Rôles et responsabilités dans une revue formelle
Auteur · Crée le produit d'activités revu et corrige les défauts (si nécessaire)

· Décide de la mise en œuvre et planifie la revue · Affecte le personnel, le budget et le temps

· Vérifie le rapport coût-efficacité en continu
Manager · Met en œuvre les mesures appropriées en cas de résultats inadéquats

· Assure le bon déroulement des réunions de revue

· Fait la médiation, si nécessaire, entre les différents points de vue
Facilitateur (modérateur)
la personne dont dépend le succès de la revue

· Prend la responsabilité générale de la revue

Responsable de la revue · Décide qui sera impliqué et organise quand et où elle aura lieu
· Il peut s'agir d'experts du domaine, de personnes travaillant sur le projet, d'intervenants ayant un intérêt pour le
produit d’activités et/ou de personnes ayant des compétences techniques ou métier spécifiques
· Ils identifient les défauts potentiels du produit d’activités à revoir
Réviseurs · Ils peuvent représenter différentes perspectives (p. ex. testeur, programmeur, utilisateur, opérateur, analyste
métier, expert en utilisabilité, etc.).

· Recueille les défauts potentiels découverts au cours de l'activité de revue individuelle

· Enregistre les nouveaux défauts potentiels, les points en suspens et les décisions prises lors de la réunion54
de
Scribe (ou rapporteur)
revue (durant son déroulement)
Tests statiques
Types de revue

55
Tests statiques
Types de revue

56
4
Techniques
de test
 Techniques de test
Termes : technique de test de boîte-noire, analyse des valeurs limites, test basé sur les check-lists, couverture, couverture des
décisions, test de tables de décision, estimation d’erreur, partitions d'équivalence, technique de test basée sur l'expérience,
test exploratoire, test des transitions d'état, couverture des instructions, technique de test, test des cas d'utilisation, technique
de test de boîte-blanche.

1. Catégories de techniques de test

2. Techniques de test boîte-noire
3. Techniques de test boîte-blanche
4. Techniques de test basées sur l'expérience

58
 Catégories de techniques de test
Les techniques de test de boîte-noire (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 (exp spécifications, cas d'utilisation)
• 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.
Les techniques de test de boite blanche (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.
Les techniques de test basées sur l'expérience tirent parti de l'expérience des développeurs, des
testeurs et des utilisateurs pour concevoir, implémenter et exécuter des tests.
Ces techniques sont souvent combinées à des techniques de test boîte-noire et boite blanche. 59
 Techniques de test boîte-noire
Partitions d'équivalence

Classe d’équivalence : Dans le cadre des tests fonctionnels, une classe d’équivalence est un
ensemble de valeurs pour lesquelles on ne peut distinguer le comportement du logiciel.
Couverture : nombre de partitions d'équivalence testées par au moins une valeur, divisé par le
nombre total de partitions d'équivalence identifiées.

EXP: le champs âge prend des valeurs entre 20 et 50 ans.

60
 Techniques de test boîte-noire
Analyse des valeurs limites
Le comportement aux limites des partitions d'équivalence est plus susceptible d'être incorrect que le
comportement à l'intérieur des partitions.

EXP: Deux valeurs limites

le champs âge prend des valeurs entre 20 et 50 ans.

EXP: Trois valeurs limites

61
 Techniques de test boîte-noire
Test de tables de décision
Les techniques de test combinatoire 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.
EXP :
* les véhicules diesel de 10 ans ou plus
se voient attribués un malus de 5%.
* les véhicules diesel de moins de 10 ans
se voient attribués un malus de 2%.
* les véhicules essence se voient attribués
un malus de 3%.
conditions :
C1 : diesel D1 : 5%
C2 : essence D2 : 2%
C3 : 10 ans ou plus D3 : 3%
62
 Techniques de test boîte-noire
Test de transitions d'état
Un diagramme de transitions d'état montre les états possibles du logiciel, ainsi que la façon dont le
logiciel entre, sort et évolue entre ces états.

63
 Techniques de test boîte-noire
Table de transitions d'état
Un tableau de transition d'état montre toutes les transitions valides et les transitions 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.

Signer contrat Signer contrat de

Etat actuel Dispute Décès
de mariage divorce

Célibataire Marié

Marié Séparé Veuf Divorcé

Divorcé Marié

Séparé Veuf Divorcé

Veuf Marié

64
 Techniques de test boîte-noire
Test des cas d'utilisation
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.
Step Description
1 A : Inserer la carte
Sénario principal 2 S : Valider la carte et demander PIN
A : Acteur
S : Système 3 A : Entrer PIN
4 S : Valider PIN
5 S : Permettre acces au compte
2a Carte non valide
S : message d'erreur et rejeter la carte

4a PIN non valide

Extension S : Message de demande de réessayer

4b PIN non valide 3 fois

S : Avaler carte

65
 Techniques de test boîte-blanche
Test et couverture des instructions : Le test des instructions exerce les instructions exécutables dans le
code. 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.
Test et couverture des 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.
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 de résultats de décision dans l'objet de test, généralement exprimé en pourcentage.
Autres techniques basés sur la structure :
• Couverture de condition
• Couverture des conditions multiples

66
 Techniques de test basées sur
l'expérience
Estimation d’erreur : c’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

Tests exploratoires : Dans les tests exploratoires, des tests informels (non prédéfinis) sont conçus,
exécutés, enregistrés et évalués dynamiquement pendant l'exécution des tests.

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.
67
5
Gestion des
tests
 Gestion des tests
Termes : gestion de configuration, gestion des défauts, critères d'entrée, critères de sortie, risque produit, risque projet, risque,
niveau de risque, test basé sur les risques, approche de test, contrôle des tests, estimation des tests, Test Manager, pilotage
des tests, plan de test, planification des tests, rapport d'avancement des tests, stratégie de test, rapport de synthèse des tests,
testeur.

1. Organisation des tests

2. Planification et estimation des tests
3. Pilotage et contrôle des tests
4. Gestion de configuration
5. Risques et tests
6. Gestion des défauts

69
Organisation des tests
Indépendance des tests

70
 Organisation des tests
Indépendance des tests :
Avantages Inconvénients
· Détecter des types de défaillances différents · Les testeurs peuvent être isolés de l'équipe de
par rapport aux développeurs en raison de développement : manque de collaboration, des
leurs connaissances propres, de leurs retards dans la communication des retours
approches techniques et de biais différents d'information à l'équipe de développement ou une
· Un testeur indépendant peut vérifier, relation conflictuelle avec l'équipe de développement
contester ou réfuter les hypothèses formulées · Les développeurs peuvent perdre le sens des
par les parties prenantes au cours de la responsabilités vis-à-vis de la qualité
spécification et de l'implémentation du système 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
71
de certaines informations importantes
 Planification et estimation des tests
Objet et contenu d'un plan de test
Un plan de test décrit les activités de test pour des projets de développement et de maintenance.
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, l'étendue des tests, les objectifs, les risques, les
contraintes, la criticité, la testabilité et la disponibilité des ressources.
La planification des tests est une activité continue et s'effectue tout au long du cycle de vie du produit.

Les activités de planification des tests peuvent comprendre les éléments suivants, dont certains
peuvent être documentés dans un plan de test : périmètre, les objectifs et les risques, l'approche
générale des tests, les personnes et les autres ressources nécessaires, les métriques pour le pilotage
et le contrôle des tests, budgéter les activités de test, le niveau de détail et la structure de la
documentation des tests.
72
 Planification et estimation des tests
Stratégie de test et approche de test
Une stratégie de test fournit une description générale du processus de test, généralement au niveau du
produit ou de l'organisation. l'approche de test ajuste la stratégie de test pour un projet ou une version
particulière.
Les types les plus courants de stratégies de test sont les suivants :
· Analytique : Le test basé sur les risques est un exemple d'approche analytique
· Basée sur des modèles
· Méthodique : utilisation d'un ensemble prédéfini de tests ou de conditions de test, tels qu'une
taxonomie de défaillances une liste des caractéristiques de qualité importantes, ou des normes
· Conforme à un processus (ou conforme à une norme) : basés sur des règles et normes externes,
· Dirigée (ou consultative) : Dicté par les recommandations, les conseils ou les instructions des parties
prenantes, des experts
· Anti-régressions : Eviter la régression au niveau des fonctionnalités existantes.
73
· Réactive : Réaction aux événements se produisant pendant l'exécution des tests, plutôt que préplanifié.
 Planification et estimation des tests
Les critères d'entrée :
· Disponibilité d'exigences testables, de User Stories et/ou de modèles (par exemple, lorsque l’on suit une
stratégie de test basée sur les modèles)
· Disponibilité d'éléments de test qui ont satisfait aux critères de sortie pour tous les niveaux de test
précédents
· Disponibilité de l'environnement de test
· Disponibilité des outils de test nécessaires
· Disponibilité des données de test et autres ressources nécessaires

74
 Planification et estimation des tests
Les critères de sortie :
· Les tests planifiés ont été exécutés
· Un niveau défini de couverture (par exemple, des exigences, des User Stories, des critères
d'acceptation, des risques, du code) a été atteint
· Le nombre de défauts non résolus est limité à ce qui a été défini
· Le nombre estimé de défauts restants est suffisamment faible
· Les niveaux évalués de fiabilité, de performance, d'utilisabilité, de sécurité et autres
caractéristiques qualité pertinentes sont suffisants

75
 Planification et estimation des tests
Calendrier d'exécution des tests

Suites de test : les différents cas de test et procédures de test produits et assemblés

Calendrier d'exécution des tests : définit l'ordre dans lequel , les suites de test doivent être exécutées.
Le calendrier d'exécution des tests devrait tenir compte de : l'ordre de priorité, les dépendances, les
tests de confirmation, les tests de régression et la séquence la plus efficace pour exécuter les tests.
Les cas de test devraient être exécutés en fonction de leur niveau de priorité ( en respectant les
dépendances ).

Les tests de confirmation et de régression doivent également être priorisés, en fonction de

l'importance d'une remontée d'information rapide sur les changements réalisés, mais là encore, des
dépendances peuvent s'appliquer.
76
 Planification et estimation des tests
Facteurs influençant l'effort de test
Caractéristiques du produit
· Les risques associés au produit / La qualité des bases de test / La taille du produit / La complexité
du domaine métier du produit / Les exigences en matière de conformité juridique et réglementaire
· Les exigences relatives aux caractéristiques de qualité (p. ex., sécurité, fiabilité)
· Le niveau de détail requis pour la documentation des tests
Caractéristiques du processus de développement
· La stabilité et la maturité de l'organisation / Le modèle de développement utilisé / L'approche de test
· Les outils utilisés /Le processus de test / La pression des délais
Caractéristiques liées aux personnes
· Les compétences et l'expérience des personnes impliquées / La cohésion et le leadership de
l'équipe
Résultats des tests
77
· Le nombre et la sévérité des défauts trouvés / La quantité nécessaire de travail à refaire
 Pilotage et contrôle des tests
Techniques d'estimation des tests

Il existe un certain nombre de techniques d'estimation utilisées pour déterminer l'effort requis pour des
tests adéquats. Deux des techniques les plus couramment utilisées sont les suivantes :
· La technique basée sur les métriques : estimer l'effort de test sur la base de métriques d'anciens
projets similaires ou sur la base de valeurs représentatives
· La technique basée sur l'expertise : estimation de l'effort de test sur la base de l'expérience des
responsables des tâches de test ou par des experts

 Les burndown charts sont des exemples d'une approche basée sur les métriques (Pour les développements agile).
 Le planning poker est un exemple d'approche basée sur l'expertise. (Pour les développements agile).
 La technique d'estimation Wideband Delphi est un exemple d'approche basée sur l'expertise
(Dans les projets séquentiels)

78
 Pilotage et contrôle des tests
Techniques d'estimation des tests

Indicateurs clés de performance (KPI) : Un indicateur clé de performance ou indicateur de

rendement clé, en anglais key performance indicator, est un indicateur mesurable d'aide
décisionnelle.

79
 Gestion de configuration
Le but de la gestion de la configuration est d'établir et de maintenir l'intégrité du composant ou du
système, du testware et de leurs relations mutuelles tout au long du cycle de vie du projet et du produit.
Pour supporter correctement les tests, la gestion de la configuration peut assurer ce qui suit :
 Tous les éléments de test sont identifiés de façon unique, versionnées, suivis pour les
changements et reliés les uns aux autres
 Tous les éléments du testware sont identifiés de manière unique, versionnées, suivis pour les
changements, liés les uns aux autres et liés aux versions des éléments de test afin que la
traçabilité puisse être maintenue tout au long du processus de test
 Tous les documents et logiciels identifiés sont référencés sans ambiguïté dans la documentation
de test
Au cours de la planification des tests, les procédures de gestion de la configuration et l'infrastructure
80
(outils) devraient être identifiées et implémentées.
 Risques et tests
Le risque produit implique la possibilité qu'un produit d’activités puisse ne pas satisfaire les besoins de
ses utilisateurs et/ou parties prenantes.
Lorsque les risques produit sont associés à des caractéristiques de qualité spécifiques d'un les
risques produit sont également appelés risques qualité.

Le risque projet implique des situations qui, si elles se produisent, peuvent avoir un effet négatif sur la
capacité d'un projet à atteindre ses objectifs.

Risque = Probabilité d’occurrence * Impact

81
 Gestion des défauts
Un rapport de défaut comprend généralement les éléments suivants :
· Un identifiant
· Un titre et un bref résumé du défaut signalé
· La date du rapport de défaut, l'organisation émettrice et l'auteur
· L'identification de l'élément de test et de l'environnement
· La ou les phases du cycle de développement au cours desquelles le défaut a été observé
· Une description du défaut et L'historique des modifications
· La portée ou le degré d'impact (sévérité)
· Urgence/priorité de la correction
· L'état du rapport de défaut
· Les conclusions, recommandations et approbations
· Les enjeux généraux, tels que les autres domaines qui peuvent être affectés par un changement
82
· Les références, y compris le cas de test qui a révélé le problème
6 Outils de
support aux
tests
 Outils de support aux tests
￮ Termes : test piloté par les données, test piloté par les mots-clés, outil de test de performance, automatisation des tests,
outil d'exécution des tests, outil de gestion des tests.

1. Introduction aux outils de test

2. Utilisation efficace des outils

84
 Outils de support aux tests
Classification des outils de test
Les outils de test peuvent avoir une ou plusieurs des finalités suivantes en fonction du contexte :

· Améliorer l'efficacité des activités de test en automatisant des tâches répétitives ou des tâches
qui nécessitent des ressources importantes lorsqu'elles sont effectuées manuellement
· Améliorer l'efficacité des activités de test en assistant les activités de test manuelles tout au long
du processus de test
· Améliorer la qualité des activités de test en permettant des tests plus cohérents et un niveau plus
élevé de reproductibilité des défauts
· Automatiser les activités qui ne peuvent être exécutées manuellement
· Augmenter la fiabilité des tests

85
 Introduction aux outils de test
Outils pour la gestion des tests et du testware

-- Harnais de test : Environnement comprenant les bouchons et les pilotes nécessaires pour exécuter un test. 86
-- L’effet de sonde : La conséquence de l'utilisation d'outils intrusifs
 Outils de support aux tests
Bénéfices de l'automatisation des tests

Les bénéfices potentiels de l'utilisation d'outils d'aide à l'exécution des tests incluent :

 Réduction du travail manuel répétitif

 Plus grande cohérence
 Évaluation plus objective
 Accès facilité à l'information sur les tests

87
 Outils de support aux tests
Risques de l'automatisation des tests

Les risques potentiels de l'utilisation d'outils en support aux tests incluent :

 Les attentes irréalistes à l'égard de l'outil

 Sous-estimation : du temps, du coût, de l'effort pour l'introduction initiale d'un outil..
 Il est possible que l'on se repose trop sur
 Le fournisseur peut apporter une réponse médiocre pour le support, les mises à niveau et les
corrections de défauts
 Un projet open source ou commercial peut être interrompu
 Une nouvelle plate-forme ou technologie peut ne pas être prise en charge par l'outil
 Il se peut qu'il n'y ait pas de propriété claire de l'outil
88
 Outils de support aux tests
Outils d'exécution des tests et de gestion des tests

Les outils d'exécution des tests : exécutent des objets de test à l'aide de scripts de test automatisés. Ce
type d'outil nécessite souvent des efforts importants pour obtenir des bénéfices significatifs.
 Le script capturé
 Approche de test piloté par les données
 Approche de test par mots-clés
 Les outils de Model-Based Testing (MBT)
Les outils de gestion des tests : doivent souvent s'interfacer avec d'autres outils ou feuilles de calcul pour
diverses raisons, telles que :
· Produire de l'information
· Maintenir une traçabilité cohérente des exigences
· Etablir un lien avec les informations de version de l'objet de test dans l'outil de gestion de configuration 89
 Outils de support aux tests
Utilisation efficace des outils

Principes de base pour la sélection des outils :

 Évaluation de la maturité de l'organisation, de ses forces et de ses faiblesses
 Évaluation de l'outil par rapport à des exigences précises et à des critères objectifs
 Identification des besoins internes pour le coaching et le soutien dans l'utilisation de l'outil
 Prise en compte des avantages et des inconvénients des différents modèles de licence (p. ex.,
commercial ou open source)
 Estimation d'un rapport coût-bénéfice basé sur une analyse de rentabilité concrète (si nécessaire)
Une preuve de concept (POC – Proof-of-Concept) devrait être effectuée pour déterminer si l'outil
fonctionne efficacement avec le logiciel à tester et au sein de l'infrastructure (ou identifier les
changements nécessaires)

90
 Outils de support aux tests
Projets pilotes pour d'un outil dans une organisation
l'introduction de l'outil sélectionné dans une organisation commence généralement par un projet pilote,
dont les objectifs sont les suivants :
 Acquérir une connaissance approfondie de l'outil, comprendre ses forces et ses faiblesses
 Évaluer la façon dont l'outil s'intègre aux processus et pratiques existants et déterminer ce qu'il
faudrait changer
 Décider des méthodes standard d'utilisation, de gestion, de sauvegarde et de maintenance de
l'outil et des actifs de test
 Évaluer si les bénéfices seront obtenus à un coût raisonnable.
 Comprendre les métriques que vous souhaitez voir recueillies et rapportées par l'outil, et configurer
l'outil pour s'assurer que ces métriques peuvent être recueillies et rapportées.

91
 Outils de support aux tests
Facteurs de succès pour les outils

 Déployer l'outil au reste de l'organisation de façon incrémentale

 Adapter et améliorer les processus en fonction de l'utilisation de l'outil
 Apporter de la formation, de l'encadrement et du conseil aux utilisateurs d'outils
 Définir des recommandations d’usage de l'outil (p. ex. normes internes pour l'automatisation)
 Mettre en place un moyen de collecte d'informations sur l'utilisation réelle de l'outil
 Suivre l'utilisation de l'outil et ses bénéfices
 Accompagner les utilisateurs d'un outil donné
 Recueillir les leçons tirées de l'expérience de tous les utilisateurs

92
 Les Normes

La norme ISO/IEC/IEEE 29119-1 : contient des informations sur les concepts des tests
logiciels.
La norme ISO/IEC/IEEE 29119-2 : contient des informations sur les processus de test.

La norme ISO/IEC/IEEE 29119-3 : peut servir de référence pour les produits d'activités du
test.

(ISO/IEC/IEEE 29119-4 : contient des descriptions des techniques de test et les mesures
de couverture.

ISO/CEI 25010 : peut servir pour une classification des caractéristiques de qualité des
93
produits logiciels.
Merci !!

94