UNIVERSITÉ DE SFAX
Institut Supérieur d’Informatique et de Multimédia
Tests de logiciels
Certification ISTQB
D-LSI MM
Cours 1: Introduction aux tests du logiciel
par
Aicha Idriss Hentati
aicha.idriss@gmail.com
Cours ISTQB T-LSI ADBD – l’organisation,
les objectifs et les règles
• Organisation
– Le cours régime contrôle continu (21 h cours)
• Le cours de 14 séances où:
– Séances 1-6 et 8-14: les cours intégré
– La séance 7: réservée pour passer un DS
– La séance 14: réservée pour une révision pour l’examen final
2
Cours T-LSI ADBD – l’organisation, les
objectifs et les règles
• Objectifs:
– Donner aux étudiants deux couches de connaissances:
• Les tests (essais) logiciels selon le programme de certification
ISTQB - Niveau fondamental
• La manipulation des tests (TP)
– Éduquer et préparer les meilleurs professionnels en test
du logiciel
3
Cours T-LSI ADBD – l’organisation, les objectifs et
les règles
• Règles:
– Les séances sont obligatoires parce que:
• elles sont interactives et fondamentales
• elles facilitent la compréhension du programme de certification en test
logiciel
– L’évaluation finale se composera de:
• La note TP (20%)
• La note pour le DS (40%)
• La note pour l’examen final (40%)
4
Cours T-LSI ADBD - la structure
• Les fondamentaux de Tests
• Les tests pendant le Cycle de Vie Logiciel (SLC)
• Les tests statiques
• Les techniques de tests
• La gestion des tests
• Les outils de support aux Tests
5
Références
[1] https://www.cftl.fr/wp-content/uploads/2018/10/CTFL-Syllabus2018-FR.pdf
[2] https://www.istqb.org/
[3] http://istqbfoundation.wikidot.com/1#toc0
6
Introduction
7
ISTQB?
 « International Software Testing Qualifications Board »
• Comité international de qualification du test logiciel reconnue dans le
monde entier.
 ISTQB® Certified Tester
• Qualification standardisée pour le test logiciel
• Basé sur le Syllabus et Glossaire, définis par ISTQB et formant la
base de la Qualification Internationale en Test de Logiciels
8
ISTQB® - Schéma de certification
9
Niveaux de connaissances (K-levels)
 K-levels
• Utilisés pour la classification des objectifs d’apprentissage suivant la taxonomie de Bloom
[Anderson 2001].
Analyse
K4
 Foundation & Advanced: K1-> K4
 K1: Se souvenir (définition)
 K2: Comprendre (le pourquoi des choses)
 K3: Utiliser (identifier des valeurs, calcul, ..)
 K4: Analyser (analyser les risques)
Evaluation
K5
Synthèse
K6
Utilisation
K3
Compréhension
K2
 Experts: K2->K6
 K5: Evaluer
 K6: Créer
Connaissance
K1
10
Structure de l’examen (Foundation)
Nombre de questions par niveau
K1
K2
K3
Total
8
24
8
40
Chaque question vaut 1 point
Un minimum de 65% pour réussir  26 points
Durée de l’examen 60 minutes (75 minutes pour ceux qui
passent l’examen dans une langue étrangère ou non local)
11
Nombre des questions par chapitre
Numéro
du
chapitre
Nom du chapitre
K1
K2
K3
Total des
Questions
1
Fondamentaux des tests
2
6
0
8
2
Tester pendant le cycle de vie
du développement logiciel
1
4
0
5
3
Tests statiques
1
3
1
5
4
Techniques de test
1
5
5
11
5
Gestion des tests
2
5
2
9
6
Outils de support aux tests
1
1
0
2
12
Chapitre1:
Les fondamentaux des tests
13
Les fondamentaux des tests
1.1
Qu'est-ce qu’un test?
1.2
Pourquoi les tests sont-ils nécessaires ?
1.3
Les sept principes généraux des tests
1.4
Processus de test
1.5
La psychologie des tests
1.6
Quiz
14
1.1 Qu'est-ce qu’un test?
Objectifs d'apprentissage (LO):
LO-1.1.1
Identify typical objectives of testing (K1)
LO-1.1.2
Differentiate testing from debugging (K2)
15
LO-1.1.1 (K1) Identifier les objectifs habituels des tests
Pour un projet donné, les objectifs du test peuvent inclure :
1.
évaluer les produits d’activités tels que les exigences, les User Stories, la conception et le code
2.
vérifier si toutes les exigences spécifiées ont été satisfaites
3.
valider si l'objet de test est complet et fonctionne comme attendu par les utilisateurs et
autres parties prenantes
4.
Construire la confiance dans le niveau de qualité de l'objet de test
5.
Prévenir des défauts
6.
Trouver des défaillances et des défauts
16
LO-1.1.1 (K1) Identifier les objectifs habituels des tests (Suite…)
7.
Fournir suffisamment d'information aux parties prenantes pour leur permettre de prendre des
décisions éclairées, en particulier en ce qui concerne le niveau de qualité de l'objet de test
8.
Réduire le niveau de risque d'une qualité logicielle inadéquate (p. ex. des défaillances non
détectées auparavant se produisant en opération)
9.
Se conformer aux exigences ou aux normes contractuelles, légales ou réglementaires, et/ou
pour vérifier la conformité de l’objet de test à ces exigences ou normes.
17
Objectif - 1
Evaluer les produits d’activités tels que les exigences, les User Stories,
la conception et le code
Exemple: For a web page, when the login details are given the next
page shall load in few ms and if login details are not correct then
show a pop up
1. How much time?
2. Which page will load next?
3. What is the pop up content?
18
Objectif - 2
Vérifier si toutes les exigences spécifiées ont été satisfaites
Exemple: For a web page, when the login details are given the next page shall
load in few ms and if login details are not correct then show a pop up
1. Login is correct, go to the next page
2. Next page shall loaded in 500 ms
3. Next page shall contain the personal information
4. If the login detail is not correct pop up shall appear
5. Pop up message “password or User-ID is incorrect”
19
Objectif - 3
Valider si l'objet de test est complet et fonctionne comme prévu par
les utilisateurs et autres parties prenantes
Exemple: For a web page, when the login details are given the next page shall
load in few ms and if login details are not correct then show a pop up
Input
1. Login is correct go to the next page
2. Next page shall loaded in 500 ms
3. Next page shall contain the personal information
4. If the login detail is not correct pop up shall appear
5. Pop up message “password or User-ID is incorrect
Output
20
Objectif - 4
Construire la confiance dans le niveau de qualité de l'objet de test
Objectifs - 5 & 6
• Trouver des défaillances et des défauts
• Prévenir des défauts
Objectif - 7
Fournir suffisamment d'information aux parties prenantes pour leur permettre de
prendre des décisions appropriées, en particulier en ce qui concerne le niveau de
qualité de l'objet de test
21
Objectif - 8
Réduire le niveau de risque d'une qualité logicielle inadéquate (exemple,
des défaillances non détectées auparavant se produisant en opération)
Objectif – 9
Se conformer aux exigences ou aux normes contractuelles, légales ou
réglementaires, et/ou pour vérifier la conformité de l’objet de test à ces
exigences ou normes
22
Objectifs du Test?
Rôle des tests (K2)
Le test n’a pas pour objectif de
– Diagnostiquer les fautes
– Corriger les défauts
– Prouver qu’un logiciel est correcte
Le test a pour objectif de
– Mettre en évidence les défauts d’un logiciel
– Prouver la conformité fonctionnelle
– Donner une indication de la qualité du logicielle => un niveau de confiance
– Prévenir des défauts
24
Prévenir les défauts (K2)
Proposez moi chacun
Comment peut-on prévenir
les défauts?
5 minutes
Prévenir les défauts (K2)
Conception des tests tôt
Revue des documents
dans le cycle de vie
• Identification et résolution des
• Réflexion sur les cas de tests
• Vérification des bases de test existantes
Tests rigoureux des systèmes et
problèmes avant le codage
prévenir les défauts
Analyse du code
de la documentation
• Identification et résolution des
•
Réduction des risques

Augmentation de la qualité
défauts dans le code
•
Respect des exigences légales
prévenir les défaillances

Atteinte des normes spécifiques
Tests et qualité (K2) ISO 25010
• Les tests logiciels sont un moyen d’évaluer la qualité du logiciel et de réduire le risque
de défaillance de logiciel lors de son fonctionnement
Aptitude
fonctionnelle
Portabilité
Répond
aux besoins
fonctionnels
Transfert
vers un autre
environnement
Securité
Accès à des
informations autorisées
Fiabilité
Maintenabilité
Maturité
Tolérance
aux pannes
Effort pour
les évolutions
Compatibilité
Interopérabilité
Facilité
d’utilisation
User
Experience
Efficacité du
rendement
Performance,
charge, stress
Combien de test est suffisant? (K2)
Comment juger la quantité de tests suffisante?
– Ce n’est jamais suffisant
– Quand on a fait ce qu’on a planifié
– Quand le client est content
– Quand on a prouvé que le système fonctionne correctement
– Quand on est confiant que le système fonctionne correctement
– Ca dépend du risque sur le système
Prendre en compte l’évaluation des risques
comment faire un minimum de tests pour un minimum de risques
28
Combien de test est suffisant? (K2)
Comment juger la quantité de tests suffisante?
– Ce n’est jamais suffisant x
– Quand on a fait ce qu’on a planifié x
– Quand le client est content x
– Quand on a prouvé que le système fonctionne correctement x
– Quand on est confiant que le système fonctionne correctement x
– Ca dépend du risque sur le système 
Prendre en compte l’évaluation des risques
comment faire un minimum de tests pour un minimum de risques
29
Test Vs Debogage
Testing
Debugging
Tester
Developer
Observe failure
Investigate and
isolate defect
Fix defect
Re-test to
confirm failure
no longer
occurs
 Test est l'exploration du système
afin de trouver des défauts
 Debogage est un processus de
détermination des causes des
erreurs (bugs) dans un code et de
les corriger
Check fix works
30
Verification Vs Validation
Verification
• Est-ce que nous avons bien
construit le produit?
Validation
• Est-ce que nous avons construit le
bon produit?
31
1.1 Qu'est-ce qu’un test?
1.2 Pourquoi les tests sont-ils nécessaires ?
Objectifs d'apprentissage (LO):
LO-1.2.1
LO-1.2.2
LO-1.2.3
LO-1.2.4
Pourquoi les Tests sont-ils nécessaires? (K2)
Contribution des tests au succès (K2)
Erreurs, défauts et défaillances (K2)
Causes racines et effets (K2)
32
1.2.1 Pourquoi les Tests sont-ils nécessaires?
• Les systèmes logiciels deviennent une part de notre existence, des
applications commerciales aux produits de grande
consommation
• Des logiciels ne fonctionnant pas correctement peuvent générer
de nombreux problèmes: pertes financières, temps, réputations,
allant même aux blessures ou mort
• Il est important de détecter et de corriger ces défaillances avant
qu’elles soient livrés aux clients
33
Exemples
• 1996: Ariane 5
• Utilisation du même software de Ariane 4 (32 bits) sur Ariane5 (64 bits)
 7 billion $
• 1999: Mars climate orbiter
• Integration d’un module utilisant différents unité (Newton/Libra)
 900 million $
• 1999: French Bank
• Migration de windows NT à windows 2000 : comportment incorrect du
software
34
1.2.2 Contribution des tests au succès
35
Assurance qualité et test
• La gestion de la qualité comprend toutes les activités qui dirigent et contrôlent
une organisation en matière de qualité
• L’assurance qualité est principalement axée sur le respect des processus
adéquats, afin de donner l'assurance que les niveaux de qualité appropriés seront
atteints (processus, produits d’activité de bonne qualité, causes des erreurs,
application des résultats de rétrospective)
• Le contrôle de la qualité comprend diverses activités, y compris des activités de
test, qui contribuent à l'atteinte de niveaux de qualité adéquats.
36
1.2.3 Erreurs, défauts et défaillances
• Les erreurs peuvent survenir suite à de nombreuses raisons, telles
que :
- 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, y compris au sujet des
exigences et de la conception
- 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
- la pollution peuvent causer des défauts dans le firmware
37
1.2.3 Erreurs, défauts et défaillances
• Les défaillances peuvent être causées par :
- Une erreur humaine causée par une échéance serrée, complexité du code,
infrastructure ou multiple interaction entre les systèmes
- Une condition d’environnement (radiation, magnétisme, pollution, etc.)
38
1.2.3 Erreurs, défauts et défaillances
• Erreur(= méprise) => Défaut(=Bug) => Défaillance qui peut être aussi
causée par les conditions de l’environnement
• En effectuant des tests, il est possible de mesurer la qualité des logiciels en terme de
défauts trouvés
• En comprenant les causes principales des défauts trouvés dans d’autres projets, les
processus peuvent être améliorés, ce qui ensuite peut prévenir l’apparition de ces
défauts => améliorer la qualité des systèmes futurs. C’est un aspect de l’assurance
qualité
• Les tests devraient être intégrés comme une activité de l’assurance qualité
(e.g., en utilisant des standards de développement, de la formation et de
l’analyse des défauts)
• C’est l’aspect d’aide à la décision => en prenant en compte le niveau de
risque
39
Erreur Humaine
Défaut (Bug)
Défaillance
40
1.2.4 Causes racines et effets
• Les causes racines des défauts (Root Cause Analysis)
• Les causes racines des défauts sont les premières actions ou
conditions qui ont contribué à la création des défauts.
• Les défauts peuvent être analysés pour identifier leurs causes racines,
afin de réduire l'apparition de défauts similaires à l'avenir.
• L'analyse des causes racines peut conduire à des améliorations de
processus qui préviennent l'introduction d'un nombre important de
défauts futurs
41
Defects - Root Causes - Effects
42
1.1 Qu'est-ce qu’un test?
1.2 Pourquoi les tests sont-ils nécessaires ?
1.3 Les sept principes généraux des tests
Objectifs d'apprentissage (LO):
LO-1.3.1
Les sept principes généraux des tests (K2)
43
Principes généraux des tests (K2)
1
• Les tests montrent la présence de défauts
2
• Les tests exhaustifs sont impossibles
3
• Tester tôt
4
• Regroupement des défauts
5
• Paradoxe du pesticide
6
• Les tests dépendent du contexte
7
• L’illusion de l’absence des erreurs
44
Principe 1 : Les tests montrent la présence de défauts
Les tests réduisent la probabilité que les défauts restent cachés dans le logiciel
45
Principe 2 : Les tests exhaustifs sont impossibles
 Test exhaustif?
 Quand tous les tests planifiés sont exécutés?
 Quand les testeurs sont extenués?
 Quand toutes les combinaisons de pré conditions et inputs sont terminées?
Why not just "testeverything"?
Tout tester (toutes les combinaisons d’entrées et de préconditions) n’est pas faisable sauf pour des cas triviaux
Au moyen 4 menus
3 options / menu
Système a 20
écrans
Total for 'exhaustive' testing:
Average: 10 champs / option
2 types input / field
(date as Jan3 or 3/1)
(number as integer or decimal)
Around 100 possible values
Au lieu de procéder à des tests exhaustifs, l'analyse
20 x 4 x 3 x 10 x 2 x 100 = 480,000 tests
If 1 second per test, 8000 mins, 133 hrs, 5,5 days
des risques et les priorités devraient être utilisées
(not counting finger trouble, faults or retest)
pour concentrer les efforts de test..
10 secs ~= 8 wks, 1 min ~= 1 yrs, 10 min ~= 10 yrs
46
Principe 2 : Les tests exhaustifs sont impossibles (Suite…)
Too little time, too much to test ..
 Durée du test sera toujours limitée
RISQUE
 utiliser
pour determiner:
 Que tester en premier (priorité)
 Que tester le plus
i.e. où mettre l'accent
 Comment tester chaque élément
 Ce qu'il ne faut pas tester (cette fois)
}
RISQUE
 utiliser
pour:
 allouer le temps disponible pour les tests en priorisant les tests...
47
Principe 2 : Les tests exhaustifs sont impossibles (Suite…)
Donnez la priorité aux tests afin
que, chaque fois que vous
arrêtez les tests, vous ayez
effectué les meilleurs tests dans
le temps disponible.
48
Principe 3 : Tester tôt
• Pour détecter tôt les défauts, à la fois des activités de tests
statiques et des activités de tests dynamiques doivent être
lancées le plus tôt possible dans le cycle de vie du logiciel
(SLC)
• Le fait de tester tôt est parfois appelé « shift left »
• Tester tôt dans le SLC permet de réduire ou d’éliminer des
changements coûteux
Plus une erreur est découverte tard dans le cycle de vie plus la correction
est coûteuse.
49
Principe 4 : Regroupement des défauts
 Concentration des efforts de test sur les modules contenant la majorité
des défauts
 Modules complexes: algorithmique, cyclomatique…
 Métiers complexes: pas ou peu de spécification
 Nouveaux Modules: encore non mature
 Nouvelles technologies: encore non maitrisée
• Approximately 80% of the problems are caused by 20%of the modules (Pareto principle)
50
Principe 5 : Paradoxe du pesticide
Si les mêmes tests sont répétés de nombreuses fois 
le même ensemble de cas de tests ne trouvera plus de nouveaux
défauts.
 Revoir et réviser régulièrement les cas de tests
 Ecrire de nouveaux tests, différents des anciens
 Couvrir d’autres chemins dans le logiciel ou le système
51
Principe 6 : Les tests dépendent du contexte
Les tests sont effectués différemment dans des contextes différents.
Un système archaïque sera testé différemment d’un système plus intelligent.
e.g. Les logiciels critiques de sûreté seront testés différemment
d’un site de commerce électronique
52
Principe 7 : L’ illusion de l’absence d’erreurs
Trouver et corriger des défauts n’aide pas si le système conçu est
inutilisable et ne comble pas les besoins et les attentes des utilisateurs.
• Par exemple, tester en profondeur toutes les exigences spécifiées et corriger
tous les défauts trouvés pourrait toujours produire un système qui est difficile
à utiliser, qui ne répond pas aux besoins et aux attentes des utilisateurs
ou qui est moins performants comparé à d'autres systèmes concurrents
53
1.1 Qu'est-ce qu’un test?
1.2 Pourquoi les tests sont-ils nécessaires ?
1.3 Les sept principes généraux des tests
1.4 Processus de test
Objectifs d'apprentissage (LO):
LO-1.4.1
Le processus de test dans le contexte(K2)
LO-1.4.2
Activités et tâches de test(K2)
LO-1.4.3
Les produits d’activités du test(K2)
LO-1.4.4
Traçabilité entre les bases de test et les produits d’activités du test (K2)
54
1.4 Processus de test
• Le processus de test logiciel approprié et spécifique dans une
situation donnée dépend de nombreux facteurs
− 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?
• Ces facteurs peuvent être précisés dans la stratégie de test
d’une organisation
55
1.4.1 Le processus de test dans le contexte
• Les facteurs contextuels qui influencent le processus de test d'une
organisation comprennent
− Le modèle de SLC et les méthodologies de projet utilisées
− Les niveaux de test et les types de test prévus
− Les risques liés aux produits et aux projets
− Le domaine d’activités
• Les contraintes opérationnelles incluent
− Les budgets et ressources
− Les délais
− La complexité
− Les exigences contractuelles et réglementaires, etc.
56
1.4.2 Activités et tâches de test
57
1.4.2 Activités et tâches de test
• Chaque groupe d’activités est composé d’activités constitutives
• Chaque activité au sein de chaque groupe d’activités peut à son tour consister en de multiples tâches
individuelles, qui peuvent varier d'un projet ou d'une version à une autre
• De plus, même si plusieurs de ces groupes d’activités peuvent sembler logiquement séquentiels, ils sont
souvent mis en œuvre de façon itérative
• Le développement Agile implique de petites itérations de conception de logiciels, de construction et de
test qui se produisent en continu, soutenues par une planification régulière. Ainsi, les activités de test se
déroulent également de façon itérative et continue dans le cadre de cette approche de développement.
• Même en mode séquentiel, la séquence logique par étapes des activités induira le chevauchement, la
combinaison, de sorte qu’une adaptation de ces activités principales dans le contexte du système et du
projet est habituellement nécessaire
58
1.4.2 Activités et tâches 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
Exemple: spécifier les techniques et tâches de test appropriées, et
produire un calendrier de test pour respecter une date limite
• Les plans de test peuvent être revus en fonction des retours sur les
activités de pilotage et de contrôle
59
1.4.2 Activités et tâches de test
Pilotage et contrôle des tests
• Le pilotage des tests implique 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 pilotage et le contrôle des tests se basent sur l'évaluation des
critères de sortie, que l'on appelle « definition of done » dans
certains cycles de vie
• Par exemple, l’évaluation des critères de sortie pour l'exécution des
tests dans le cadre d’un niveau de test (La vérification des résultats et
logs de test par rapport aux critères de couverture spécifiés)
60
1.4.2 Activités et tâches de test
Analyse de test (quoi tester?)
• Pendant l’analyse de test, les bases de test sont analysées pour
identifier les caractéristiques testables et définir les conditions de test
associées (quoi tester, critère de couverture mesurable).
− Activité 1: Analyser les bases de test appropriées au niveau de test
considéré (UML, l’implémentation de la base des composants ou
du système, rapport d’analyse de risque fonctionnel , non
fonctionnel et structurel)
− Activité 2 : Evaluer les bases de test et des éléments de test pour
identifier des défauts de différents types (Ambiguïtés,
Incohérences, Inexactitudes, Contradictions, etc)
61
1.4.2 Activités et tâches de test
• Activité 3: Identifier les caractéristiques (éléments) et les ensembles de
caractéristiques à tester
• Activité 4: Définir et prioriser les conditions de test pour chaque
caractéristique en fonction de l’analyse des bases de test et en tenant
compte des caractéristiques fonctionnelles, non-fonctionnelles et
structurelles, des autres facteurs métiers et techniques, et des niveaux de
risque
• Activité 5: Capturer la traçabilité bidirectionnelle entre chaque élément
des bases de test et les conditions de test associées
Les conditions de test qui doivent être utilisées comme objectifs de test dans
des chartes de test (durant les sessions des tests)
62
1.4.2 Activités et tâches de test
• Remarque: activités d’analyse de test ne se contentent pas de vérifier si
les exigences sont cohérentes, correctement exprimées, et complètes,
mais aussi de valider si les exigences capturent correctement les
besoins des clients, utilisateurs et des autres parties prenantes
Exemple: les techniques telles que le BDD (Behavior-Driven
Developement) et ATDD (Acceptance Test-Driven Development), qui
impliquent la définition des conditions de test et de cas de test à partir
des User Story et des critères d’acceptation avant le codage, permettent
aussi de vérifier, valider et détecter des défauts dans les User Stories et
les critères d’acceptation
63
1.4.2 Activités et tâches de test
Conception des tests (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
• La déclinaison des conditions de test lors de la conception implique
souvent l’utilisation de techniques de test
64
1.4.2 Activités et tâches de test
Implémentation des tests (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 (y compris, potentiellement, les
harnais de test, la virtualisation des services, les simulateurs et
d’autres éléments d’infrastructure) et vérifier que tout le nécessaire a
été correctement mis en place
65
1.4.2 Activités et tâches de test
− 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
• Les tâches de conception et d’implémentation des tests sont souvent combinées.
• Dans le cas des tests exploratoires et d’autres types de tests basés sur l’expérience, 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 peuvent être basés sur des chartes de test (produites dans le
cadre de l’analyse de test)
• Les tests exploratoires sont exécutés immédiatement, en même temps que leur
conception et leur implémentation
66
1.4.2 Activités et tâches de test
Exécution des tests
• 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
• 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
• Test de confirmation et de régression
67
1.4.2 Activités et tâches de test
Clôture des tests
• Vérifier si tous les rapports de défauts sont clôturés
• 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
− Remettre le testware aux équipes de maintenance, aux autres équipes de projet,
et/ou à d’autres parties prenantes qui pourraient bénéficier de son utilisation
− Analyser les leçons apprises des activités de test terminées
68
1.4.3 Les produits d’activités du test
Produits d’activités de la planification des tests (Le plan de test comprend
des informations sur les bases de test, critère E/S, risque)
Produits d’activités du pilotage et contrôle des tests (compris les rapports
d'avancement des tests, synthèse des tests, un résumé des résultats de
l'exécution)
Produits d’activités de l’analyse de test (comprennent les conditions de test
définies et priorisées, dont chacune est idéalement traçable de façon
bidirectionnelle avec le ou les élément(s) spécifiques des bases de test
qu'elle couvre) Pour les tests exploratoires, l'analyse de test peut impliquer
la création de chartes de test.
Produits d’activités de la conception des tests (La conception de cas de tests
de haut niveau, affiner ou finaliser les conditions , les données,
l’environnement)
69
1.4.3 Les produits d’activités du test
Produits d’activités de l’implémentation des tests
− Les procédures de test et l’ordonnancement de ces procédures de test
− Les suites de test
− Un calendrier d'exécution des tests.
• l'atteinte des critères de couverture établis dans le plan de test peut être
démontrée par une traçabilité bidirectionnelle entre les procédures de test
et des éléments spécifiques des bases de test, au travers des cas de test et
des conditions de test
• la création et la vérification de données de test et de l'environnement de
test. Les conditions de test définies dans l'analyse de test peuvent être
affinées (finalisées) lors de l’implémentation des tests
• Les résultats attendus concrets qui sont associés à des données concrètes
de test sont identifiés à l'aide d'un oracle de test
70
1.4.3 Les produits d’activités du test
Produits d’activités de l’exécution des tests
• La documentation du statut de chaque cas de test ou des procédures de
test (exemple: prêt à être exécuté, réussite, échec, blocage, délibérée, etc.)
• Les rapports de défauts
• La documentation précisant quel(s) élément(s) de test, objet(s) de test,
outils de test et testware ont été impliqués dans le test.
• Idéalement, une fois l'exécution des tests terminée, le statut de chaque
élément des bases de test peut être déterminé et indiqué par traçabilité
bidirectionnelle avec la ou les procédures de test associée(s).
71
1.4.3 Les produits d’activités du test
Produits d’activités de la clôture des tests
• les rapports de synthèse de test
• les mesures à prendre pour améliorer les projets ou les itérations
ultérieurs
72
1.4.4 Traçabilité entre les bases de test
et les produits d’activités du test
• Importance 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.
• 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
 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
73
1.1 Qu'est-ce qu’un test?
1.2 Pourquoi les tests sont-ils nécessaires ?
1.3 Les sept principes généraux des tests
1.4 Processus de test
1.5 La psychologie des tests
Objectifs d'apprentissage (LO):
LO-1.5.1 Identify the psychological factors that influence the success of testing (K1)
LO-1.5.2 Explain the difference between the mindset required for test activities and the mindset required
for development activities (K2)
74
1.5 La Psychologie des Tests
• Un certain degré d’indépendance (évitant la partir-pris de l’auteur) est
souvent plus efficace pour détecter des défauts et des défaillances.
• Plusieurs niveaux d’indépendance peuvent être définis, comme les niveaux
suivants présentés du plus faible au plus élevé :
• Tests conçus par la (les) personne(s) qui a (ont) écrit le logiciel à tester (niveau
faible d’indépendance).
• Tests conçus par une (des) autre(s) personne(s) (exemple: équipe de
développement).
• Tests conçus par une (des) personne(s) d’un groupe différent au sein de la même
organisation (exemple: équipe de test indépendante) ou par des spécialistes de
test (exemple: spécialistes en tests de performance ou utilisabilité)
• Tests conçus par une (des) personne(s) d’une organisation ou société différente
(exemple: sous-traitance ou certification par un organisme externe)
75
1.5 La Psychologie des Tests
• Il existe plusieurs manières d’améliorer la communication et les
relations entre les testeurs et leurs interlocuteurs :
• Commencer par une collaboration plutôt que par des conflits – rappeler à
chacun l’objectif commun de systèmes de meilleure qualité
• Communiquer les découvertes sur le produit de façon neutre et factuelle sans
critiquer la personne responsable, par exemple, écrire des rapports
d’incidents (ou des résultats de revues) objectifs et factuels.
76
1.5 La Psychologie des Tests
• Essayer de comprendre ce que ressent une autre personne et pourquoi elle
réagit comme elle le fait.
• Confirmer que l’autre personne a compris ce que l’on a dit et vice versa.
77
1.1 Qu'est-ce qu’un test?
1.2 Pourquoi les tests sont-ils nécessaires ?
1.3 Les sept principes généraux des tests
1.4 Processus de test
1.5 La psychologie des tests
Quizz
78
88
89
90
91
92
93
94
95
96
Differentiate the following test work products ++
 Test suite : Suite de test : Ensemble de plusieurs cas de tests pour un composant ou
système à tester, dont les post-conditions d’un test sont souvent utilisées comme préconditions du test suivant
 Test case : Cas de test : un ensemble de valeurs d’entrée, de préconditions d’exécution,
de résultats attendus et de postconditions d’exécution, développées pour un objectif ou
une condition de tests particulier, tel qu’exécuter un chemin particulier d’un programme
ou vérifier le respect d’une exigence spécifique
 Test script : Script de test : Généralement utilisé pour se référer à une spécification de
procédure de test, surtout une procédure automatisée
 Test charter : Charte de test : Une expression d’objectifs de test et éventuellement
d’idées de test au sujet de la façon de tester. Les agréments de test sont utilisés en test
exploratoire.
Differentiate the following test work products ++
 Test strategy : Stratégie de test : Document de haut niveau définissant, pour un
programme, les niveaux de tests à exécuter et les tests dans chacun de ces niveaux
 Test procedure : Spécification de procédure de test : Document spécifiant la séquence
d’actions pour l’exécution d’un test. Aussi connu sous le terme de script de test ou script
de test manuel.
 Test basis : Base de tests : tous les documents à partir desquels les exigences d’un
composant ou système peuvent être déduites. La documentation sur laquelle les cas de
tests sont basés
 Test specification : Spécification de test : Document qui consiste en une spécification de
conception du test, des spécifications de cas de test et/ou des spécifications de
procédures de test.
 Test data : Données de tests : Donnée existante (ex. : dans une base de données) avant
qu’un test ne soit exécuté et qui affecte ou est affectée par le composant ou système en
test.
 Testware : les scripts, les entrées, les résultats attendus, les procédures d’installation et
de nettoyage, les fichiers, les bases de données, les environnements
Differentiate the following test work products ++
 Test policy : Politique de test : Document de haut niveau décrivant les principes,
approches et objectifs majeurs de l’organisation concernant l’activité de test.
 Test plan : Plan de test : Document décrivant l’étendue, l’approche, les ressources et le
planning des activités de test prévues. Il identifie entre autres les éléments et
caractéristiques à tester/ l’affectation des tâches/ le degré d’indépendance des testeurs/
l’environnement de test/ les techniques de conception des tests / les techniques de
mesure des tests à utiliser ainsi que tout risque nécessitant la planification de
contingence.
 Test process : Processus de test : Processus de test fondamental comprenant la
planification, la spécification, l’exécution, l’enregistrement et la vérification de
l’achèvement.
 Test Harness : Harnais de test : Environnement comprenant les bouchons et les pilotes
nécessaires pour exécuter un test.