01 — Les activités
Les 7 activités du processus de test
Selon l'ISTQBInternational Software Testing Qualifications Board Niveau Fondation, les activités sont logiques, pas strictement séquentielles : on itère, et le pilotage & contrôle accompagne les autres en continu plutôt que de suivre une place fixe.
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".
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.
Pilotage & contrôle
Objectif : Suivre l'avancement, mesurer la couverture, analyser les écarts par rapport au plan et ajuster les priorités. Contrairement aux autres, cette activité est continue : elle accompagne toutes les suivantes plutôt que de suivre une place fixe dans la séquence.
- Monitoring : couverture, résultats, avancement.
- Contrôle : réallouer des ressources, revoir le périmètre, escalader un risque.
Cas concret : À J-2 d'une livraison : 92% des cas passés, 3 anomalies majeures ouvertes. Décision : Go conditionnel avec hotfixCorrectif publié en urgence, en dehors du cycle de livraison habituel prévu en J+1.
Analyse
Objectif : Identifier ce qui sera testé : conditions de test et priorités à partir des exigences et des risques.
Cas concret : Une user story "Le•la client•e peut appliquer un code promo" donne plusieurs conditions à couvrir : code valide, expiré, déjà utilisé, cumul avec une autre promo, montant minimum non atteint, code en majuscules, champ vide.
Conception
Objectif : Concevoir les cas de test et les procédures de test à partir des conditions de test identifiées.
Cas concret : Pour chacune des 7 conditions retenues sur le code promo, on crée un cas de test documenté (donnée d'entrée, étapes, résultat attendu).
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.
Cas concret : Préparation d'un jeu de données anonymisé pour le test de charge : 50 000 comptes client•es fictifs·ves, panier moyen calibré, comportements répartis sur 24h.
Exécution
Objectif : Exécuter les tests (manuels ou automatisés), comparer les résultats attendus et obtenus, journaliser les anomalies et les écarts.
Cas concret : Smoke testVérification rapide que les fonctions critiques fonctionnent, avant d'aller plus loin après chaque déploiement (5 min, 12 scénarios critiques) avant de lancer la régression complète (2h, 400 cas).
Clôture
Objectif : Capitaliser les enseignements, archiver, livrer le rapport final, transférer aux équipes de maintenance, organiser une rétrospective.
Cas concret : Rétrospective de fin de projet : "60% des bugs venaient du module legacyCode ancien, souvent peu documenté ou peu testé, encore en production mais rarement retouché. non couvert par les tests unitaires" → action : prioriser un chantier sur ce module.
02 — Les stratégies
Quelques stratégies de test
Hors syllabus FondationOn combine généralement plusieurs stratégies. L'enjeu est de doser en fonction du contexte, du risque et du temps disponible.
Analytique
Partir d'une analyse formelle (matrice de risques, exigences, modèle) pour décider quoi tester et avec quelle profondeur. 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
Modéliser le comportement attendu (diagrammes d'états, tables de décision, BPMNBusiness Process Model and Notation) et générer les cas à partir du modèle. Excellent pour les workflows complexes.
Quand l'utiliser : Règles métier nombreuses, besoin de couverture exhaustive
Méthodique
S'appuyer sur des référentiels éprouvés (OWASPOpen Web Application Security Project, WCAGWeb Content Accessibility Guidelines, ISOInternational Organization for Standardization 25010, heuristiques de Bach) 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
Suivre un standard imposé : ISTQBInternational Software Testing Qualifications Board, IEEEInstitute of Electrical and Electronics Engineers 829, normes internes. La traçabilité prime sur l'agilité.
Quand l'utiliser : Audit, certification, sous-traitance avec engagements contractuels
Réactive
Interagir avec le logiciel tel qu'il est livré : tests exploratoires, sessions chronométrées (SBTMSession-Based Test Management). La connaissance se construit pendant l'exécution.
Quand l'utiliser : Délais courts, exigences floues
Consultative
Ce sont les utilisateur•rices, le support, le métier ou les développeur•ses qui dictent les priorités de test. Le•la testeur•se facilite et structure.
Quand l'utiliser : Produit mûr, dette qualité connue, équipes Ops impliquées
Anti-régression
Capitaliser 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
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 utilisateur•rices ou la sécurité, plutôt que de tester uniformément toutes les fonctionnalités.
Risque produit
Le risque qu'un défaut du logiciel lui-même pose problème : calcul erroné, faille de sécurité, perte de données, mauvaise performance. C'est le risque que le test adresse directement, et celui qu'évalue la matrice ci-dessous.
Risque projet
Le risque que le projet n'atteigne pas ses objectifs : délais, budget, ressources, organisation, compétences, fournisseurs. Il ne dit rien de la qualité du produit, mais peut réduire le temps ou les moyens disponibles pour le tester.
Impact
Quels seront les impacts en cas d'anomalie avérée ? Argent, réputation, conformité, vies humaines ?
Probabilité
Quelle est la probabilité qu'une anomalie se produise ? Code récent, équipe junior, dépendances instables, complexité ?
04 — Les entrants et sortants
Les critères d'entrée et de sortie
Les critères d'entrée disent quand commencer une phase de test, les critères de sortie disent quand terminer.
Critères d'entrée
- Exigences validées
- Environnement disponible
- Données de test prêtes
- Build déployé
- Anomalies bloquantes connues ou traitées
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 — Gestion de configuration
Gestion de configuration
Elle garantit l'intégrité et la traçabilité de tout ce qui est testé : quelle version du logiciel, avec quels cas de test, sur quel environnement. Sans elle, impossible de rejouer un test dans les mêmes conditions ou de savoir ce qui a réellement été validé.
Versionning
Identifier de manière unique chaque version d'un élément (code, exigence, cas de test, jeu de données, environnement) pour savoir précisément ce qui a été testé et quand.
Baseline
Un point de référence figé (exigences validées, version livrée) à partir duquel tout changement ultérieur est contrôlé, tracé et comparé.
Traçabilité
Relier les versions entre elles (exigence ↔ cas de test ↔ résultat ↔ anomalie) pour savoir ce qui a été testé sur quelle version, et pouvoir rejouer les tests dans le bon contexte.
06 — Techniques d'estimation
Techniques d'estimation
Avant de planifier, encore faut-il estimer l'effort de test nécessaire. Deux approches, souvent combinées.
Basée sur l'expertise
Des personnes expérimentées (testeur•ses senior, chef•fes de projet, l'équipe elle-même) estiment l'effort à partir de leur jugement et de projets comparables déjà menés.
Techniques : Delphi large bande (chaque expert•e estime individuellement et anonymement, les écarts sont discutés en groupe, puis on refait un tour d'estimation ; on répète jusqu'à ce que les estimations convergent), planning poker en contexte agile.
Basée sur des métriques
L'estimation s'appuie sur des données historiques mesurées lors de projets précédents plutôt que sur un avis subjectif.
Exemples : nombre moyen de cas de test par point de fonction, temps moyen de conception par exigence, vélocité constatée sur les sprints précédents.
07 — 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/k6Outils open source pour simuler de nombreux utilisateurs et mesurer la tenue en charge reproduisant le pic réel
- Suite de régression jouée à chaque commit
- Chaos testingProvoquer volontairement des pannes (serveur, réseau) pour vérifier que le système résiste sur le panier pour valider la résilience
Startup SaaSSoftware as a Service B2BBusiness to Business (premier MVPMinimum Viable Product)
Risque principal : Spécifications mouvantes, équipe réduite, délai court.
Stratégies adoptées : Réactive (exploratoire) + Consultative.
Actions concrètes :
- Sessions exploratoires de 90 min, avec une charte de test écrite puis debrief
- Pair-testingDeux personnes testent ensemble, en binôme, sur le même poste avec les développeur•ses
- Smoke tests automatisés sur les 10 scénarios clients
- Feedback continu avec les premier•ères utilisateur•rices
Application bancaire mobile
Risque principal : Réglementation (DSP2Directive sur les Services de Paiement 2), sécurité, données sensibles.
Stratégies adoptées : Conforme au processus + Méthodique (OWASPOpen Web Application Security Project, MASVSMobile Application Security Verification Standard).
Actions concrètes :
- Plan de test traçable exigence par exigence
- Tests de sécurité (OWASPOpen Web Application Security Project Mobile Top 10)
- Tests d'accessibilité (WCAGWeb Content Accessibility Guidelines 2.2 AA)
- Audit indépendant avant chaque release majeure
08 — 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 (MTTDMean Time To Detect) et de correction (MTTRMean Time To Repair)
- Taux de fuite en production (escaped defects)
- Stabilité de la suite automatisée (flaky rateTaux de tests instables : résultat différent à chaque exécution, sans changement de code)
À 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•se
- Vélocité de test (peut masquer une dette technique)
A retenir
Ce qu'il faut retenir
7 activités, un pilotage continu
Le processus de test ISTQBInternational Software Testing Qualifications Board se compose de 7 activités, dont le pilotage & contrôle qui est continu plutôt que de suivre une place fixe dans la séquence.
Une stratégie, pas une recette
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.
Concentrer l'effort sur le risque
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é.
Savoir quand commencer et arrêter
Les critères d'entrée et de sortie aident à décider quand commencer et quand arrêter une phase de test.
Mise en pratique
Testez votre compréhension
Une sélection de questions basées sur ce que vous venez de lire.
On identifie les risques, on rédige la matrice des risques et on fixe les critères d'entrée et de sortie. À quelle activité du processus de test cela correspond-il ?
Une user story donne lieu à 7 conditions de test couvrant les cas valides, invalides et limites. Quelle activité identifie ces conditions ?
À J-2 d'une release, l'équipe mesure la couverture, analyse les écarts et prend une décision Go/No-Go. Quelle activité est-ce ?
Une équipe s'appuie sur l'OWASP et les heuristiques de Bach pour ne rien oublier lors de tests non-fonctionnels. Quelle stratégie applique-t-elle ?
Faute de spécifications stables et avec un délai très court, l'équipe explore le logiciel en sessions chronométrées. Quelle stratégie est-ce ?
Une application bancaire mobile doit respecter la DSP2 et une traçabilité stricte exigence par exigence. Quelle stratégie domine ici ?
À savoir
La Minute QA est une aide à la compréhension, pas une formation professionnelle : certains points ne peuvent pas être couverts ici. Pensez à suivre une formation certifiante et à consulter le syllabus officiel ISTQB pour une préparation complète.
Pour aller plus loin