Chapitre (1) : Fondamentaux des tests

Les tests logiciels sont un moyen d'évaluer la qualité du logiciel et de réduire le risque de
défaillance de ce logiciel en cours de fonctionnement
● Mise en évidence des défauts d’un logiciel
● Donner un niveau de confiance
● Indication sur la qualité du logiciel
● Prouver qu’un logiciel est correcte
● Corriger les défauts
● Prouver la conformité fonctionnelle
● Prévenir des défauts
● Diagnostiquer les fautes

1) Tests et débogage
● L'exécution de tests peut mettre en évidence des défaillances causées par des
défauts dans le logiciel.
● Le débogage est l'activité de développement qui trouve, analyse et corrige de tels
défauts. Le débogage intervient après qu'une erreur a été détectée, que ce soit par
les tests ou par d'autres moyens.

2) Nécessité des tests :

● Contribution des tests au succès par réduction de développement de
fonctionnalités incorrectes ou non testables.
● Assurance de qualité et test : La gestion qualité comprend l’assurance qualité et le
contrôle qualité Le test est lié au contrôle qualité
► L’assurance qualité concerne les processus, vise à prévenir les défauts: il s’agit
d’une approche préventive
► Le contrôle qualité concerne le produit d’activité,vise à détecter les défauts: c’est
une approche curative
● Erreurs ,défauts et défaillances : Si un défaut dans le code est exécuté, cela peut
causer une défaillance .
● Défauts, causes racines et effets : Les causes racines des défauts sont les
premières actions ou conditions qui ont contribué à la création des défauts
► Les contraintes de temps
► L’inexpérience ou le manque de compétence des participants
► 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
► Des technologies nouvelles, peu connues

Les résultats inattendus ne sont pas tous des défaillances. Des faux positifs peuvent se
produire qui sont des situations où un test signale un défaut alors qu'en réalité, il n'y en a
pas. Les faux négatifs sont des situations où un test ne détecte pas un défaut réellement
présent dans le logiciel.
 3) 7 principes sur les tests :
● Les tests montrent la présence de défauts, pas leur absence : le test ne peut
jamais garantir l'absence totale de défauts dans un logiciel.
● Tester tôt économise du temps et de l’argent : Identifier et corriger les défauts tôt
dans le cycle de vie du développement logiciel
● Regroupement des défauts : une fois qu'un défaut est découvert dans une partie
du logiciel, il est judicieux de rechercher d'autres défauts similaires dans la même
zone.
● Paradoxe du pesticide : l'importance de la diversification des techniques de test
● Les tests dépendent du contexte : Les tests doivent être adaptés au contexte
spécifique du projet et aux exigences de l'application.
● L’absence d’erreurs est une illusion : ce principe met en garde contre l'idée
erronée que l'absence de défauts dans un logiciel signifie que le logiciel est sans
erreur.

4) Processus du test :

● Les facteurs qui influencent le processus de test dans le contexte :

→ Le modèle de cycle de vie du dev logiciel et les méthodologies de projet utilisées

→ Les niveaux de test et types de test prévus
→ Les risques liés aux produits et aux projets
→ Le domaine d'activité
→ Les contraintes opérationnelles, entre autres : Les budgets et ressources, les délais, la
complexité, les exigences contractuelles et réglementaires.
→ Les politiques et pratiques organisationnelles
→ Les normes internes et externes requises

● Activités et tâches de test :

➢ Planification des tests : Définir les objectifs du test et l'approche retenue pour
atteindre les objectifs du test.
➢ Pilotage et contrôle des tests : Le pilotage → 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 → prendre les mesures
nécessaires pour satisfaire aux objectifs du plan de test (qui peut être mis à jour au fil
du temps).
➢ Analyse de tests : Identifier les caractéristiques testables et les conditions de test
associées.
 ➢ Conception des tests : Développer les cas de test, prioriser, concevoir
l'environnement et établir la traçabilité.
➢ Implémentation des tests : Développer les procédures de test, créer des suites de
tests, préparer l'environnement et les données de test.
➢ Exécution des tests : Exécuter les tests selon le calendrier, enregistrer les résultats
et analyser les anomalies.
➢ Clôture des tests

5) La psychologie des tests :

La psychologie des tests implique d'adopter une approche collaborative et axée sur les
bénéfices pour favoriser la communication et la collaboration entre les testeurs et les
développeurs. Cela comprend :

● Collaboration plutôt que confrontation : Mettre l'accent sur des objectifs communs
pour une meilleure qualité des systèmes.
● Communication neutre et axée sur les faits : Transmettre les résultats des tests
de manière impartiale, sans blâmer les individus, et s'assurer d'une compréhension
mutuelle.
● Compréhension mutuelle des points de vue : Reconnaître les objectifs différents
des testeurs et des développeurs, mais travailler ensemble pour atteindre un niveau
de qualité élevé.
● États d'esprit des testeurs et des développeurs : Les testeurs devraient être
curieux, critiques et attentifs aux détails, tandis que les développeurs doivent être
concentrés sur la conception et la construction, tout en étant ouverts à l'identification
des défauts dans leur propre code.

En adoptant le bon état d'esprit et en favorisant une communication ouverte et constructive,

les équipes peuvent améliorer la qualité des produits logiciels.
 Chapitre (2) : Tester pendant le cycle de vie du
développement logiciel

Un modèle de cycle de vie de développement logiciel décrit les types d'activités réalisées
à chaque étape d'un projet de développement logiciel, et la façon dont les activités sont
reliées entre elles logiquement et chronologiquement.
► Pour chaque activité de développement, il y a une activité de test correspondante.
► Chaque niveau de test a des objectifs de test spécifiques à ce niveau.
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 différents modèles de cycle de développement nécessitent des approches de tests
différentes.

Les modèles de cycle de vie de développement de logiciels :

1. Le développement Séquentiel :
Le processus est un flux linéaire et séquentiel d'activités. Ces modèles fournissent des
logiciels qui contiennent l'ensemble des fonctionnalités, mais qui nécessitent généralement
des mois ou des années pour être livrés aux parties prenantes et aux utilisateurs.

2. Le développement incrémental :
Le développement incrémental implique la définition des exigences, la conception, le
développement et le test d'un système par morceaux, ce qui signifie que les fonctionnalités
du logiciel augmentent de façon incrémentale. La taille de ces incréments de fonctionnalités
varie.

3. Le développement itératif :
Le développement itératif se déroule lorsque des groupes de caractéristiques sont
spécifiés, conçus, développés et testés ensemble dans une série de cycles, souvent
d'une durée fixe. Les itérations peuvent impliquer des changements sur les caractéristiques
développées dans les itérations précédentes, ainsi que des changements sur le périmètre
du projet.
● Système basé sur des itérations. Un incrément est réalisé à la fin de chaque itération
● Chaque itération intègre toutes les activités: exigences, conception, construction et
tests unitaires, fonctionnels, d‟intégrations et d‟acceptation.
Le modèle en V :

→ A chaque activité de développement correspond une activité de test.

→ Vérification et Validation doivent avoir lieu
→ L'analyse et la conception des tests pour un niveau de test devraient commencer pendant
l'activité correspondante de développement.
→ Les testeurs doivent être impliqués dans la revue des documents aussi tôt que des
brouillons sont disponibles dans le cycle de développement.

Les niveaux de tests :

1. Les tests de composants / tests unitaires (implique developpeurs et testeurs) :
Ces derniers se font avec l'accès au code du logiciel testé sur un environnement de
développement et implique les développeurs.

2. Les test d'intégrations (implique developpeurs et testeurs) :

Ces tests impliquent les interfaces entre les composants, les interactions entre les parties
d’un système, une intégration incrémentale (composant après l'autre) ou Intégration en
une fois « Big Bang » ,tester la communication des modules pas leurs fonctionnalités.

3. Les tests systèmes (implique testeurs) :

Tester le comportement d’un système / produit complet , correspond à la cible finale /
l’environnement de production, l’équipe de test indépendante.

4. Les tests d’acceptation :

Valider que le produit atteint le niveau de confiance requis,
Responsabilité des clients / utilisateurs du système
Pas nécessairement le dernier niveau de test
De test d'acceptation utilisateur à alpha & beta tests sur le terrain.
Les formes communes de tests d'acceptation comprennent :
● Tests d'acceptation utilisateur :
Les tests d'acceptation du système visent à vérifier si le système répond aux besoins
des utilisateurs dans un environnement réel ou simulé, minimisant difficultés, coûts et
risques.
● Tests d'acceptation opérationnelle :
Vérifier que l'application est prête du point de vue opérationnel pour être mise en
production en s'assurant qu'elle peut être gérée et maintenue sans problèmes dans
un environnement de production simulé. Ils couvrent des aspects tels que la
 sauvegarde/restauration, l'installation/mise à jour, la reprise après sinistre, la gestion
des utilisateurs, la maintenance, le chargement des données, la sécurité, et la
performance. L'objectif est de garantir que le système est non seulement fonctionnel
mais aussi opérationnellement viable.
● Tests d'acceptation contractuelle et réglementaire :
Les tests d'acceptation contractuelle vérifient la conformité du logiciel aux
exigences d'un contrat, tandis que les tests d'acceptation réglementaire s'assurent
qu'il respecte les normes légales ou de sécurité les résultats étant parfois observés
ou vérifiés par des organismes de réglementation. Effectués souvent par des
testeurs indépendants ou les utilisateurs, leur but est de confirmer la conformité et
la fiabilité du logiciel avant son déploiement..
● Tests alpha et bêta :
Les tests alpha sont réalisés dans l'organisation développeuse avec des clients
potentiels ou une équipe de test indépendante, visant à identifier les bugs avant la
sortie publique. Les tests bêta sont effectués par des utilisateurs finaux dans leurs
propres environnements, permettant de détecter des problèmes spécifiques et
d'améliorer l'expérience utilisateur. Les deux phases aident à peaufiner le logiciel
avant son lancement officiel.

Approches de développement logiciel :

1. Rational Unified Process (RUP): adopte des itérations longues, généralement de 2

à 3 mois, livrant d'importants groupes de fonctionnalités connexes à chaque fois.

2. Scrum: préfère des itérations courtes, de quelques jours à quelques semaines, se

concentrant sur des incréments de fonctionnalités plus petits et plus fréquents.

⇒ Un modèle de cycle de vie du développement logiciel approprié devrait être choisi et

adapté en fonction de l'objectif du projet, du type de produit développé, des priorités métier
et des risques produit et projet identifiés.
Selon le contexte du projet, on peut combiner ou réorganiser les niveaux de test et/ou les
activités de test. Les modèles de cycle de vie du développement logiciel eux-mêmes
peuvent être combinés.

Les types de tests :

→ Un type de test est un groupe d'activités de test visant à tester des caractéristiques
spécifiques d'un système logiciel ou d'une partie d'un système
● Tests fonctionnels : le test d’une fonction devant être effectuée par le logiciel.
● Tests non fonctionnels : une caractéristique non fonctionnelle, telle que la fiabilité
ou l’utilisabilité ou la performance.
● Tests liés au changement: tests de confirmation ou tests de régression. Les tests
de confirmation vérifient qu'un bug précédemment identifié a été corrigé. Les tests
de régression s'assurent qu'aucun nouveau bug n'a été introduit dans des parties
du logiciel qui n'étaient pas supposées être affectées par les changements récents.
● Tests structurels/tests blancs : Ces tests vérifient la qualité du code, la logique de
programmation, et les flux de données au sein du logiciel. L'objectif est d'identifier les
problèmes dans la structure ou l’architecture du logiciel qui pourraient affecter sa
performance ou sa fiabilité.
⇒ Il est possible d'effectuer n'importe quel type de test mentionné ci-dessus à n'importe quel
niveau de test.

● Les tests de maintenance :

Ces tests interviennent après le déploiement d'un logiciel ou d'un système en
environnement de production. Ils sont essentiels pour gérer les changements qui
surviennent tout au long de la vie du logiciel. La maintenance est également
nécessaire pour préserver ou améliorer les caractéristiques de qualité
non-fonctionnelles du composant ou du système pendant toute sa durée de vie, en
particulier la performance, la compatibilité, la fiabilité, la sécurité et la portabilité.
Des tests de maintenance devraient être effectués pour évaluer le succès avec
lequel les modifications ont été apportées et vérifier les effets secondaires possibles.

● Tests d'interopérabilité : Testent la capacité du logiciel à interagir et fonctionner

correctement avec d'autres systèmes ou composants, garantissant la compatibilité et
la coopération entre différents logiciels.
● Tests de Maintenabilité : Évaluent la facilité avec laquelle un logiciel peut être
modifié pour corriger des défauts, répondre à de nouvelles exigences ou s'adapter à
des changements d'environnement.
● Tests de performances / rendement : Mesurent la capacité du logiciel à fournir des
performances adéquates sous des conditions spécifiées, par exemple en termes de
temps de réponse et de débit.
● Test de charge : Évalue le comportement du système sous une charge de travail
croissante, telle que l'augmentation du nombre d'utilisateurs ou de transactions
simultanées.
● Tests de robustesse : Analysent la fiabilité et la stabilité du logiciel en conditions
normales d'utilisation.
● Tests de stress : Examinent la capacité du logiciel à fonctionner sous des conditions
extrêmes, comme sous des charges de travail très élevées ou avec des ressources
systèmes limitées.
● Tests d'utilisabilité : Jugent la facilité d'utilisation du logiciel, y compris son
apprentissage, son efficacité, sa mémorabilité, et l'attrait pour les utilisateurs dans
des conditions spécifiques.
 Chapitre (3) : Tests statiques
Les tests statiques sont une méthode d'évaluation qui n'implique pas l'exécution du
logiciel. Ils consistent à examiner et à analyser divers types de documents et de code source
à différentes étapes du développement logiciel pour détecter les erreurs le plus tôt possible.

Liste des produits d'activités qui peuvent être examinés par des tests statiques :
► Les spécifications, y compris 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, y compris 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

Bénéfices des tests statiques:

● Détection et correction plus efficace des défauts, avant l'exécution des tests
dynamiques
● Identification des défauts qui ne sont pas facilement décelables par des tests
dynamiques
● Prévention des défauts de conception ou de codage par la découverte
d'incohérences, d'ambiguïtés,
● 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, grâce
à la réduction du nombre de défaillances plus tard dans le cycle de vie ou après la
mise en service

Différences entre les tests statiques et dynamiques :

Les tests statiques et dynamiques visent tous deux à vérifier la qualité et à détecter les
défauts le plus tôt possible, mais de manières complémentaires. Les tests statiques
examinent directement les documents et le code sans exécuter le logiciel, permettant de
repérer les erreurs dans les produits d'activités eux-mêmes. Ils aident à améliorer la
cohérence et la qualité interne. Les tests dynamiques, en revanche, impliquent
l'exécution du logiciel pour observer les comportements visibles à l’extérieur et identifier
les défaillances causées par des défauts.

Le processus de revue
Le processus de revue en développement de logiciels est une vérification statique où des
participants analysent des éléments comme le code ou les spécifications pour identifier des
défauts ou des écarts. Ce processus peut aller d'informel à formel et comprend
généralement les étapes suivantes :

Planification : Définir l'objectif, le périmètre qui comprend le but de la revue, les documents
ou parties de documents à revoir et les caractéristiques de qualité à évaluer , et sélectionner
les participants ainsi que les critères d’entrée et de sortie.
Lancement de la revue : Distribuer les documents à examiner et clarifier les objectifs et le
processus.
Revue individuelle : Les participants examinent le produit et notent les problèmes.
Communication et analyse des problèmes : Discuter des défauts identifiés, leur attribuer
un statut et décider des actions à prendre.
Correction et rapport : Corriger les défauts trouvés, communiquer les modifications, et
vérifier la satisfaction des critères de sortie.

Rôles et responsabilités dans une revue formelle :

Auteur : Celui qui a créé le produit d'activité à examiner. Il est aussi responsable de corriger
les défauts identifiés.

Manager : Responsable de la planification de la revue, de la décision de sa mise en œuvre,

de l'affectation des ressources et de l'évaluation de son rapport coût-efficacité. Il prend des
mesures correctives si nécessaire.

Facilitateur (ou Modérateur) : Clé pour le bon déroulement des réunions de revue, il gère
la communication et peut servir de médiateur entre les participants. Son rôle est crucial pour
le succès de la revue.

Responsable de la revue : Prend la responsabilité globale de la revue, décide des

participants, et organise le planning et le lieu.

Réviseurs : Experts ou parties prenantes sélectionnés pour identifier les défauts dans le
produit examiné. Ils apportent diverses perspectives basées sur leur expertise.

Scribe (ou Rapporteur) : Documente les défauts, les questions ouvertes, et les décisions
prises pendant la revue. Il joue un rôle essentiel dans le suivi des résultats de la revue.

Types de revues :
Revue Informelle
● Objectif : Identifier les défauts potentiels et générer des idées.
● Processus : Sans formalités documentées, sans réunion obligatoire.
● Participants : Effectuée par des collègues ou pairs.
● Documentation : Les résultats peuvent être notés, l'utilisation de checklists est
facultative.
Relecture Technique
● Objectifs : Trouver des défauts, envisager des alternatives, et évaluer la conformité
avec moins de formalité que les inspections..
● Processus : La préparation individuelle est optionnelle, et la réunion est souvent
dirigée par l'auteur.
● Rôles : La présence d'un scribe est requise, l'utilisation de checklists est optionnelle.
Revue Technique
● Objectifs : Obtenir un consensus, détecter des défauts, et évaluer la qualité.
● Processus : Nécessite une préparation individuelle, la réunion de revue est
facultative et idéalement menée par un facilitateur.
● Rôles : La participation de pairs et d'experts est nécessaire, avec documentation des
défauts.
Inspection
● Objectifs : Détecter et prévenir les défauts, évaluer la qualité, et favoriser
l'apprentissage avec la méthode la plus formelle.
● Processus : Suit un protocole défini très structuré avec des critères d'entrée et de
sortie, nécessite une préparation et implique des rôles définis.
● Rôles : Des rôles spécifiques sont clairement définis.Conduit par un facilitateur
formé, avec un scribe désigné, et l'auteur ne peut pas tenir certains rôles.

La différence principale réside dans le degré de formalité et de structure du processus de

revue, allant de l'informel sans documentation obligatoire (Revue Informelle) à un processus
très structuré avec des rôles définis et des critères d'entrée/sortie (Inspection).

Les techniques de revue (Utilisés au cours de l'activité de revue individuelle) :

● Ad-hoc : Approche non structurée où les réviseurs utilisent leur expérience et

intuition sans directives spécifiques.
● Basé sur des Checklists / Scénarios : Guidée par checklists ou scénarios qui
ciblent des erreurs communes ou des aspects critiques, pour une revue méthodique.
● Basé sur les rôles : Adopte la perspective de différents utilisateurs ou rôles (comme
administrateur système, utilisateur novice), pour identifier des problèmes spécifiques
à chaque rôle.
 ● Basé sur la Perspective : Considère différents points de vue des parties prenantes
(utilisateur final, marketing, testeur), enrichissant l'évaluation par une compréhension
variée des besoins et attentes.

Chaque technique offre un angle différent pour évaluer un produit, de l'approche libre à des
méthodes plus ciblées et structurées.

Analyse statique avec des outils: (Effectué sans exécuter le code par les
développeurs )

Outils d’Analyse statique :

● Compilateur ⬄ compiler : un outil logiciel qui traduit un programme exprimé dans
un langage de haut niveau dans son équivalent en langage machine
● Lint tools : Repérage de mauvaises pratiques
● Calcul de la Complexité Cyclomatique ⬄ Cyclomatic complexity : le nombre de
chemins indépendants au travers d'un programme.
● Inconvénients :
o Outils peuvent être chers
o Besoin de maîtrise et de configuration
o Résultat nécessite analyse
 Chapitre (4) : Techniques de Test

Le choix des techniques de test à utiliser dépend d'un certain nombre de facteurs, dont :
● le Type de composant ou de système,
● Complexité du composant ou des systèmes,
● Normes réglementaires,
● Exigences client ou contractuelles,
● Niveaux de risque, Types de risques,
● Objectifs du test, Documentation disponible,
● Connaissances et compétences des testeurs,
● Outils disponibles, Temps et budget
● Modèle de cycle de vie du développement logiciel, Utilisation prévue du logiciel

Les catégories des techniques de tests :

1. Test de Boîte-Noire
● Se concentre sur les fonctionnalités visibles du logiciel sans considération pour la
structure interne.
● Examine les entrées et sorties du système. Les tests sont conçus à partir des
spécifications et exigences du logiciel.
● Adapté tant pour les tests fonctionnels que non fonctionnels. Idéal pour vérifier si le
logiciel répond aux attentes des utilisateurs.
2. Test de Boîte-Blanche
● Basé sur une connaissance approfondie de la structure interne, du code source et de
l'architecture du logiciel.
● Les tests se concentrent sur le fonctionnement interne, le flux de données, et les
chemins d'exécution dans le code.
● Permet de détecter les problèmes internes spécifiques, comme les boucles infinies,
les problèmes de couverture de code, et les failles de sécurité.

3. Tests Basés sur l'Expérience

● Utilise l'expérience accumulée des développeurs, des testeurs, et des utilisateurs
pour guider la conception et l'exécution des tests.
● Il s'appuie sur l'intuition, les connaissances antérieures et les compétences pratiques
pour identifier les zones problématiques potentielles.
● Complémentaire aux techniques de boîte-noire et boîte-blanche, en ciblant les tests
là où l'expérience suggère la présence de défauts.

Techniques de Test de Boîte-Noire :

Partitions d'Équivalence : Divise les données d'entrée en classes où chaque classe est
traitée de manière identique. Cela inclut des partitions pour les entrées valides et invalides.
Analyse des Valeurs Limites : Se concentre sur les limites entre les partitions
d'équivalence, où les erreurs sont plus susceptibles de se produire.
Test de Tables de Décision : Utilise des tables pour représenter et tester toutes les
combinaisons possibles de conditions et leurs résultats attendus.
Test des transitions d'État : Examine les changements d'état dans le logiciel pour vérifier
les transitions valides et invalides.
Test des cas d'utilisation : Dérive les tests des scénarios d'utilisation du logiciel pour
s'assurer qu'il répond aux attentes des utilisateurs.

Techniques de Test de Boîte-Blanche :

Test et Couverture des Instructions : Vise à exécuter chaque ligne de code au moins une
fois pour identifier les erreurs.
Test et Couverture des Décisions : Teste les branches dans le code, assurant que chaque
décision a été prise dans toutes les directions possibles.

Techniques de Test Basées sur l'Expérience

Tests Exploratoires : Les tests sont conçus et exécutés de manière dynamique, s'appuyant
sur l'intuition et l'expérience du testeur.
Tests Basés sur des Checklists : Utilise des checklists pour guider le testeur sur les
aspects spécifiques à vérifier.

Processus de développement des tests :

Le processus peut être informel ou formel. Ceci dépend de la contrainte de temps et des
personnes concernées.

Traçabilité :
→ Quoi ? : C'est la relation entre les spécifications, les exigences, les conditions de test, les
cas de test et les incidents.
→ Pourquoi ? : La traçabilité donne une visibilité sur le progrès et la couverture des tests.
Elle est importante pour comprendre l'impact des changements d'exigences sur les tests
existants.
→ Comment ? : On établit la traçabilité en référençant les exigences et les spécifications.
Des tables de liaison sont créées pour relier les références des exigences aux conditions de
test correspondantes.

Cas de test :
● Composition d‟un cas de test
○ Ensemble de valeurs d'entrée
○ Pré-conditions d'exécution
○ Résultats attendus
○ Post-conditions d'exécution

● Résultats Attendus
○ Les sorties
○ Les modifications d'état
○ Les modifications de données
○ Autres conséquences et impacts du test
 Chapitre (5) : Gestion des Tests
1. Organisation des tests : Indépendance des tests
Concept d'indépendance : L'indépendance dans les tests fait référence à la séparation
entre la personne qui écrit le code et celle qui le teste. Cette séparation aide à minimiser les
biais cognitifs qui pourraient affecter la capacité du testeur à identifier les erreurs, car
l'auteur et le testeur ont des perspectives différentes.

Niveaux d'indépendance :
Aucun testeur indépendant : Les développeurs testent leur propre code. Ce niveau
présente le risque le plus élevé de biais.
Testeurs indépendants dans les équipes : Ici, les tests peuvent être réalisés par d'autres
développeurs au sein de la même équipe ou par des testeurs spécialisés. Cela offre une
certaine distance par rapport au code original.
Équipe de test indépendante : Une équipe séparée au sein de l'organisation qui se
concentre uniquement sur les tests. Ces testeurs rapportent généralement à la direction du
projet ou à la direction générale, offrant une perspective externe plus forte et moins de
conflits d'intérêts.
Des testeurs indépendants appartenant à l’organisation métier ou à la communauté
d’utilisateurs, ou spécialisés dans des types de tests spécifiques tels que l'utilisabilité, la
sécurité, la performance, la conformité réglementaire ou la portabilité.
Testeurs externes : Des spécialistes non affiliés à l'organisation, travaillant soit sur site
(insourcing) soit hors site (outsourcing).

Avantages de l'indépendance :
● Les testeurs indépendants apportent des perspectives différentes, ce qui peut
conduire à une meilleure identification des défauts.
● Ils peuvent également remettre en question les hypothèses prises pendant la
conception et l'implémentation du système.

Inconvénients de l'indépendance :
● Risque d'isolement des testeurs par rapport à l'équipe de développement, ce qui
peut entraver la collaboration et retarder les feedbacks.
● Perception possible des testeurs comme un goulot d'étranglement, surtout si les
délais de mise en marché sont impactés.
● Manque potentiel d'accès à des informations cruciales sur le produit à tester.
● Les développeurs peuvent perdre le sens des responsabilités vis-à-vis de la qualité.

Testeur VS Responsable des tests :

● Testeur
Le testeur est un professionnel technique impliqué dans les tests d'un composant ou
système. Ses principales responsabilités incluent :
Planification : Participer à la révision et contribuer au plan de test.
Analyse : Évaluer la testabilité des exigences et examiner les spécifications de test.
Conception : Créer des spécifications de test et potentiellement automatiser les tests.
Implémentation et exécution : Préparer les données et environnements de test, exécuter
les tests, évaluer les résultats et mesurer la performance des composants testés.
 ● Responsable des tests
Le responsable des tests (aussi appelé Gestionnaire de Test, Test Leader ou Test Manager)
est chargé de diriger et de superviser le processus de test. Ses tâches sont plus
stratégiques et comprennent :
Planifier : Établir la stratégie de test, planifier les tests, générer le plan de test, estimer le
budget et les ressources nécessaires, organiser la formation des testeurs, et coordonner la
mise en œuvre des environnements de test.
Surveiller : Piloter la mise en œuvre de la stratégie de test, établir les rapports de
progression, et introduire des indicateurs de mesure de l'avancement.
Contrôler : Adapter le planning en fonction de l'avancement du projet et superviser
l'exécution des tests.
Manager : Promouvoir et soutenir les activités et les métiers du test au sein de
l'organisation, développer les compétences des testeurs.
● Distinctions clés
Testeur : Plus impliqué dans les aspects techniques et opérationnels du test.
Responsable des tests : Focus sur la gestion, la planification, et la stratégie globale des
activités de test.

2. Planification et estimation des tests :

Objet et contenu d'un plan de test :
● Objectif : Un plan de test définit les activités de test pour des projets de
développement et de maintenance.
● Facteurs influents : La planification est guidée par divers éléments comme la
politique de test de l'organisation, les cycles de vie du développement, la méthode de
développement utilisée, l'étendue et les objectifs des tests, les risques, les
contraintes, la criticité, la testabilité des produits, et les ressources disponibles.
● Nature continue : La planification des tests est un processus continu qui s'étend sur
tout le cycle de vie du produit.
Activités de planification des tests :
● Détermination du périmètre et des objectifs : Fixer les limites, les buts, et
identifier les risques des tests.
● Définition de l'approche de test : Établir la méthode générale des tests.
● Coordination avec le cycle de vie du développement : Intégrer les activités de
test dans le cycle de vie global du logiciel.
● Planification détaillée : Organiser les étapes spécifiques des tests comme
l'analyse, la conception, l'implémentation, l'exécution, et l'évaluation.
● Sélection des métriques : Choisir des indicateurs pour suivre et contrôler les tests.
● Budgétisation : Estimer les coûts liés aux activités de test.
● Documentation : Déterminer le niveau de détail et la structure de la documentation
nécessaire.

Stratégie et approche de test

● Stratégie de test : Description générale du processus de test au niveau du produit
ou de l'organisation, pouvant inclure différentes méthodes comme analytique, basée
sur des modèles, méthodique, conforme aux normes, dirigée ou consultative,
anti-régression, et réactive.
Une stratégie de test pertinente est souvent créé en combinant plusieurs de ces types de
stratégies de test
 ● Approche de test : Adaptation de la stratégie de test à un projet ou une version
spécifique pour répondre aux besoins uniques de celui-ci.
Alors que la stratégie de test fournit une description générale du processus de test,
l'approche de test ajuste la stratégie de test pour un projet ou une version particulière.
Critères d'entrée et de sortie
Critères d'entrée : Conditions nécessaires pour commencer les tests, telles que la
disponibilité des exigences testables, de l'environnement de test, des outils, et des données
de test.
Critères de sortie : Conditions qui doivent être remplies pour considérer les tests comme
complets, incluant l'exécution de tous les tests planifiés et l'atteinte d'un certain niveau de
couverture.
Calendrier d'exécution des tests
Planification de l'ordre et de la séquence des tests en tenant compte des priorités, des
dépendances entre tests, et de la nécessité de tests de confirmation ou de régression.
Facteurs influençant l'effort de test
➢ Produit : Risques, qualité des bases de test, taille, complexité, exigences de qualité
spécifiques, et conformité réglementaire.
➢ Processus de développement : Stabilité et maturité de l'organisation, modèle de
développement, approche de test, outils utilisés, et pression des délais.
➢ Personnes : Compétences et expérience des personnes impliquées.
➢ Résultats des tests :Le nombre et la sévérité des défauts trouvés et La quantité
nécessaire de travail à refaire
Techniques d'estimation des tests
➢ Technique basée sur les métriques : Utilisation de données de projets précédents
pour estimer l'effort.
➢ Technique basée sur l'expertise : Estimation basée sur l'expérience et le jugement
des experts.
3. Pilotage et contrôle des tests :
Pilotage des tests
Le pilotage des tests consiste à surveiller les activités de test en continu pour recueillir des
données qui permettent d'évaluer l'avancement et l'efficacité des tests. Le but principal est
de fournir un retour et une visibilité sur l'état des tests, permettant ainsi une prise de décision
informée et proactive tout au long du cycle de développement.
Contrôle des tests
Le contrôle des tests fait référence aux actions prises en réponse aux informations
recueillies lors du pilotage. Ces actions peuvent inclure des ajustements ou des corrections
pour s'assurer que les tests restent sur la bonne voie par rapport aux objectifs prévus. Cela
peut impliquer la modification des approches de test, la réaffectation des ressources, ou
l'adaptation des échéances pour corriger tout écart par rapport au plan.
Métriques utilisées pour les tests
Les métriques de test sont des indicateurs quantitatifs collectés pendant et après les
activités de test pour mesurer différents aspects de la performance des tests, tels que :
➢ Avancement : Comparaison de l'avancement réel avec le calendrier et le budget
prévus.
➢ Qualité : Évaluation de la qualité actuelle de l'objet de test, en fonction des défauts
découverts et corrigés.
➢ Pertinence de l'approche : Évaluation de l'adéquation de l'approche de test utilisée
pour le projet en cours.
 ➢ Efficacité : Mesure de l'efficacité des activités de test pour atteindre les objectifs
fixés.
➢ Exemples spécifiques de métriques : couverture des exigences, des User Stories,
des critères d'acceptation, degré d'achèvement des tâches, coût des tests, etc.
Buts, contenu et destinataires des rapports de test
Les rapports de test sont des documents qui synthétisent et communiquent les informations
sur l'activité de test à différents stades du processus. Ils sont utilisés pour informer les
parties prenantes de l'état des tests et des éventuels problèmes rencontrés :
Rapport d'avancement de test : Préparé pendant l'activité de test, ce rapport donne des
mises à jour régulières sur l'avancement par rapport au plan.
Rapport de synthèse de test : Préparé à la fin de l'activité de test, ce rapport offre une vue
d'ensemble de l'ensemble du processus de test, évaluant si les objectifs ont été atteints et
soulignant les problèmes majeurs rencontrés.
4. Gestion de configuration
La gestion de configuration vise à maintenir l'intégrité des composants du système et du
testware (ensemble des artefacts de test), ainsi que de leurs relations tout au long du cycle
de vie du projet et du produit. Cela implique :
Identification unique et versionnage : Chaque élément de test et du testware doit être
clairement identifié, versionné, suivi pour les changements, et relié aux autres éléments
pertinents.
Traçabilité : Assurer une liaison claire entre tous les éléments du testware et les versions
des éléments de test pour maintenir la traçabilité à travers tout le processus de test.
Référencement clair : Tous les documents et logiciels doivent être référencés sans
ambiguïté dans la documentation de test.
Les procédures de gestion de la configuration et l'infrastructure nécessaire, y compris les
outils, doivent être identifiées et mises en place lors de la planification des tests.
5. Risques et tests
Le concept de risque dans le contexte des tests logiciels se réfère à la possibilité qu'un
événement futur ait des conséquences négatives, évaluées par la probabilité de l'événement
et son impact. Il y a deux types principaux de risques :
Risques produit : Concernant la possibilité qu'un produit logiciel ne réponde pas aux
besoins de ses utilisateurs ou parties prenantes. Ces risques sont souvent associés à des
attributs de qualité spécifiques tels que la fiabilité, la performance, l'utilisabilité, etc.
Risques projet : Relatifs à des situations qui peuvent compromettre la capacité du projet à
atteindre ses objectifs, comme des retards ou des dépassements de coûts.
6. Gestion des défauts
La gestion des défauts traite de la manière dont les défauts identifiés sont analysés, suivis et
résolus. Le processus inclut :
Suivi : Du moment de la découverte et classification du défaut jusqu'à sa résolution.
Workflow et règles de classification : Définition d'un processus clair pour la gestion des
défauts, incluant les étapes et classifications à suivre.
Contenu d'un rapport de défaut : Typiquement, un rapport de défaut contiendrait un
identifiant, un titre, un résumé du défaut, la date du rapport, l'organisation et l'auteur,
l'identification de l'élément de test, la phase du cycle de développement où le défaut a été
observé, une description détaillée du défaut, les résultats attendus et obtenus, la sévérité,
l'urgence, l'état actuel du défaut, des conclusions et recommandations, et toute référence
pertinente.
 Chapitre (6) : Outils de support aux tests

1. Les différents types d’outils

Outils de tests : Une application, un module ou un produit logiciel qui aide à la mise en
place d'une ou plusieurs activités de tests

2. Objectifs des outils

● Amélioration de l'efficacité
○ Automatisation de tâches répétitives, pour les tests de régression
○ Faciliter la conception, le contrôle et le reporting.
● Automatisation des tests non réalisables manuellement : Les tests de
performances et de stress
● Automatisation des tâches nécessitant des ressources importantes : Les tests
statiques / analyse du code (code mort, non initialisé….)
● Amélioration de la fiabilité : Simulation des comportements ,Automatisation d‟un
grand jeux de données

3. Bénéfices et risques potentiels de l’automatisation des tests

Bénéfices
● Réduction du travail répétitif
● Plus grande répétabilité et cohérence dans le processus
● Evaluation objective dans les mesure statiques, de couverture
● Facilité d'accès aux informations des tests et leur exécution pour le reporting
Risques
● Attentes irréalistes placées dans l'outil (facilité d'utilisation et la fonctionnalité).
● Sous-estimation du temps, du coût et de l'effort liés à l'outil et à l'accomplissement
des bénéfices
● Confiance excessive dans l‟outil
● Dépendance de l'outil: faillite ou faible réactivité du fournisseur
 ● Négligence des problèmes d'interopérabilité entre les outils ou avec le produit lui
même une fois modifié

4. Introduire un outil dans une organisation

Principes généraux
● Evaluation de la maturité de l‟organisation
● Évaluation au regard d'exigences claires et de critères objectifs.
● Une preuve de concept, pour vérifier le fonctionnement avec le logiciel,
l'infrastructure courante…
● Evaluation du fournisseur
● Identification des exigences internes pour le coaching et la tutelle dans l'utilisation de
l'outil
Projet pilote
● Connaître l'outil plus en profondeur.
● Voir comment l'outil s'adapte à des processus et pratiques existants, et comment ces
derniers devraient évoluer.
● Décider comment utiliser, gérer, et maintenir l'outil
● Évaluer les bénéfices à atteindre selon le coût
Facteurs de succès
● Déploiement incrémental
● Adapter et améliorer les processus
● Fournir la formation et l'assistance aux nouveaux utilisateurs.
● Établir des guides d'utilisation.
● Capitaliser fréquemment sur l'utilisation de l'outil.
● Suivi des gains et bénéfices d‟utilisation

5. Outils d’aide à la gestion du test et des tests

Outils de gestion des exigences : fournissent des interfaces pour
● enregistrer les énoncés des exigences,
● enregistrer les attributs des exigences (priorité y compris)
● fournir des identifiants uniques
● supporter la traçabilité des exigences vers les tests individuels.
● aider à identifier des exigences contradictoires ou manquantes.
Outils de gestion d'incidents : fournissent des interfaces pour
● enregistrer et gérer les rapports d'incidents, c.-à-d. les défauts, les défaillances,
● gérer les demandes de modification ou les problèmes et anomalies rencontrés.
● gérer le cycle de vie des incidents, éventuellement avec le support de l'analyse
statistique.
Outils de gestion de configuration :
● pas strictement des outils de test
● nécessaires pour le stockage et la gestion de version du testware et du logiciel
associé
● Important dans le cas de plusieurs environnements matériel/logiciel (versions du
système d'exploitation, compilateurs, navigateurs web, ... )

6. Spécificité des outils d’analyse statique

Outils de revue
● aider aux revues des processus, des check-lists, des directives de revue
 ● enregistrer et communiquer les commentaires des revues, et les rapports sur les
défauts et les essais.
● assister des revues en ligne pour des équipes de taille importante ou
géographiquement dispersées.
Outils d'analyse statique
● aider les développeurs et les testeurs à trouver des défauts avant le test dynamique
aider à introduire des normes de codage (codage sécurisé y compris),
● analyser les structures et les dépendances.
● aider dans la planification ou l'analyse de risque en via des métriques pour le code
(par exemple, complexité).

7. Outils d’exécution des tests

Outils d’exécution des tests
● Exécution automatique, ou semi-automatique des tests
● Enregistrement de tests effectués manuellement 􀀀 Utilisation des entrées
enregistrées et des résultats prévus pour fournir un registre à chaque exécution
● Utilisation d'un langage de script ou une configuration via une interface graphique
utilisateur
Harnais de tests/Outils framework de tests unitaires
● Fourniture d'objets factices comme des bouchons ou des pilotes pour simuler
l'environnement d‟exécution d‟un objet de test
Outil de capture/playback
● type d’outil d'exécution de tests où les entrées sont enregistrées pendant les tests
manuels, pour générer des scripts qui peuvent être rejoués après.
● souvent utilisés pour fournir un support automatisé aux tests de régression.
Outils de mesure de couverture
● mesurer le pourcentage de certains types de structures de code qui ont été exercés
(par exemple, des déclarations, des branches ou des décisions, et appels de module
ou fonction) par un ensemble de tests.
Comparateurs de tests
● Déterminer les différences entre les fichiers, bases de données ou résultats de tests.
● Peut être inclus dans les outils d'exécution des tests
● Les comparaisons post-exécution peuvent être faites par un outil de comparaison
distinct.
● utilise un oracle de tests, en particulier s'il est automatisé.
Oracle de test est une source utilisée pour déterminer les résultats attendus à comparer
avec les résultats obtenus de l'application en cours de test. Un oracle peut être le système
existant (comme point de référence), un manuel utilisateur, ou la connaissance spécialisée
d’un individu, mais ne devrait pas être le code [Adrion]

8. Outils d’aide à la spécification des tests

Outils de conception de tests fournissent des interfaces pour
● générer des entrées de tests ou des tests exécutables à partir ▪ des exigences, ▪ des
interfaces utilisateur graphiques, ▪ des modèles de conception (état, données ou
objet) ou à partir ▪ du code.
Outils de préparations de données de tests
● agissent sur des bases de données, fichiers ou transferts de données
● Pour élaborer des données de tests utilisables lors de l‟exécution des tests
Outils de modélisation
● valider les modèles de logiciel (par exemple, modèle de données physiques (MDP)
pour une base de données relationnelle),
● énumérer les incohérences et les défauts.
● aider à produire quelques cas de test basés sur le modèle

9. Spécificité des outils d’exécution des tests

Caractéristiques
● Utilisent des scripts de tests automatisés
● Maîtrise du langage de scripting exigée
● Effort important en cas de grand nombre de test
● Capture manuel des actions de la part d'un testeur
● risqué / instable
Approche guidée par les données
● Script générique alimenté par divers données de tests
○ plus grand nombre de tests avec un seul script
○ pas besoin de maîtrise du langage pour ajouter de nouveaux cas de test
Approche guidée par Mots clés
● Mots-clés ou macro pour décrire une action
○ Les tests sont une combinaison des mots clés
○ Pas besoin de maîtrise du langage pour ajouter de nouveaux cas de test

10. Outils de support de performance et de surveillance des tests

Outils d'analyse dynamique
● Détection de défauts qui ne se manifestent que lors de l‟exécution du logiciel, telles
que les dépendances temporelles ou les fuites de mémoire.
● Typiquement utilisés dans des tests de composants et d'intégration de composants
Outils de surveillance
● Analyse et vérification de l'utilisation de ressources systèmes spécifiques,
● Alertes sur de possibles problèmes de service