Préparation à la certification

ISTQB - International
Software Testing
Qualifications Board
Ezzine Missaoui
2022 - 2023
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
ISTQB Foundation Level
ISTQB Foundation Level Exam
Chap1 : Fondamentaux des tests
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
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
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.
Que sont les tests ?

● 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]
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 système testé, du niveau de
test et du modèle de cycle de vie de développement logiciel.
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 les défauts.
❑ Le test de confirmation vérifie si les corrections apportées ont résolu
les défauts.

➢ Les testeurs sont responsables du test initial et du test de confirmation

final,
➢ Les développeurs se chargent du débogage et du test des composants
concernés.

o NB : Dans le développement Agile, les testeurs peuvent être impliqués

dans le débogage et le test des systèmes.
Pourquoi les tests sont-ils nécessaires ? Assurance qualité et test
Assurance qualité et test :
Assurance qualité Test (Contrôle qualité)
• Mise en place d'une approche • Mise en place d'une approche curative
préventive de la qualité. de la qualité.

• Respect des processus adéquats ce qui • Assurer que les exigences fonctionnels
contribue à la prévention des défauts. et non fonctionnels sont satisfait .
• L'analyse des causes racines pour • Le contrôle qualité combine diverses
détecter et éliminer les causes des activités, y compris des activités de test,
défauts. qui contribuent à l'atteinte de niveaux de
• L'application des résultats des réunions qualité adéquats.
de rétrospective pour améliorer les • Les activités de test font partie du
processus. 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é.
Pourquoi les tests sont-ils nécessaires ? Erreurs, défauts et défaillances
❑ Une personne peut faire une erreur, ce qui peut conduire à l'introduction d'un défaut
dans le code du logiciel ou dans un autre produit d’activités connexe. Si un défaut dans
le code est exécuté, cela peut causer une défaillance.
➢ 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 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û
Pourquoi les tests sont-ils nécessaires ? Erreurs, défauts et défaillances
❑ Les causes racines des défauts sont les premières actions ou conditions qui
ont contribué à la création des défauts.
o Les contraintes de temps
o La faillibilité humaine
o Le manque de compétence des participants au projet
o Une mauvaise communication entre les participants au projet
o La complexité du code, de la conception, de l'architecture, du problème sous-jacent à
résoudre, et/ou des technologies utilisées
o Les malentendus sur les interfaces intra-système et inter-système
o Des technologies nouvelles, peu connues
o Conditions environnementales.
Les 7 principes sur les tests
1. Les tests montrent la présence de défauts, pas leur absence
2. Les tests exhaustifs (complets) sont impossibles
3. Tester tôt (à l’avance) é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
Processus de test - Activités et taches de test
Processus de test - Le processus de test dans le contexte
Les facteurs qui influencent le processus de test :
o Le modèle de cycle de vie du développement logiciel et les
méthodologies de projet utilisées
o Les niveaux de test et types de test prévus
o Les risques liés aux produits et aux projets
o Le domaine d'activité
o Les contraintes opérationnelles, entre autres :
▪ Les budgets et ressources
▪ Les délais
▪ La complexité
▪ Les exigences contractuelles et réglementaires
o Les politiques et pratiques organisationnelles
o 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
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
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
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.
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/défaillance 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 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
Processus de test - Activités et taches de test
❑ Les produits d’activités du test
Processus de test - Activités et taches 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
La psychologie des tests- Activités et taches de test
❑ 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.
La psychologie des tests- Activités et taches de test
❑ Psychologie humaine et test
➢ 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
➢ Confirmer que l'autre personne a compris ce qui a été dit et vice versa.
La psychologie des tests- Activités et taches de test
❑ 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..
Chap2 : Tester pendant le cycle de vie du développement
1. Les modèles de développement logiciel
2. Niveaux de test
3. Types de test
4. Tests de maintenance
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.
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 :
o Modèles de développement séquentiel
o Modèles de développement itératif et incrémental
Les modèles de développement logiciel
❑ Les modèles de développement
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
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.
Les modèles de développement logiciel
❑ Développement de logiciel et tests logiciels
Spiral (ou par prototypage) : il s'agit de créer des incréments expérimentaux
Les modèles de développement logiciel
❑ Développement de logiciel et tests logiciels
➢ Agile
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.
Les modèles de développement logiciel
❑ Développement de logiciel et tests logiciels
➢ Kanban : mis en œuvre 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 livrer en une fois
Les modèles de développement logiciel
❑ Développement de logiciel et tests logiciels
➢ Les modèles de cycle de vie du développement logiciel eux-mêmes peuvent
être combinés. Exemple : Les systèmes Internet des Objets (IoT – Internet of
Things), qui se composent de nombreux objets différents, tels que des
équipements, des produits et des services, appliquent généralement des
modèles de cycle de développement logiciel distincts pour chaque objet.
Niveaux de test
❑ Les niveaux de test utilisés dans ce cours sont les suivants :
Niveaux de test
❑ Test de composants
Niveaux de test
❑ Test d'intégration
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.
Niveaux de test
❑ Test système
Niveaux de test
❑ Test d'acceptation
Niveaux de test
❑ Test d'acceptation
Types de test
❑ Tests fonctionnels / Tests non fonctionnels
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 : refaire 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 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.
✓ 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é.
✓ Le déclassement, par exemple lorsqu'une application arrive en fin de vie
➢ Lorsqu'une application ou un système est mis hors service, il peut être nécessaire de tester la
migration ou l'archivage des données si de longues périodes de conservation des données
sont nécessaires. Il peut également être nécessaire de tester les procédures de
restauration/récupération après l'archivage pour de longues périodes de conservation
Analyse d'impact pour la maintenance
❑ L'analyse d'impact évalue les changements qui ont été apportés afin
d'identifier les conséquences prévues ainsi que des effets secondaires
attendus et possibles d'un changement, et d'identifier les zones du système
qui seront affectées par le changement.
❑ L'analyse d'impact peut être difficile si :
✓ 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
Chap3 : Tests statiques

1. Bases des tests statiques

2. Processus de revue
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.
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.
Tests statiques
Bases des tests statiques
➢ Contrairement aux tests dynamiques, qui nécessitent l'exécution du logiciel testé,
les tests statiques reposent sur l'examen manuel des produits d’activités (c.-à-d. les
revues) ou sur une évaluation outillée du code ou d'autres produits d’activités (c.-à-d.
l'analyse statique).
➢ Les tests statiques évaluent le code ou tout autre produit d’activités testé sans
exécuter réellement le code ou le produit d’activités testé.
➢ Les revues varient d’informelles à formelles. La focalisation d'une revue dépend des
objectifs fixés pour la revue trouver des défauts gagner en compréhension former les
participants tels que des testeurs et de nouveaux membres de l'équipe discuter et
décider par consensus
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étectables 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
Tests statiques
Les défauts 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é
● Lacunes dans la traçabilité ou la couverture des bases de test (p. ex., des tests manquants
pour un critère d'acceptation)
● ** Code mort : code inatteignable
Tests statiques
Processus de revue
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.
Tests statiques
Rôles et responsabilités dans une revue formelle
Tests statiques
Types de revue
Tests statiques
Types de revue
Tests statiques
Facteurs de réussite
● Les facteurs de réussite organisationnels pour les revues incluent:
○ Chaque revue a des objectifs clairs, définis lors de la planification de la revue
○ Le type de revue est choisi en fonction des objectifs
○ 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
○ Les participants ont suffisamment de temps pour préparer
○ Le management appuie le processus de revue Les facteurs de succès liés aux
participants aux revues sont les suivants:
○ Le choix des bonnes personnes contribue à l'atteinte des objectifs de la revue
○ Les participants consacrent suffisamment de temps et d'attention aux détails
○ Le résultat ne sera pas utilisé pour l'évaluation des participants
○ Les participants évitent le langage corporel
○ Une formation adéquate est fournie