Processus & stratégie

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 personnes utilisatrices, le support, le métier ou les équipes dev qui dictent les priorités de test. Le pôle QA 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

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.

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

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.

Ce que l'on estime concrètement

L'estimation ne se résume pas à deviner une date de livraison. Elle porte sur trois dimensions complémentaires :

• L'effort : la charge de travail effectif (en heures, jours-homme ou story points) nécessaire pour concevoir, automatiser, préparer les données et exécuter les tests.
• La durée : le temps calendaire total (jours ou semaines) en intégrant les délais d'attente, livraisons de builds et disponibilités de l'équipe.
• Les ressources & coûts : les profils de test requis, les accès aux outils de test et les environnements à réserver.

Les facteurs d'influence

Pourquoi l'effort varie-t-il d'un projet à l'autre ? Les estimations dépendent principalement de :

• Du produit : sa complexité technique et métier, son niveau de risque et ses exigences de sécurité.
• Du processus : la clarté et stabilité des spécifications, la maturité de l'équipe et les outils d'automatisation en place.
• De la qualité du code : le nombre et la criticité des anomalies trouvées, qui imposent des cycles de re-test et de régression imprévus.

1. Basée sur l'expertise

On s'appuie sur l'expérience et le jugement de personnes chevronnées (profils QA senior, architectes, chefs de projet) qui évaluent l'effort selon leur vécu.

Techniques phares :

• Delphi large bandeChaque participant estime individuellement et anonymement (ex. effort en jours-homme, durée ou coût), les écarts sont discutés en groupe, puis on refait un tour d'estimation ; on répète jusqu'à ce que les estimations convergent : estimations individuelles anonymes suivies de tours d'échange jusqu'à consensus.
• Planning poker : estimation collective en story points pratiquée en équipe agile.

2. Estimation en trois points

Variante mathématique de l'expertise. Pour éviter de parier sur un seul chiffre, on pondère trois scénarios : optimiste (a), probable (m) et pessimiste (b).

Moyenne pondérée : E = (a + 4m + b) / 6

Marge d'erreur (écart-typeStandard Deviation : mesure la dispersion et le niveau d'incertitude autour de la moyenne) : SD = (b - a) / 6

Exemple : si a = 4 j (scénario idéal), m = 7 j (scénario réaliste) et b = 16 j (scénario avec gros blocages), l'effort retenu est E = 8 ± 2 jours-homme (soit entre 6 et 10 jours de travail).

3. Basée sur des métriques

L'estimation repose sur des données chiffrées réelles et historiques mesurées lors de projets précédents plutôt que sur un ressenti subjectif.

Exemples de métriques :

• Ratios historiques : temps moyen pour concevoir un cas de test ou nombre moyen de tests par point de fonction.
• Vélocité constatéeQuantité de travail (souvent mesurée en story points) qu'une équipe est capable de réaliser et valider au cours d'un sprint : capacité réelle mesurée lors des sprints passés pour calibrer les suivants.

À 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 personne en test
• VélocitéQuantité de travail (souvent mesurée en story points) qu'une équipe est capable de réaliser et valider au cours d'un sprint de test (peut masquer une dette technique)