Résumé du Chapitre 1 : Tests des Logiciels
ISTQB
Objectifs du cours
Le cours vise à fournir les connaissances nécessaires pour effectuer des tests
logiciels et réussir la certification de base ISTQB.
Public cible
Le cours est destiné aux développeurs, testeurs, analystes de test, responsables
de test, ainsi qu’aux individus et organisations nécessitant une compréhension
des concepts de base des tests logiciels.
Introduction à l’ISTQB
L’ISTQB (International Software Testing Qualifications Board) est une associa-
tion internationale fondée en 2002, proposant des certifications reconnues mon-
dialement pour valider les compétences des testeurs de logiciels. Les niveaux
de certification incluent le niveau Fondation, les niveaux Avancés (Analyste de
Test, Analyste Technique de Test, Test Manager) et le niveau Expert (Manage-
ment des tests, Amélioration du processus de test).
Avantages de la certification ISTQB
Pour les professionnels, la certification offre une reconnaissance internationale
des compétences acquises et l’autorisation d’utiliser le logo ”Certified Tester”.
Pour les entreprises, avoir un personnel certifié assure un haut niveau de fiabilité
des applications développées et permet d’offrir un service de meilleure qualité
aux clients.
Fondamentaux des tests
1. Que sont les tests? : Les tests permettent de vérifier le comportement
d’un programme selon des critères prédéfinis et de détecter des anomalies.
1
2. Pourquoi tester? : Les tests réduisent les risques d’anomalies, aug-
mentent la confiance dans la qualité du logiciel et permettent de détecter
des défauts.
3. 7 principes des tests :
(a) Les tests montrent la présence de défauts, pas leur absence.
(b) Les tests exhaustifs sont impossibles.
(c) Tester tôt économise du temps et de l’argent.
(d) Les défauts sont souvent regroupés.
(e) Paradoxe du pesticide (nécessité de varier les tests).
(f) Les tests dépendent du contexte.
(g) L’absence d’erreurs est une illusion.
4. Processus de test : Inclut la planification, le suivi, l’analyse et la con-
ception, l’implémentation et l’exécution, ainsi que la clôture des tests. La
traçabilité est cruciale pour un pilotage efficace.
5. Psychologie des tests : Les compétences interpersonnelles sont essen-
tielles pour communiquer efficacement les défauts et établir des relations
positives avec les collègues.
Résumé du Chapitre 2 : Tester pendant le cycle
de vie du développement logiciel
Modèles de développement logiciels
Les tests logiciels doivent être adaptés aux modèles de cycle de vie du développement
logiciel choisis, qu’ils soient séquentiels (en cascade), en V, ou itératifs. L’objectif
est d’intégrer les activités de test dès les premières étapes du cycle de vie en
respectant le principe de ”Tester tôt”.
Niveaux de tests
1. Test de composants (tests unitaires) : Test de chaque partie du
logiciel de manière isolée pour vérifier son bon fonctionnement.
2. Test d’intégration : Vérification de l’interaction entre les composants ou
systèmes pour assurer leur compatibilité et bon fonctionnement ensemble.
3. Test système : Test du système dans son ensemble pour vérifier la con-
formité aux exigences spécifiées.
4. Test d’acceptation (UAT) : Tests formalisés par le client pour valider
le produit avant sa mise en œuvre opérationnelle.
2
Types de tests
1. Tests fonctionnels : Vérification des fonctions d’une application logi-
cielle selon les spécifications des exigences, principalement via des tests de
boı̂te noire.
2. Tests non-fonctionnels : Vérification des caractéristiques non directe-
ment liées à l’utilisation du code, telles que la performance et la sécurité.
3. Tests boı̂te blanche : Stratégie basée sur la structure interne du pro-
gramme pour vérifier les conditions d’arrêt de boucle, les branches d’instructions
conditionnelles et la validité des structures de données internes.
4. Tests liés aux changements : Tests de confirmation pour vérifier la
correction des défauts et tests de régression pour s’assurer qu’il n’y a pas
d’effets secondaires imprévus lors des modifications.
Tests de maintenance
La maintenance logicielle implique des tests pour corriger des défauts, ajouter
ou modifier des fonctionnalités, et préserver ou améliorer les caractéristiques
de qualité non-fonctionnelles tout au long de la durée de vie du logiciel. Une
analyse d’impact est nécessaire pour évaluer les conséquences des changements
apportés et identifier les zones du système affectées.
Résumé du Chapitre 3 : Tests statiques
Bases des tests statiques
Les tests statiques sont effectués sur le code source non exécuté et sur la doc-
umentation. Ils permettent de détecter des défauts avant que le code ne soit
exécuté, contrairement aux tests dynamiques qui sont réalisés sur un logiciel
en cours d’exécution. Les tests statiques peuvent être appliqués à divers pro-
duits d’activités, y compris les spécifications, le testware, les User Stories, les
conceptions d’architecture, le code, les guides utilisateur, etc.
Bénéfices des tests statiques
Les tests statiques offrent plusieurs avantages, notamment :
• La détection précoce des défauts, ce qui permet de réduire les coûts de
correction.
• L’amélioration de la productivité du développement grâce à une meilleure
conception et un code plus maintenable.
3
• La réduction des coûts et des délais de développement et de test.
• L’amélioration de la communication entre les membres de l’équipe.
Différences entre les tests statiques et dynamiques
Les tests statiques détectent directement les défauts dans les produits d’activités,
tandis que les tests dynamiques identifient les défaillances causées par des défauts
lors de l’exécution du logiciel. Les tests statiques et dynamiques se complètent
mutuellement et permettent de trouver différents types de défauts.
Processus de revue
Le processus de revue comprend les activités suivantes :
1. Planification : Définir le périmètre, les objectifs, les produits à examiner,
et les critères de sortie.
2. Lancement de la revue : S’assurer que tous les participants sont prêts
et comprennent leur rôle.
3. Revue individuelle : Les participants examinent individuellement le
produit d’activités et notent les défauts potentiels.
4. Communication et analyse des problèmes : Communiquer et anal-
yser les défauts identifiés.
5. Correction et production de rapports : Créer des rapports de défauts
et documenter les résultats de la revue.
Rôles et responsabilités dans une revue formelle
• Auteur : Crée et corrige les produits d’activités.
• Manager : Décide de ce qui doit être revu et fournit les ressources
nécessaires.
• Responsable de la revue : Prend la responsabilité générale de la revue
et organise sa tenue.
• Facilitateur : Assure le bon déroulement des réunions de revue.
• Scribe : Documente les anomalies et les décisions prises.
• Réviseurs : Effectuent les revues et peuvent être des experts en la matière
ou des parties prenantes.
4
Types de revue
• Revue informelle : Ne suit pas un processus défini, objectif principal
de détection des anomalies.
• Relecture technique : Évaluation de la qualité, renforcement de la
confiance, détection des anomalies.
• Revue technique : Réalisée par des réviseurs techniquement qualifiés,
objectif de consensus et de décision technique.
• Inspection : Type de revue le plus formel, objectif principal de détection
des anomalies, collecte de métriques pour améliorer le cycle de vie de
développement.
Facteurs de réussite des revues
• Objectifs clairs et définis.
• Choix du type de revue adapté.
• Utilisation de checklists couvrant les principaux risques.
• Participants ayant les compétences appropriées et suffisamment de temps
pour préparer.
• Gestion efficace des réunions de revue.
• Encouragement d’une culture de l’apprentissage et de l’amélioration des
processus.
Résumé du Chapitre 4 : Analyse et conception
des tests
Aperçu des techniques de test
Les techniques de test aident le testeur à analyser ce qu’il faut tester et à con-
cevoir les tests. Elles permettent de développer systématiquement un ensemble
restreint mais suffisant de cas de test. Les techniques sont classées en trois
catégories :
1. Techniques boı̂te-noire : Concentrez-vous sur les entrées et sorties de
l’objet de test sans référence à sa structure interne.
2. Techniques boı̂te-blanche : Concentrez-vous sur la structure et le
traitement interne de l’objet de test.
5
3. Techniques basées sur l’expérience : Tirent parti de l’expérience des
développeurs, des testeurs et des utilisateurs pour concevoir, implémenter
et exécuter des tests.
Techniques de test boı̂te noire
1. Partitions d’équivalence : Divisent les données en partitions traitées
de la même manière par l’objet de test. Un test pour chaque partition
suffit pour détecter les défauts.
2. Analyse des valeurs limites : Se concentre sur les valeurs limites des
partitions d’équivalence. Utilise des techniques à 2 ou 3 valeurs pour
exercer les limites.
3. Test par tables de décision : Teste les interactions entre des com-
binaisons de conditions, en réduisant intelligemment les combinaisons à
celles produisant des sorties différentes.
4. Test de transition d’état : Montre les états possibles du logiciel et
comment il entre, sort et évolue entre ces états. Teste la capacité du
système à entrer et sortir des états définis par des transitions valides et
invalides.
Techniques de test boı̂te blanche
1. Test des instructions et couverture des instructions : Conçoit des
tests pour exécuter des instructions. La couverture des instructions est
le pourcentage des instructions exécutables qui ont été exécutées par une
suite de tests.
2. Test des branches et couverture des branches : Conçoit des tests
pour exécuter les résultats de décisions (vrai et faux). La couverture des
décisions est le pourcentage des résultats de décisions exécutés par une
suite de tests.
Techniques de tests basés sur l’expérience
1. Estimation d’erreur : Anticipe les erreurs, défauts et défaillances basés
sur l’expérience du testeur.
2. Tests exploratoires : Se concentrent sur la découverte, l’exploration et
l’investigation du produit. Utilisent des sessions de test pour structurer
l’activité.
3. Tests basés sur des checklists : Conçoivent, implémentent et exécutent
des tests pour couvrir les conditions de test figurant dans une checklist.
6
Approches de test basées sur la collaboration
1. Rédaction collaborative de User Stories : Utilise des techniques
comme le brainstorming pour rédiger des User Stories qui représentent
une caractéristique utile à l’utilisateur ou à l’acheteur.
2. Critères d’acceptation : Conditions que doit remplir une User Story
pour être acceptée par les parties prenantes. Utilisés pour définir le
périmètre, obtenir un consensus, décrire les scénarios positifs et négatifs,
et servir de base aux tests d’acceptation des utilisateurs.
3. Développement piloté par les tests d’acceptation (ATDD) : Les
cas de test sont créés avant d’implémenter la User Story et sont basés sur
les critères d’acceptation.
Résumé du Chapitre 5 : Gestion des tests
Planification des tests
1. Objet et contenu d’un plan de test : Documente les moyens et le
calendrier pour atteindre les objectifs de test, sert de moyen de communi-
cation avec les membres de l’équipe et les parties prenantes, et démontre
la conformité à la politique et à la stratégie de test. Le contenu typique
inclut le contexte, les hypothèses, les parties prenantes, la communication,
le référentiel des risques, l’approche de test, le budget et le calendrier.
2. Contribution du testeur à la planification des itérations et des re-
leases : Les testeurs participent à la rédaction des User Stories, l’analyse
des risques, l’estimation de l’effort de test, la détermination de l’approche
de test et la planification des tests pour les releases et les itérations.
3. Critères d’entrée et critères de sortie : Les critères d’entrée définissent
les préconditions pour commencer une activité de test et les critères de
sortie définissent les conditions pour déclarer un niveau de test ou un
ensemble de tests terminés.
4. Techniques d’estimation : Prévoient la quantité de travail nécessaire
pour atteindre les objectifs de test. Techniques incluent l’estimation basée
sur des ratios, l’extrapolation, la méthode Delphi large bande et l’estimation
en trois points.
5. Priorisation des cas de test : Basée sur la couverture et les risques,
elle définit l’ordre d’exécution des tests.
6. Pyramide des tests : Modèle qui montre que différents tests peuvent
avoir un niveau de détail différent, avec des tests unitaires, des tests
d’intégration et des tests de bout en bout.
7
Gestion des risques
1. Définition et attributs du risque : Le risque est un événement poten-
tiel avec un impact négatif, caractérisé par sa probabilité et son impact.
2. Risques projet et risques produit : Risques projet (organisation-
nels, humains, techniques, fournisseurs) affectent le calendrier, le budget
ou le périmètre. Risques produit (fonctionnalités, calculs, architecture,
sécurité) entraı̂nent des conséquences négatives pour les utilisateurs et
l’entreprise.
3. Analyse des risques produits : Identification et évaluation des risques
pour concentrer l’effort de test et minimiser le risque résiduel.
4. Contrôle des risques produits : Mesures pour atténuer les risques
identifiés, telles que la sélection des testeurs, l’indépendance du test, les
revues, les analyses statiques et les techniques de test appropriées.
Pilotage des tests, contrôle des tests et clôture
des tests
1. Pilotage des tests : Collecte d’informations sur les tests pour évaluer
l’avancement et mesurer les critères de sortie.
2. Contrôle des tests : Utilise les informations de pilotage pour fournir
des directives et actions correctives.
3. Clôture des tests : Recueille des données pour consolider l’expérience
et le testware.
4. Métriques utilisées pour les tests : Incluent les métriques d’avancement,
de qualité du produit, de défauts, de risque, de couverture et de coût.
5. Rapports de tests : Résument et communiquent les informations pen-
dant et après les tests, comprenant des rapports d’avancement et de clôture.
Gestion de configuration
1. Gestion des éléments de configuration : Identifie, contrôle et suit
les produits d’activités tels que les plans de test, les scripts de test, les
résultats de test, etc.
2. Intégration continue et déploiement continu : Utilisent la gestion
de configuration automatisée dans un pipeline DevOps.
8
Gestion des défauts
1. Enregistrement et suivi des défauts : Les défauts trouvés pendant
les tests doivent être enregistrés et suivis jusqu’à leur résolution.
2. Faux positifs : Minimiser les rapports de faux positifs qui ne sont pas
des défaillances réelles.
3. Rapport de défauts : Inclut un identifiant, un titre, un résumé, la date,
l’auteur, l’identification de l’élément de test, l’environnement, les résultats
attendus et obtenus, la sévérité, la priorité, et le statut du défaut.