Processus & stratégie

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.

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 7 cas : code valide, expiré, déjà utilisé, cumul avec une autre promo, montant minimum non atteint, code en majuscules, champ vide.

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.

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 après chaque déploiement (5 min, 12 scénarios critiques) avant de lancer la régression complète (2h, 400 cas).

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écision 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.

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.

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 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

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

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

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 régression jouée à chaque commit
• Chaos testing 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-testing avec les développeurs
• Smoke tests automatisés sur les 10 scénarios clients
• Feedback continu avec les premiers utilisateurs

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é (OWASP Mobile Top 10)
• Tests d'accessibilité (WCAGWeb Content Accessibility Guidelines 2.2 AA)
• Audit indépendant avant chaque release majeure

À 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
• Vélocité de test (peut masquer une dette technique)