Chapitre 1 : Fondamentaux des tests (résumé en 3 pages)

1.1 Que sont les tests ?

- Les tests logiciels évaluent la qualité et réduisent les risques de défaillance.

- Ils impliquent des activités spécifiques à chaque niveau de test, statique ou dynamique.
- Les tests dynamiques impliquent l'exécution, tandis que les tests statiques n'impliquent pas
d'exécution.
- Les tests ne vérifient pas seulement les exigences, mais s'assurent que le système répond aux
besoins des utilisateurs.
- Adaptés aux cycles de vie des logiciels.

1.1.1 Objectifs habituels des tests (EVV CPI TRC)

1. Évaluation des produits d'activités.

2. Vérification des exigences spécifiées.
3. Validation de l'objet de test.
4. Construction de la confiance dans la qualité.
5. Prévention des défauts.
6. Identification des défaillances et défauts.
7. (Traçabilité) Fourniture d'informations aux parties prenantes.
8. Réduction du risque lié à la qualité logicielle.
9. Conformité aux exigences.
- Ces objectifs sont adaptables au contexte du projet et ont un impact majeur sur le succès des
activités de test.

1.1.2 Test et débogage

- Le test met en évidence les défauts.

- Le débogage est une activité de développement visant à corriger les défauts.

1.2 Pourquoi les tests sont-ils nécessaires ?

- Les tests contribuent à améliorer la qualité des composants ou des systèmes.

- Ils peuvent être indispensables pour respecter les exigences contractuelles, légales ou les
normes de l'industrie.

1.2.1 Contribution des tests au succès

- La participation des testeurs aux revues des exigences détecte les défauts.
- La collaboration entre testeurs et concepteurs réduit les défauts dans la conception.
- La collaboration entre testeurs et développeurs améliore la qualité du code.
- Les tests détectent des défaillances potentielles avant la mise en production.

1.2.2 Assurance qualité et test

- Les tests font partie intégrante du processus global de développement ou de maintenance du

logiciel.
- L'assurance qualité soutient des tests pertinents en veillant à l'exécution correcte du processus.

1.2.3 Erreurs, défauts et défaillances

- Diverses raisons peuvent entraîner des erreurs, conduisant à l'introduction de défauts.

- Les défaillances peuvent résulter de contraintes de temps, fiabilité humaine, inexpérience,
communication défaillante, complexité, nouvelles technologies, et défaillances
environnementales.

1.2.4 Défauts, causes racines et effets

- Les causes racines sont les actions initiales qui ont contribué à la création des défauts.
- Analyser les causes racines permet d'identifier des améliorations de processus.

1.3 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.

1.4 Processus de test

- Pas de processus de test unique, mais des activités communes essentielles.

- Les activités dépendent du contexte du projet, du modèle de cycle de vie, et des besoins
spécifiques.

1.4.1 Le processus de test dans le contexte

- Facteurs contextuels influent sur le processus de test, tels que le modèle de cycle de vie, les
niveaux de test, les risques, le domaine d'activité, les contraintes opérationnelles, les politiques et
normes.

1.4.2 Activités et tâches de test PACIECC

- Groupes d'activités du processus de test : Planification, Suivi et contrôle, Analyse, Conception,

Implémentation, Exécution, Clôture.
- Activités peuvent être itératives, se chevaucher, ou être omises selon le contexte.

1.4.3 Les produits d’activités du test

- Pilotage et contrôle des tests impliquent l'évaluation régulière de l'avancement et des mesures
pour atteindre les objectifs.
- Analyse de test comprend l'évaluation des bases de test, l'identification des caractéristiques à
tester, et la définition des conditions de test.
1.4.4 Traçabilité entre les bases de test et les produits d’activités du test

- La traçabilité facilite l'analyse d'impact, l'audit, la satisfaction des critères de acceptation,

l'amélioration de la clarté des rapports, et la communication avec les parties prenantes.

1.5 La psychologie des tests

1.5.1 Psychologie humaine et test

- Identifier des défauts peut être perçu comme une critique.

- Pour une communication efficace, favoriser la collaboration, souligner les avantages,
communiquer de manière neutre, comprendre les réactions, et confirmer la compréhension
mutuelle.

1.5.2 État d’esprit des testeurs et des développeurs

- Perception des tests et biais psychologiques peuvent affecter la communication.

- La communication constructive des défauts, les compétences interpersonnelles, et la définition
claire des objectifs sont essentielles.

Chapitre 2 : Tester pendant le cycle de vie du développement

logiciel (2p)

2.1.1 Développement de logiciel et tests logiciels

• Rôle du Testeur et Bonnes Pratiques
• Compréhension des modèles de cycle de vie.
• Tests pour chaque phase, objectifs spécifiques, implication tôt des testeurs.
 • "Tester Tôt" dans le Cycle de Développement
• Début des tests tôt, quel que soit le modèle de développement.
• Modèles de Cycle de Vie
• Séquentiel vs itératif/incrémental.
• Modèles "Cascade" et "en V" avec intégration précoce du test.
• Comparaison des Modèles
• Modèles séquentiels pour des produits complets, mais lents.
• Incrémental pour développer et tester progressivement.
2.1.2 Modèles de cycle de vie en contexte
• Sélection et Adaptation des Modèles
• Choix basé sur le contexte, objectifs, type de produit, priorités et risques.
• Combinaison de Niveaux et Activités de Test
• Ajustement des niveaux et activités en fonction du contexte.
• Combinaison de Modèles de Cycle de Vie
• Utilisation de modèles distincts pour les objets IoT.
2.2 Niveaux de test
• Niveaux de Test
• Groupes d'activités organisées, couvrant unités à systèmes complets.
• Niveaux Utilisés dans ce Syllabus
• Test de composants, intégration, système, acceptation.
2.2.1 Test de composants
• Objectifs :
• Tester des composants individuels, réduire les risques.
• Rôle des Tests de Régression Automatisés :
• Cruciaux dans les modèles incrémentaux.
• Exécution des Tests de Composants :
• Indépendante, parfois avec des objets fictifs.
• Portée des Tests de Composants :
• Fonctionnelles, non-fonctionnelles, propriétés structurelles.
 • Bases de test :
• Conception détaillée, code, spécifications.

2.2.2 Test d'intégration

• Objectifs :
• Intégration de composants, interactions système, éviter défauts.
• Bases de test :
• Conception, spécifications, architecture.
• Défauts courants :
• Problèmes d'intégration, défaillances de communication.
• Approches :
• Intégration continue, analyse des risques.
2.2.3 Test système
• Objectifs :
• Comportement et capacités du système dans son ensemble.
• Bases de test :
• Exigences système, cas d'utilisation, manuels.
• Défauts courants :
• Calculs incorrects, comportement défaillant.
• Approches :
• Focus global, tests indépendants.
2.2.4 Test d'acceptation
• Objectifs :
• Établir confiance, valider conformité, répondre aux exigences.
• Types :
• Utilisateur, opérationnel, contractuel, alpha/bêta.
• Bases de test :
• Exigences, cas d'utilisation, régulations.
• Défauts courants :
 • Non-conformité, défaillances non-fonctionnelles.
• Approches :
• Tests indépendants, implication précoce.
2.3 Types de test
• Tests de Qualité Fonctionnelle :
• Évaluer complétude, exactitude et pertinence.
• Tests de Qualité Non-Fonctionnelle :
• Fiabilité, performance, sécurité, compatibilité.
• Tests d'Effets des Changements :
• Confirmation de correction (tests de confirmation), recherche de régressions (tests
de régression).

2.3.1 Tests fonctionnels

• Responsabilité : Clients, utilisateurs, Product Owners.
• Position : Fin de cycle ou lors d'installations/intégrations.
• Développement Itératif : Tests à chaque itération, incluant alpha/bêta.
• Types : Utilisateur, opérationnel, réglementaire, contractuel.
2.3.2 Tests non-fonctionnels
• Nature : Évaluer utilisabilité, performance, sécurité.
• Focalisation : Sur "comment" le système se comporte.
• Timing : À tous les niveaux et le plus tôt possible.
2.3.3 Tests boîte-blanche
• Nature : Basés sur la structure interne, incluant code.
• Mesure de Complétude : Couverture structurelle (% couverture).
• Niveaux de Mesure : Composants, intégration (interfaces).
2.3.4 Tests liés aux changements
• Test de Confirmation :
• Confirmer que les modifications ont corrigé le défaut.
 • Tests de Régression :
• Détecter les régressions causées par les changements.
2.3.5 Types de test et niveaux de test (voir résumé v2)
2.4 Tests de maintenance
• Objectif des Tests de Maintenance : Évaluer les modifications et détecter les
régressions.
• Portée des Tests de Maintenance : Inclut divers tests en fonction de la portée du
changement.
• Facteurs Influents :
• Risque du Changement : Évaluer l'impact sur d'autres composants.
• Taille du Système : Considérer l'étendue et la complexité.
• Taille du Changement : Tenir compte de l'importance et de la complexité.
• Déclencheurs de Maintenance :
• Modification : Englobe les améliorations, corrections et changements
d'environnement.
• Migration : Implique un changement de plate-forme.
• Déclassement : Relatif à la fin de vie de l'application.
• Tests Spécifiques :
• Migration/archivage de données, procédures de restauration/récupération.
• Systèmes IoT : Intégration d'objets, tests de sécurité.
• Analyse d'Impact :
• Objectif : Évaluer les conséquences et les effets secondaires d'un changement.
• Préparation : Avant l'implémentation, malgré des défis potentiels.
• Difficultés : Spécifications obsolètes, cas de test non documentés, manque de
traçabilité, connaissance limitée du système.

Chapitre 3 : Tests statiques

3.1 Bases des tests statiques
• Tests Statiques :
• Description : Évaluation du code ou d'autres produits d'activités sans exécuter le
 logiciel testé.
• Types :
• Revues : Examen manuel des produits d'activités.
• Analyse Statique : Évaluation automatisée du code ou d'autres produits
d'activités.
• Applications : Cruciale pour les systèmes critiques (aéronautique, médical,
nucléaire) et largement utilisée dans d'autres contextes (sécurité, développement
Agile, livraison continue).
• Objectif : Détecter des erreurs, des vulnérabilités, ou des problèmes potentiels
sans exécuter le logiciel.
3.1.1 Produits d’activités qui peuvent être examinés par des tests statiques
• Applications des Tests Statiques :
• Description : Évaluation des produits d'activités sans exécuter le logiciel, utilisant
des revues manuelles ou des analyses statiques.
• Produits d'Activités Applicables : Spécifications, code, testware, guides
utilisateur, contrats, etc.
• Méthodes : Revues (applicables à tout produit lisible), Analyse Statique (efficace
pour les produits avec structure formelle).
3.1.2 Bénéfices des tests statiques
• Avantages des Tests Statiques :
• Détection Précoce des Défauts : Identification des défauts avant les tests
dynamiques, réduisant les coûts de correction.
• Coût-Efficacité : Correction moins coûteuse des défauts détectés tôt.
• Autres Avantages : Identification de défauts non-évidents, prévention des défauts,
amélioration de la productivité, réduction des coûts et délais.

3.1.3 Différences entre les tests statiques et dynamiques

• Tests Statiques :
• Détection des Défauts : Identifient les défauts directement dans les produits
d'activités sans les exécuter.
• Défauts Détectés : Problèmes dans les exigences, conception, code, non-
conformité aux normes, etc.
 • Objectif : Améliorer la qualité interne et la cohérence des produits d'activités.
• Tests Dynamiques :
• Détection des Défauts : Identifient les défauts en exécutant le logiciel et en
observant son comportement réel.
• Défauts Détectés : Problèmes de fonctionnement ou de comportement lors de
l'exécution du logiciel.
• Objectif : Évaluer le comportement visible du logiciel.
3.2 Processus de revue
• Les revues varient de informelles à formelles.
• Objectifs des revues : Détection des défauts, compréhension, formation, prise de
décisions.
3.2.1 Processus de revue de produits d’activités
• Planification :
• Définir le périmètre : Objectif, documents à examiner, caractéristiques de qualité.
• Estimer l'effort et le temps : Estimation du temps et des ressources nécessaires.
• Identifier les caractéristiques : Type de revue, rôles, activités, checklists.
• Sélectionner les participants : Identifier et attribuer les rôles.
• Définir des critères : Critères d'entrée et de sortie, vérification préalable.
• Lancement de la revue :
• Distribution des documents : Fournir le produit d'activités et expliquer le
contexte.
• Revue individuelle : Examen, notation des défauts, communication et analyse des
problèmes, correction et production de rapports.
3.2.2 Rôles et responsabilités dans une revue formelle
• Auteur, Manager, Facilitateur, Responsable de la revue, Réviseurs, Scribe.
• Rôles de chacun détaillés.
3.2.3 Types de revue
• Revue informelle, Relecture technique, Revue technique, Inspection.
• Objectifs et caractéristiques associés à chaque type.
3.2.4 Application des techniques de revue
• Ad hoc, Basée sur les checklists, Scénarios et essais à blanc, Basée sur les rôles, Basée
sur la perspective.
 • Description de chaque technique.
3.2.5 Facteurs de réussite des revues
• Facteurs organisationnels et liés aux participants.
• Objectifs clairs, choix du type approprié, techniques adaptées, checklists complètes,
révision par petites unités, temps de préparation, soutien du management, sélection de
bons participants, implication des testeurs, traitement objectif des défauts, gestion
efficace de la réunion, climat de confiance, formation adéquate, promotion de la culture
de l'apprentissage.

Chapitre 4 : Techniques de test

4.1 Catégories de techniques de test

4.1.1 Choix des techniques de test
• Type de composant ou de système :
• Différents types de composants ou systèmes peuvent nécessiter des approches de test
différentes en fonction de leur nature.

• Complexité du composant ou du système :

• La complexité peut influencer la sélection des techniques de test pour garantir une
couverture adéquate.

• Normes réglementaires :
• Respecter les normes réglementaires spécifiques est crucial et peut orienter le choix des
techniques de test.

• Exigences client ou contractuelles :

• Les exigences du client ou celles stipulées dans le contrat peuvent déterminer les
approches de test à adopter.

• Niveaux de risque :
• Évaluer les niveaux de risque associés au composant ou au système peut influencer les
priorités et les techniques de test à utiliser.

• Types de risques :
• Différents types de risques peuvent nécessiter des approches de test différentes pour les
atténuer.

• Objectifs du test :
• Les objectifs spécifiques des tests, tels que la détection de certaines classes de défauts,
peuvent orienter le choix des techniques de test.
 • Documentation disponible :
• La disponibilité de documentation pertinente peut influencer le choix des techniques de
test à utiliser.

• Connaissances et compétences des testeurs :

• Les compétences et l'expérience des testeurs peuvent influencer le choix des techniques
de test et leur mise en œuvre.

• Outils disponibles :
• La disponibilité d'outils de test peut influencer le choix des techniques qui peuvent être
efficacement mises en œuvre.

• Temps et budget :
• Les contraintes de temps et de budget peuvent déterminer les techniques de test les
plus réalisables dans un certain contexte.

• Modèle de cycle de vie du développement logiciel :

• Le modèle de cycle de vie du développement logiciel utilisé peut influencer le moment
et la manière d'appliquer les techniques de test.

• Utilisation prévue du logiciel :

• L'utilisation prévue du logiciel peut influencer les scénarios de test et donc les
techniques à appliquer.

• Expérience antérieure de l'utilisation des techniques de test :

• L'expérience passée avec certaines techniques peut orienter le choix des techniques de
test.

• Types de défauts attendus dans le composant ou le système :

• Les types de défauts attendus peuvent influencer les choix des techniques pour détecter
ces défauts spécifiques.

4.1.2 Catégories de techniques de test et leurs caractéristiques

Techniques de test boîte-noire :
• Basées sur une analyse de la base de test appropriée.

• Applicables aux tests fonctionnels et non-fonctionnels.

• Se concentrent sur les entrées et sorties sans référence à la structure interne.

• Conditions, cas de test et données dérivent de la base de test.

• Utilisées pour détecter les écarts entre les exigences et l'implémentation.

Techniques de test boîte-blanche :

• Basées sur l'analyse de la structure interne.
 • Se concentrent sur la structure et le traitement interne.

• Conditions, cas de test et données dérivent de la base de test, incluant le code.

• Mesure la couverture en fonction des éléments testés dans une structure donnée.

• Souvent utilisent des spécifications pour déterminer le résultat attendu.

Techniques de test basées sur l'expérience :

• Tirent parti de l'expérience des développeurs, testeurs et utilisateurs.

• Souvent combinées à des techniques boîte-noire et boîte-blanche.

• Conditions, cas de test et données dérivent de la base de test incluant les connaissances et
l'expérience des parties prenantes.

• Comprend l'utilisation prévue, l'environnement, les défauts probables et leur répartition.

4.2 Techniques de test boîte-noire
4.2.1 Partitions d'équivalence
Caractéristiques principales et principes liés aux partitions d'équivalence :
• Définition des partitions :

• Création pour valeurs valides et invalides.

• Les valeurs valides doivent être acceptées, les invalides rejetées.

• Identification des partitions :

• Définies pour tout élément lié à l'objet de test.

• Chaque valeur appartient à une partition.

• Traitement des partitions :

• Tester chaque partition individuellement.

• Éviter la combinaison de partitions invalides.

• Objectif de la couverture :

• Atteindre une couverture complète avec des cas de test couvrant toutes les partitions.

• Applicabilité :

• Applicable à tous les niveaux de test.

4.2.2 Analyse des valeurs limites

Principaux points liés à l'analyse des valeurs limites :
• Définition des valeurs limites :

• Minimale, maximale, et valeurs juste en dehors des limites.

 • Exemple d'application :

• Pour un champ acceptant 1 à 5, limites sont 1, 5, 0 et 6-9.

• Identification des valeurs limites :

• Deux ou trois valeurs par limite entre partitions.

• Objectif de la couverture :

• Tester les comportements aux limites.

• Applicabilité :

• Applicable à tous les niveaux, utile pour valeurs numériques.

4.2.3 Test de tables de décision

Notations associées aux tables de décision :
• Utilité des tables de décision :

• Répertorier les règles métier complexes.

• Chaque ligne représente une combinaison unique de conditions et actions.

• Structure d'une table de décision :

• Conditions en haut, actions en bas.

• Chaque colonne représente une règle associant conditions à des actions.

• Notation pour conditions et actions :

• Booléennes (Vrai/Faux), discrètes, nombres.

• Regroupement des conditions et actions :

• Peuvent être regroupées selon la pertinence.

• Objectif du test :

• Tester si le système réagit correctement selon les combinaisons de conditions.

4.2.4 Test des transitions d'état

Aspects liés au test de transitions d'état :
• Concept d'état :

• Composants passent par différents états en réaction à des événements ou conditions.

• Diagramme de transitions d'état :

• Montre les états possibles et les transitions.

• Transition d'état :
 • Passage d'un état à un autre en réponse à un événement.

• Utilisation du test de transitions d'état :

• Test des applications basées sur des menus ou logiciels embarqués.

• Objectifs des tests :

• Couvrir plusieurs états, exercer tous les états, transitions et séquences spécifiques.

• Mesure de la couverture :

• Mesurée en fonction du nombre d'états ou de transitions testés par rapport au total.

4.2.5 Test des cas d'utilisation

Relation entre les cas d'utilisation et les tests :
• Définition des cas d'utilisation :

• Comportement du système du point de vue de l'utilisateur ou autre système.

• Spécifient les interactions entre acteurs et système.

• Associations :

• Chaque cas d'utilisation associé à acteurs et sujet.

• Comportement et interactions :

• Spécifie le comportement du sujet avec des interactions, activités, préconditions, post-

conditions.

• Variations de comportement :

• Peut inclure des variations, comportements exceptionnels et gestion des erreurs.

• Représentation graphique :

• Peut être représenté graphiquement avec des flux de travail, diagrammes d'activités.

• Tests dérivés des cas d'utilisation :

• Tests conçus pour exercer les comportements spécifiés, y compris comportements de

base, exceptionnels, alternatifs et traitement des erreurs.

• Mesure de la couverture :

• Mesurée en pourcentage des comportements testés par rapport au total.

4.3 Techniques de test boîte-blanche
4.3.1 Test et couverture des instructions
• Test des instructions : Exercer chaque instruction exécutable.

• Couverture des instructions : Mesurer le pourcentage d'instructions exécutées par les tests.

4.3.2 Test et couverture des décisions

 • Test des décisions : Exercer les décisions et tester le flux d'exécution.

• Couverture des décisions : Mesurer le pourcentage de résultats de décision testés.

4.3.3 Apport des tests des instructions et décisions

• Couverture à 100 % des instructions : Toutes les instructions exécutables testées.

• Couverture à 100 % des décisions : Tous les résultats possibles des décisions testés.
4.4 Techniques de test basées sur l'expérience
4.4.1 Estimation d’erreur
• Anticiper les erreurs basées sur l'expérience.

• Créer une liste d'erreurs possibles et concevoir des tests pour les exposer.

4.4.2 Tests exploratoires

• Conception, exécution et évaluation dynamiques des tests.

• Tests informels adaptés en fonction des résultats obtenus pendant l'exécution.

4.4.3 Tests basés sur des checklists

• Conception et exécution de tests basés sur des listes de contrôle prédéfinies.

• Checklists créées sur la base de l'expérience ou de la connaissance des défauts courants.

Chapitre 5 : Gestion des tests

5.1 Organisation des tests
5.1.1 Indépendance des tests
Avantages de l'indépendance des tests:
• Détection efficace des défauts en minimisant les biais cognitifs.
• Détection de différents types de défauts par rapport aux développeurs.
• Vérification et remise en question des hypothèses de spécification et d'implémentation.
Niveaux d'indépendance des tests (du faible au élevé):
• Pas d'indépendance (développeurs testent leur propre code).
• Indépendance au sein de l'équipe de développement.
• Équipe de test indépendante dans l'organisation.
• Testeurs indépendants appartenant à l'organisation ou spécialisés.
• Testeurs indépendants externes à l'organisation.
Inconvénients de l'indépendance des tests:
 • Risque d'isolement des testeurs de l'équipe de développement.
• Possibilité de perte de responsabilité des développeurs envers la qualité.
• Risque de considérer les testeurs indépendants comme des ralentissements ou
responsables des retards.
• Possibilité de manque d'informations importantes pour les testeurs indépendants (ex :
objet de test).
5.1.2 Tâches d’un Test Manager et d’un testeur
Résumé des tâches d'un Test Manager:
• Responsabilité globale du processus de test.
• Développer ou revoir la politique et la stratégie de test.
• Planifier les activités de test en tenant compte des objectifs, des risques et des approches
de test.
• Coordonner les plans de test avec les parties prenantes et les équipes de projet.
• Suivre et contrôler l'avancement des tests, adapter la planification en conséquence.
• Préparer et fournir des rapports d'avancement.
• Mettre en place un système de gestion des défauts et une gestion de la configuration du
testware.
• Introduire des métriques pour mesurer l'avancement et évaluer la qualité.
• Promouvoir et soutenir les testeurs.
• Développer les compétences et les carrières des testeurs.
Résumé des tâches d'un testeur:
• Revoir et contribuer aux plans de test.
• Analyser, revoir et évaluer les exigences, User Stories et spécifications.
• Identifier et documenter les conditions de test.
• Concevoir, configurer et vérifier l'environnement de test.
• Concevoir et implémenter des cas de test.
• Préparer et acquérir des données de test.
• Planifier et exécuter les tests.
• Évaluer les résultats et documenter les écarts.
• Utiliser des outils pour faciliter et automatiser les tests.
• Évaluer les caractéristiques non-fonctionnelles.
 • Revoir des tests développés par d'autres.
5.2 Planification et estimation des tests
5.2.1 Objet et contenu d'un plan de test
Résumé du contenu et de l'objet d'un plan de test:
• Description des activités de test pour les projets de développement et de maintenance.
• Influencé par la politique, la stratégie de test, les cycles de vie, les méthodes, etc.
• Planification continue ajustée tout au long du cycle de vie du produit.
• Documentation dans un plan de test maître et plans distincts pour différents niveaux ou
types de tests.
• Activités de planification incluent détermination du périmètre, objectifs, risques,
approche générale, intégration, coordination, métriques, budget, et structure de
documentation.
5.2.2 Stratégie de test et approche de test
Stratégie de test:
• Analytique, basée sur l'analyse (ex: test basé sur les risques).
• Basée sur des modèles (conception de tests à partir d'un modèle).
• Méthodique, utilisant un ensemble prédéfini de tests.
• Conforme à un processus ou une norme externe.
• Dirigée ou consultative, basée sur des recommandations externes.
• Anti-régressions, pour éviter la régression des fonctionnalités existantes.
• Réactive, s'adaptant aux événements avec des tests exploratoires.
Approche de test:
• Ajuste la stratégie en fonction du contexte, des objectifs, du produit, des risques, de la
sécurité, des ressources, de la technologie.
• Varie en fonction du contexte, des objectifs et des réglementations.
5.2.3 Critères d'entrée et de sortie (Définition du prêt et définition du terminé)
Critères d'entrée:
• Disponibilité des exigences testables, User Stories, ou modèles.
• Existence d'éléments de test ayant satisfait aux critères de sortie des 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 requises.
Critères de sortie:
• Exécution des tests planifiés.
• Atteinte d'un niveau défini de couverture (exigences, User Stories, critères d'acceptation,
risques, code).
• Limite du nombre de défauts non résolus conformément aux définitions.
• Atteinte des niveaux évalués de fiabilité, performance, utilisabilité, sécurité, et autres
caractéristiques qualité pertinentes.
5.2.4 Calendrier d'exécution des tests
Résumé des considérations pour l'organisation et l'exécution des tests:
• Suites de test organisées selon un calendrier prenant en compte priorités, dépendances,
tests de confirmation, tests de régression, et efficacité d'exécution.
• Idéalement, exécution basée sur la priorité, en commençant par les cas de test à priorité
élevée.
• Dépendances entre les cas de test prises en compte.
• Priorisation des tests de confirmation et de régression basée sur l'importance de
remontées d'information rapides sur les changements.
5.2.5 Facteurs influençant l'effort de test
Facteurs liés au produit:
• Risques associés au produit.
• Qualité des bases de test.
• Taille et complexité du produit.
• Exigences de qualité.
• Niveau de détail de la documentation des tests.
• Conformité juridique et réglementaire.
Facteurs liés au processus de développement:
• Stabilité et maturité de l'organisation.
• Modèle de développement utilisé.
• Approche de test.
• Outils et processus de test.
• Pression des délais.
Facteurs liés aux personnes:
 • Compétences et expérience des personnes impliquées.
• Cohésion et leadership de l'équipe.
Résultats des tests:
• Nombre et gravité des défauts trouvés.
• Quantité de travail de correction nécessaire.
5.2.6 Techniques d'estimation des tests
• Technique basée sur les métriques:
• Estimation basée sur les métriques d'anciens projets similaires ou sur des valeurs
représentatives.
• Exemple: Burndown charts dans le développement Agile.
• Technique basée sur l'expertise:
• Estimation de l'effort basée sur l'expérience des responsables des tâches de test ou
d'experts.
• Exemple: Planning poker dans le développement Agile.
• Dans les projets séquentiels:
• Modèles de correction des défauts.
• Wideband Delphi.
5.3 Pilotage et contrôle des tests
Pilotage des tests:
• Objectif: Collecte d'informations et fourniture de retour et de visibilité sur les activités de
test.
• Méthodes: Collecte manuelle ou automatique des données pour évaluer l'avancement des
tests et mesurer la satisfaction des critères de sortie.
Contrôle des tests:
• Objectif: Mettre en œuvre des mesures correctives basées sur les données et les métriques
collectées.
• Actions possibles: Re-priorisation des tests, modification du calendrier des tests,
réévaluation de la conformité des éléments de test.
5.3.1 Métriques utilisées pour les tests
Métriques d'avancement:
• Objectif: Évaluer le progrès par rapport au calendrier et au budget prévus.
• Exemples: Pourcentage du temps de travail prévu réalisé, degré d'achèvement des tâches,
affectation et utilisation des ressources.
Métriques de qualité:
• Objectif: Évaluer la qualité actuelle de l'objet de test.
• Exemples: Densité des défauts, résultats des tests de confirmation.
Métriques d'efficacité:
• Objectif: Évaluer l'efficacité des activités de test par rapport aux objectifs.
• Exemples: Nombre de cas de test exécutés/non exécutés, coût des tests.
Métriques de pertinence de l'approche de test:
• Objectif: Évaluer la pertinence de l'approche de test choisie.
• Exemples: Couverture des exigences, des User Stories, des critères d'acceptation, des
risques ou du code par les tests.
5.3.2 Buts, contenu et destinataires des rapports de test
Rapport d'avancement de test (pendant l'activité de test):
• Statut des activités de test.
• Facteurs entravant l'avancement.
• Tests prévus pour la prochaine période.
• Évaluation de la qualité de l'objet de test.
Rapport de synthèse de test (à la fin de l'activité de test):
• Récapitulatif des tests réalisés.
• Écarts par rapport au plan.
• Statut des tests et qualité du produit.
• Facteurs bloquant l'avancement.
• Métriques liées aux défauts, cas de test, couverture de test, risques résiduels.
5.4 Gestion de configuration
• Identification et Versionnement.
• Suivi des Changements et Traçabilité.
• Liaison du Testware.
• Documentation Précise.
• Procédures et Infrastructure.
5.5 Risques et tests
5.5.1 Définition du risque
5.5.2 Risques produit et risques projet
Risques Produit:
• Non-conformité du produit aux besoins et attentes des utilisateurs.
• Exemples: Non-respect des spécifications, performances inadéquates.
Risques Projet:
• Risques affectant la capacité du projet à atteindre ses objectifs.
• Exemples: Retards, estimation incorrecte des ressources.
5.5.3 Test basé sur les risques et qualité du produit
• Orientation des Tests : Les risques guident où et quand commencer les tests. Les
zones à haut risque nécessitent une attention précoce et intensive dans les tests.
• Identification des Risques : Les tests aident à identifier les risques en fournissant une
remontée d'informations sur les anomalies, les problèmes, et les défauts potentiels.
• Réduction des Risques : Les tests sont des activités d'atténuation des risques. Ils
visent à réduire la probabilité qu'un événement indésirable se produise ou à en réduire
l'impact.
• Analyse des Risques Produit : Une approche de test basée sur les risques inclut
l'analyse des risques produit, évaluant la probabilité et l'impact de chaque risque sur le
produit.
• Planification des Tests : Les résultats de l'analyse des risques aident à déterminer les
techniques, les niveaux, et les types spécifiques de tests à effectuer. Ils influent sur la
priorisation et le volume des tests.
• Gestion des Risques : Les activités de gestion des risques fournissent une approche
méthodique pour analyser, déterminer l'importance, atténuer et planifier des mesures de
contingence pour les risques.

• Gestion des défauts

• Enregistrement des Défauts : Les défauts identifiés pendant les tests doivent être
enregistrés et suivis, du signalement à la résolution. Cela nécessite un processus de
gestion des défauts approuvé par toutes les parties impliquées.
• Faux Positifs : Il est essentiel de minimiser les faux positifs, des situations où un test
échoue mais ce n'est pas dû à un défaut réel. Les testeurs doivent exercer leur jugement
pour éviter ces faux signalements.
• Origine des Défauts : Les défauts peuvent être identifiés à divers stades, y compris le
codage, les revues, les tests dynamiques ou l'utilisation du produit. Ils peuvent concerner
le code, les systèmes en utilisation, ou divers documents.
• Objectifs des Rapports de Défauts : Les rapports de défauts ont pour but de fournir des
informations aux développeurs pour résoudre les problèmes, aux Test Managers pour
évaluer la qualité du produit, et d'apporter des améliorations au processus de test.
 • Contenu d'un Rapport de Défaut : Un rapport de défaut typique comprend un
identifiant, un titre, la date, l'identification de l'élément testé, une description du défaut,
les résultats attendus et obtenus, la sévérité, la priorité de correction, l'état du rapport, des
recommandations, et d'autres détails pertinents.
• Outils de Gestion des Défauts : Les outils de gestion des défauts automatisent et
facilitent le suivi des défauts, attribuent des identifiants, mettent à jour l'état du rapport, et
permettent un suivi efficace jusqu'à la résolution.

Chapitre 6 : Outils de support aux tests

6.1 Introduction aux outils de test
6.1.1 Classification des outils de test
• Outils de Gestion des Tests et du Testware:
• Gestion des tests et du cycle de vie des applications.

• Gestion des exigences.

• Gestion des défauts.

• Gestion de la configuration.

• Intégration continue (D).

• Outils pour les Tests Statiques:

• Support aux revues.

• Analyse statique (D).

• Outils pour la Conception et l'Implémentation des Tests:

• Conception de tests.

• Model-Based Testing.

• Préparation des données de test.

• Développement dirigé par les tests (ATDD, BDD).

• Développement dirigé par les tests (TDD) (D).

• Outils pour l'Exécution et les Logs de Tests:

• Exécution de tests.

• Couverture (exigences, code) (D).

• Harnais de test (D).

• Framework de tests unitaires (D).

 • Outils pour la Mesure de la Performance et l'Analyse Dynamique:
• Test de performance.

• Monitoring.

• Analyse dynamique (D).

• Outils pour des Besoins de Test Spécifiques:

• Évaluation de la qualité des données.

• Conversion et migration des données.

• Tests d'utilisabilité.

• Tests d'accessibilité.

• Tests de localisation.

• Tests de sécurité.

• Tests de portabilité.

6.1.2 Bénéfices et risques de l'automatisation des tests

Bénéfices potentiels:
• Réduction du travail manuel répétitif.

• Cohérence et répétabilité accrues.

• Évaluation plus objective.

• Automatisation d'activités impossibles manuellement.

• Fiabilité accrue des tests.

Risques potentiels:
• Attentes irréalistes.

• Coûts sous-estimés (introduction et maintenance).

• Sur-reliance sur l'outil.

• Contrôle des versions négligé.

• Interopérabilité et support fournisseur.

6.1.3 Considérations particulières pour les outils d'exécution des tests et de gestion des tests
Considérations Particulières:
• Outils d'Exécution des Tests:

• Techniques de script (capturé, piloté par les données, par mots-clés, MBT).
 • Comparaison des résultats attendus et effectifs.

• Outils de Gestion des Tests:

• Interface avec d'autres outils et feuilles de calcul.

• Traçabilité des exigences.

• Intégration avec des modules de gestion de cycle de vie logiciel.

6.2 Utilisation efficace des outils
6.2.1 Principes de base pour la sélection des outils
Principaux Facteurs à Prendre en Compte:
• Maturité de l'Organisation.

• Opportunités d'Amélioration du Processus de Test.

• Compatibilité Technologique.

• Compatibilité avec les Outils Existant.

• Évaluation Objective de l'Outil.

• Période d'Essai Gratuite.

• Évaluation du Fournisseur.

• Besoins en Formation et Soutien.

• Modèle de Licence.

• Analyse Coût-Bénéfice.

Étapes de la Dernière Sélection avec Preuve de Concept (POC):

• Phase de Preuve de Concept (POC):
• Effectuer une preuve de concept.

• Identifier les changements nécessaires à l'infrastructure.

6.2.2 Projets pilotes pour l'introduction d'un outil dans une organisation
Objectifs du Projet Pilote:
• Comprendre l'outil en profondeur.

• Évaluer son intégration aux processus existants.

• Établir des méthodes d'utilisation et de gestion standard.

• Évaluer les avantages par rapport aux coûts.

• Configurer les métriques et rapports nécessaires.

Étapes de Mise en Œuvre du Projet Pilote:

 • Sélection de l'Équipe Pilote.

• Formation et Familiarisation.

• Définition des Objectifs Clés.

• Configuration de l'Environnement.

• Conception et Exécution des Tests Pilotes.

• Évaluation des Résultats.

• Collecte de Retours d'Expérience.

• Révision et Ajustements.

6.2.3 Facteurs de succès pour les outils

• Déploiement Incrémental.

• Adaptation des Processus.

• Formation et Encadrement.

• Définition de Recommandations d'Usage.

• Collecte d'Informations sur l'Utilisation.

• Suivi des Bénéfices.

• Accompagnement des Utilisateurs.

• Leçons Tirées.