Parmi les six chapitres du syllabus CTFL v4.0, le domaine Tests statiques est sans doute le plus sous-préparé. Les candidats le jugent « évident » et y consacrent peu de temps. C’est une erreur : l’examen y pose des questions précises sur les types de revues, les rôles, et les facteurs de succès — des nuances qui ne s’improvisent pas.
Le chapitre 3 « Tests statiques » représente 15 % de l’examen CTFL v4.0, soit environ 10 questions sur 65. Score de passage : 65 %. Durée : 90 minutes. Source : syllabus officiel ISTQB CTFL v4.0.
Ce que couvre réellement le domaine Tests statiques
Le chapitre 3 du syllabus v4.0 est structuré en deux grandes sections :
- 3.1 — Les bases des tests statiques : quels produits de travail peuvent être testés statiquement, pourquoi, et en quoi ils diffèrent des tests dynamiques.
- 3.2 — Le processus de feedback et de revue : les activités de revue, les rôles, les quatre types de revues, et les facteurs de succès.
Contrairement à une idée reçue, les tests statiques ne concernent pas uniquement le code source. Le syllabus l’affirme clairement : tout produit de travail lisible peut être soumis à une revue — user stories, critères d’acceptation, plans de test, maquettes, contrats, et même les cas de test eux-mêmes.
Les 4 concepts clés que l’examen teste sur ce domaine
1. La valeur économique des tests statiques
L’ISTQB insiste sur un principe fondamental : détecter un défaut en phase d’exigences coûte de 10 à 100 fois moins cher que le corriger en production. Les tests statiques permettent cette détection précoce. L’examen peut vous demander d’argumenter cette valeur ou d’identifier dans quel contexte les tests statiques apportent le plus de bénéfices.
- Détection précoce des défauts, avant exécution du code
- Amélioration de la qualité des produits de travail intermédiaires
- Réduction des coûts globaux de test et de développement
- Meilleure compréhension partagée entre les parties prenantes
- Conformité aux normes et aux exigences légales
2. Différence entre tests statiques et tests dynamiques
Un test statique n’exécute pas le code — il analyse les artefacts. Un test dynamique exécute le logiciel et observe son comportement. Les deux sont complémentaires : les tests statiques trouvent des défauts que les tests dynamiques ne peuvent pas détecter (ambiguïtés dans les exigences, mauvaise conception), et vice versa.
3. Les quatre types de revues
C’est le cœur du domaine et la zone la plus testée. L’examen vous donnera un scénario et vous demandera d’identifier le type de revue le plus approprié.
| Type | Formalisme | Rôle auteur | Cas d’usage typique |
|---|---|---|---|
| Revue informelle | Aucun | Présent ou non | Vérification rapide entre collègues |
| Walkthrough | Faible | Présente et explique | Formation, partage de connaissances |
| Revue technique | Moyen | Présent | Détection de défauts techniques, décisions |
| Inspection | Élevé | Peut être absent | Audit qualité formel, certification |
Retenez l’axe formalisme croissant : informelle → walkthrough → technique → inspection. Si la question mentionne « formation » ou « partage », c’est le walkthrough. Si elle mentionne « audit » ou « conformité », c’est l’inspection.
4. Les facteurs de succès des revues
Le syllabus v4.0 liste des facteurs de succès que l’examen peut tester directement : objectifs clairs et mesurables, participants adaptés au type de revue, utilisation d’une liste de contrôle, résultats documentés, et — point souvent négligé — l’absence de jugement personnel sur l’auteur. Une revue qui vire à la critique personnelle est un anti-pattern explicitement mentionné dans le syllabus.
Les 3 erreurs fréquentes des candidats
Erreur 1 — Confondre le rôle du modérateur et de l’auteur
Dans une inspection, c’est le modérateur qui dirige la réunion — pas l’auteur. Dans un walkthrough, c’est l’inverse : l’auteur prend le lead. Beaucoup de candidats inversent ces deux rôles et perdent des points sur des questions pourtant directes.
Erreur 2 — Croire que les tests statiques ne s’appliquent qu’au code
Une question qui parle de « revue des exigences » ou de « vérification d’une user story » parle bien de tests statiques. Le terme « statique » signifie sans exécution du logiciel — pas sans lecture du code.
Erreur 3 — Ne pas distinguer revue technique et inspection
L’inspection a un formalisme maximal avec des rôles stricts (auteur, modérateur, scribe, réviseurs) et produit un rapport formel. La revue technique est plus souple et orientée vers les décisions techniques. Le critère de choix : si le scénario évoque un audit ou une conformité formelle, c’est l’inspection.
Question type avec analyse complète
Une équipe agile termine son sprint review. La Product Owner souhaite s’assurer que toute l’équipe comprend les user stories du prochain sprint. Elle veut les présenter elle-même et répondre aux questions. Quel type de revue est le plus approprié ?
A) Inspection B) Revue technique C) Walkthrough D) Revue informelle
Réponse : C — Walkthrough. L’objectif est le partage de compréhension, l’auteur (PO) prend le lead, et le contexte agile confirme un formalisme faible. L’option B est le piège classique : « vérifier » évoque la revue technique, mais c’est l’objectif de partage qui prime ici.
Comment préparer ce domaine efficacement
- Lire les sections 3.1 à 3.2.5 du syllabus officiel CTFL v4.0 (disponible gratuitement sur le site de l’ISTQB)
- Mémoriser le tableau des 4 types de revues avec leurs caractéristiques distinctives
- S’entraîner sur des questions de scénario K2 — la mémorisation brute ne suffit pas sur ce domaine
Pour aller plus loin, consultez notre guide complet CTFL v4.0 et notre article sur comment analyser ses résultats d’examen blanc.
Testez vos connaissances sur les tests statiques avec nos examens blancs CTFL v4.0 — 100+ questions, explications détaillées par domaine, score immédiat.
→ Accéder aux examens blancs CTFL v4.0