Processus & stratégie
Tester sans plan, c'est espérer. Le processus de test ISTQB structure la démarche en six activités cohérentes - et la stratégie choisie détermine la profondeur, la priorité et le vitesse de chacune.
01 - Les activités
Les 6 activités du processus de test
Selon l'ISTQB Foundation Level. Les activités sont logiques, pas strictement séquentielles : on itère.
01
Planification
OBJECTIF : Définir les objectifs, le périmètre, les risques, les critères d'entrée et de sortie, les ressources et le calendrier. C'est le moment où l'on rédige le Plan de Test.
LIVRABLES :
-
Plan de test
-
Stratégie de test
-
Matrice des risques
Cas concret : Sur un nouveau module de paiement : on identifie les risques (perte d'argent, fraude), on fixe le critère de sortie "0 bug bloquant", "5 majeurs" + 3 sprints de test.
02
Analyse & conception
OBJECTIF : Identifier ce qui sera testé et comment on va tester.
LIVRABLES :
-
Conditions de test
-
Cas de test
-
Jeux de données
-
Matrice de traçabilité exigences/tests
Cas concret : Une user story « Le client peut appliquer un code promo » donne éventuelle 7 cas : code valide, expiré, déjà utilisé, cumul avec une autre promo, montant minimum non atteint, code en majuscules, champ vide.
03
Implémentation
OBJECTIF : Préparer les scripts, jeux de données, environnements, ordonnancement et procédures d'exécution. C'est aussi la phase où l'on automatise les cas pertinents.
LIVRABLES :
-
Scripts manuels & automatisés
-
Environnements prêts
-
Suites de tests organisées
Cas concret : Préparation d'un jeu de données anonymisé pour le test de charge : 50 000 comptes clients fictifs, panier moyen calibré, comportements répartis sur 24h.
04
Exécution
OBJECTIF : Exécuter les tests (manuels ou automatisés), comparer les résultats attendus et obtenus, journaliser les anomalies et les écarts.
LIVRABLES :
-
Résultats d'exécution
-
Logs
-
Anomalies déclarées
-
Captures d'écran / vidéos
Cas concret : Smoke test (test de fumée - test rapide et sommaire) après chaque déploiement (5 min, 12 scénarios critiques) avant de lancer la régression complète (2h, 400 cas).
05
Pilotage & contrôle
OBJECTIF : Suivre l'avancement, mesurer la couverture, analyser les écarts par rapport au plan, ajuster les priorités, communiquer aux parties prenantes.
LIVRABLES :
-
Rapport des tests
-
Dashboard de couverture
-
Rapport des anomalies
-
Décisions "Go/No-Go"
-
Cas concret : À J-2 d'une release : 92% des cas passés, 3 anomalies majeures ouvertes. Décision : Go conditionnel avec hotfix prévu en J+1.
06
Clôture
OBJECTIF : Capitaliser les enseignements, archiver, livrer le rapport final, transférer aux équipes de maintenance, organiser une rétrospective.
LIVRABLES :
-
Rapport des tests
-
Leçons apprises
-
Backlog des dettes de test
Cas concret : Rétro de fin de projet : "60% des bugs venaient du module legacy non couvert par les tests unitaires" → action : prioriser un chantier sur ce module.
02 - Les stratégies
Les 7 stratégies de test
On combine généralement plusieurs stratégies. L'enjeu est de doser en fonction du contexte, du risque et du temps disponible.
Analytique
On part d'une analyse formelle (matrice de risques, exigences, modèle) pour décider quoi tester et avec quelle profondeur. C'est la stratégie de référence en environnement réglementé (banque, santé, aéronautique).
Quand l'utiliser : Projets critiques, exigences claires, contexte réglementé
Basée sur un modèle
On modélise le comportement attendu (diagrammes d'états, tables de décision, BPMN - Business Process Model and Notation) et on génère les cas à partir du modèle. Excellent pour les workflows complexes (commande, souscription, états d'un dossier).
Quand l'utiliser : Règles métier nombreuses, besoin de couverture exhaustive
Méthodique
On s'appuie sur des référentiels éprouvés (OWASP, WCAG, ISO 25010, heuristiques de Bach - règles générales ou grilles d’exploration) pour ne rien oublier. Très utile pour les tests non-fonctionnels.
Quand l'utiliser : Sécurité, accessibilité, performance, équipes en montée en compétence.
Conforme au processus
On suit un standard imposé : ISTQB, IEEE 829, normes internes d'une grande entreprise. La traçabilité prime sur l'agilité.
Quand l'utiliser : Audit, certification, sous-traitance avec engagements contractuels
Réactive
On réagit au logiciel tel qu'il est livré : tests exploratoires, sessions chronométrées (SBTM - Session‑Based Test Management - gestion de test par sessions). La connaissance se construit pendant l'exécution.
Quand l'utiliser : Délais courts, exigences floues
Consultative
Ce sont les utilisateurs, le support, le métier ou les développeurs qui dictent les priorités de test. Le testeur facilite et structure.
Quand l'utiliser : Produit mûr, dette qualité connue, équipes Ops impliquées
Anti-régression
On capitalise sur l'existant : suites de régression massives, automatisation lourde, comparaison entre captures. Minimiser le risque de casser ce qui marche.
Quand l'utiliser : Produits matures, releases fréquentes, faible tolérance aux régressions
Impact
Qu'est-ce qu'on perd si ça casse ? Argent, réputation, conformité, vies humaines ?
Probabilité
Quelle est la chance que ça casse ? Code récent, équipe junior, dépendances instables, complexité ?
03 - Les risques
Stratégie basée sur les risques
Une stratégie de test basée sur les risques consiste à concentrer principalement les efforts de test sur les parties du système qui présentent le plus de risque pour les affaires, les utilisateurs ou la sécurité, plutôt que de tester uniformément toutes les fonctionnalités.
Toutes les fonctionnalités ne se valent pas. Chaque risque produit est scoré sur deux axes :
04 - Les entrants et sortants
Les critères d'entrée et de sortie
Les critères d’entrée disent quand on commence une phase de test, les critères de sortie disent quand on peut la terminer.
Un exemple de critères d'entrée et de sortie :
Critères d'entrée
LIVRABLES :
-
Exigences validées
-
Environnement disponible
-
Données de test prêtes
-
Build déployé
-
Anomalies bloquantes connues ou traitées
Cas concret : À J-2 d'une release : 92% des cas passés, 3 anomalies majeures ouvertes. Décision : Go conditionnel avec hotfix prévu en J+1.
Critères de sortie
-
100% des cas critiques exécutés, 0 bug bloquant ouvert
-
Couverture des exigences ≥ seuil défini (ex : 95%)
-
Tous les bugs majeurs ont une décision (corrigé / accepté / reporté)
-
Tests de non-régression au vert
-
Rapport de test validé par le Product Owner
05 - Cas concrets
Choisir sa stratégie
Trois contextes différents, trois doses de stratégies adaptées.
E-commerce - Black Friday
Risque principal — Pic de charge × 20, panier abandonné = chiffre perdu.
Stratégies adoptées — Analytique (risques) + Méthodique (performance) + Anti-régression.
Actions concrètes :
-
Modélisation des risques métier (paiement, stock, recherche)
-
Tests de charge JMeter/k6 reproduisant le pic réel
-
Suite de regression jouée à chaque commit
-
Chaos testing sur le panier pour valider la résilience
Startup SaaS B2B — premier MVP
Risque principal — Spécifications mouvantes, équipe réduite, time-to-market.
Stratégies adoptées — Réactive (exploratoire) + Consultative
Actions concrètes :
-
Sessions exploratoires de 90 min, charte écrite, debrief
-
Pair-testing avec les développeurs
-
Smoke automatisé sur les 10 scénarios clients
-
Feedback continu avec les premiers utilisateurs
Application bancaire mobile
Risque principal — Réglementation (DSP2 - Directive (UE) 2015/2366 relative aux services de paiement dans le marché intérieur), sécurité, données sensibles.
Stratégies adoptées — Conforme au processus + Méthodique (OWASP - Open WorldWide Application Security Project, MASVS - Mobile Application Security Verification Standard).
Actions concrètes :
-
Plan de test traçable exigence par exigence
-
Tests de sécurité (OWASP Mobile Top 10)
-
Tests d'accessibilité (WCAG 2.2 AA - conformité au niveau AA des Règles pour l’accessibilité des contenus Web (WCAG) version 2.2)
-
Audit indépendant avant chaque release majeure
06 - Indicateurs
Indicateurs utiles (et ceux qui mentent)
À suivre
-
Taux de couverture des exigences critiques
-
Densité de bugs par module (bug hotspots)
-
Temps moyen de détection (MTTD - Mean Time To Detect) et de correction (MTTR - Mean Time To Repair)
-
Taux de fuite en production (escaped defects)
-
Stabilité de la suite automatisée (flaky rate)
À manier avec prudence
-
Nombre brut de cas de test (quantité ≠ qualité)
-
% de couverture de code (100% ne garantit rien)
-
Nombre de bugs trouvés par testeur
-
Vélocité de test (peut masquer une dette technique)
07 - A retenir
En bref :
-
Le processus de test ISTQB se compose de 6 activités, mais il est itératif : on ajuste en continu plutôt que de suivre une séquence figée.
-
Une stratégie de test ne se copie pas dans un livre : elle se construit en fonction du contexte, des risques, des contraintes et de la maturité de l’équipe.
-
Une approche basée sur les risques permet de concentrer l’effort là où l’impact d’un défaut serait le plus fort (argent, réputation, conformité, sécurité).
-
Les critères d’entrée et de sortie aident à décider quand commencer et quand arrêter une phase de test, au lieu de tester “jusqu’à ce qu’on n’ait plus le temps”.