Qualité logicielle : construire la confiance

Cette publication est l’épisode 2 sur 9 de la série « De la preuve à l’action — L’agilité incarnée ». Elle conserve la distinction de la source entre références établies, retours d’expérience anonymisés et cas pédagogiques simulés.

Introduction — La qualité comme propriété du système

Cas pédagogique — données simulées. Chez My Little Old Cie, une hausse de vélocité coïncide avec davantage d’incidents, de reprises et d’insatisfaction. Le scénario illustre le risque d’optimiser une mesure d’activité au détriment de la qualité.

La qualité ne se résume ni au nombre de tests, ni à la couverture de code, ni à la présence d’un rôle QA. Elle résulte de décisions prises tout au long du cycle de vie : compréhension du besoin, conception, développement, vérification, déploiement, observation en production et apprentissage.

Les référentiels de test fournissent une terminologie et des techniques communes, applicables à des démarches prédictives comme adaptatives [7]. Ils ne prescrivent pas un seuil universel de couverture, de défauts ou de réussite des pipelines.

Trois confusions à éviter

Confondre vitesse locale et performance globale. Réduire une activité de vérification peut raccourcir une étape tout en augmentant le travail non planifié, les incidents et le délai global.

Déléguer la qualité à un rôle. Les spécialistes du test apportent des compétences d’analyse, d’exploration et de conception. La responsabilité du niveau de qualité attendu reste collective.

Automatiser sans stratégie. Un test automatisé apporte de la confiance seulement s’il vérifie un risque pertinent, produit un signal fiable et reste maintenable.

Un système de mesure équilibré

Les recherches DORA relient la livraison continue à des résultats de performance et de qualité, tout en combinant des métriques de débit et d’instabilité [8]. Cette approche soutient un principe essentiel : aller plus vite ne signifie pas réduire les contrôles, mais obtenir plus rapidement un signal fiable.

Organisation de la partie

• Le chapitre 5 pose les fondements du test logiciel et précise les niveaux, objectifs et techniques.
• Le chapitre 6 présente une méthode de structuration et de traçabilité des tests manuels.
• Le chapitre 7 applique cette méthode à un retour d’expérience industriel anonymisé. Les volumes et résultats y décrivent ce contexte particulier et ne constituent pas des seuils de référence.

Chapitre 5 — Les fondamentaux du test logiciel

Le test comme production d’information

Tester ne démontre pas l’absence de défaut. Le test produit une information sur la qualité et le risque afin d’aider une décision : intégrer, livrer, corriger, explorer davantage ou accepter explicitement une limite. Il contribue aussi à prévenir les défauts lorsque les exemples et critères sont discutés avant l’implémentation.

Quatre finalités se complètent :

• prévenir, en clarifiant tôt les comportements attendus et les risques ;
• détecter, en révélant une différence entre résultat observé et résultat attendu ;
• évaluer, en appréciant la qualité d’un produit dans un contexte d’usage ;
• informer, en rendant le risque résiduel compréhensible pour les décideurs.

Un vocabulaire précis

Une erreur est une action humaine incorrecte. Un défaut est une imperfection introduite dans un produit de travail. Une défaillance est un comportement observé qui s’écarte de l’attendu. Un défaut peut rester latent ; une défaillance peut aussi résulter d’une configuration, d’une donnée ou d’une interaction externe. Cette distinction évite de confondre cause, artefact et manifestation.

Niveaux de test et observation en production

Le syllabus CTFL v4 décrit cinq niveaux : composant, intégration de composants, système, intégration de systèmes et acceptation. Ils se distinguent par leur objet, leurs objectifs et leur base de test ; ils ne prescrivent pas un acteur unique pour chaque niveau.[7]

L’observation en production complète ces niveaux : télémétrie, déploiement progressif, tests synthétiques ou comparaison de versions peuvent détecter des comportements difficiles à reproduire ailleurs. Elle n’est pas un « sixième niveau » ISTQB et ne justifie pas d’exposer les utilisateurs à un risque non maîtrisé.

Types et approches

Le modèle des quadrants de test aide à équilibrer les tests orientés produit ou technologie, et ceux qui soutiennent l’équipe ou évaluent le produit. Il s’agit d’un outil de conversation, non d’un quota universel.[16]

Articuler validation automatisée, régression et test manuel

Un test automatisé est un logiciel : il a un coût de conception, d’exécution, de diagnostic et de maintenance. Sa valeur dépend d’abord de la décision qu’il éclaire. Le syllabus CTFL distingue la vérification — conformité à des exigences spécifiées — de la validation — aptitude à répondre aux besoins des utilisateurs et parties prenantes dans l’environnement opérationnel [7].

Les tests automatisés de validation traduisent les critères d’acceptation et les risques du changement en résultats observables. Ils répondent à la question : « avons-nous construit un comportement qui satisfait le besoin visé ? ». Ils sont exécutés avant la décision de livraison sur un environnement suffisamment représentatif ; leur réussite ne dispense pas d’examiner les hypothèses, les données et les risques non couverts.

Les tests automatisés de régression protègent les comportements déjà validés. Ils répondent à une autre question : « cette évolution a-t-elle dégradé une capacité existante ? ». Ils restent dans la suite permanente après la livraison, sont rejoués à chaque changement pertinent et doivent être sélectionnés selon le risque afin de limiter lenteur, fragilité et faux signaux.

Le test manuel reste indispensable lorsqu’une investigation demande du jugement, de l’adaptation ou une compréhension située : exploration d’un comportement nouveau, utilisabilité, cohérence visuelle, accessibilité vécue, ambiguïtés métier et scénarios difficiles à prévoir. Une validation humaine métier peut également éclairer l’acceptabilité dans le contexte réel. Elle ne doit cependant pas devenir une porte de contrôle systématique lorsque le comportement est fréquent, déterministe et automatisable.

La stratégie combine ces modalités au lieu de les opposer. Automatiser en priorité les contrôles fréquents, déterministes et importants ; conserver une exploration humaine intentionnelle pour ce qui exige du jugement. La forme de la « pyramide » dépend de l’architecture ; le principe robuste reste de rechercher le feedback utile au coût total le plus faible.

Concevoir par le risque

Pour chaque risque, relier conséquence, probabilité, détectabilité et capacité de récupération. Cette analyse guide la profondeur de test, l’environnement, les données, la fréquence et l’indépendance nécessaires. Le risque résiduel doit être formulé en termes compréhensibles : scénarios non couverts, hypothèses d’environnement, limitations connues et plan de surveillance.

Critère de qualité d’une stratégie de test

Elle permet de savoir ce qui a été vérifié, ce qui ne l’a pas été, avec quelles données, dans quel environnement et quelle décision ces observations soutiennent.

Chapitre 6 — Méthodologie du plan de test

Documenter les choix, pas accumuler les étapes

Un plan de test relie le contexte, les risques, la couverture, les moyens et les critères de décision. Il ne se réduit ni à un tableur de cas ni à une preuve que « tout a été testé ». Sa précision doit être proportionnée aux conséquences d’une défaillance, à la fréquence des changements et aux exigences de traçabilité.

Quatre artefacts complémentaires

1. Cas de test. Vérifie une règle ou un comportement identifiable. Il contient des préconditions, une action, un résultat attendu et un lien vers le besoin ou le risque.
2. Suite de tests. Regroupe des cas selon un parcours, une capacité ou un objectif de régression. L’ordre n’est imposé que lorsqu’il reflète une dépendance réelle.
3. Jeu de données. Décrit les valeurs, états, profils et règles de remise à zéro nécessaires à la reproductibilité.
4. Journal d’exécution. Associe version, environnement, données, résultat observé, statut, preuve et anomalie. Il constitue une trace d’exécution, pas une garantie absolue.

Cette séparation favorise la réutilisation, mais elle n’est pas obligatoire pour tous les produits. Un dispositif léger peut suffire lorsque l’impact est faible et le feedback rapide.

Écrire un cas exploitable

Un format Given/When/Then peut faciliter la discussion, sans être une exigence universelle :

Étant donné un compte soumis à une limite de 2 000 €
Et une demande d’un montant de 2 500 €
Quand l’utilisateur tente de la confirmer
Alors la demande reste non engagée
Et une approbation est sollicitée auprès du rôle autorisé

Le résultat attendu doit être observable. Éviter les formulations comme « fonctionne correctement ». Paramétrer les données lorsqu’elles varient souvent, tout en gardant un exemple lisible pour la revue métier.

Construire la couverture

La couverture n’est pas seulement un pourcentage de code. Elle peut relier risques, règles, parcours, plateformes, profils, données limites et qualités non fonctionnelles. Une matrice de traçabilité légère suffit souvent :

Préparer environnement et données

Préciser la représentativité de l’environnement, les versions des dépendances, les mécanismes de génération ou d’anonymisation, les droits d’accès et la remise en état. Les données sensibles suivent les politiques applicables. Une donnée réaliste n’autorise pas l’usage indiscriminé de données de production.

Définir les critères de décision

Les critères d’entrée indiquent ce qui doit être prêt pour obtenir un résultat interprétable. Les critères de sortie relient les tests exécutés, les anomalies, les risques résiduels et les capacités de surveillance. Un taux de réussite seul masque l’importance relative des scénarios ; la décision doit considérer la gravité, l’exposition et la capacité de récupération.

Maintenir le patrimoine

Versionner les cas avec le produit, supprimer les doublons, suivre les tests instables et revoir les suites à partir des incidents et changements de risque. Mesurer le temps de feedback et le coût de diagnostic évite qu’un grand volume automatisé donne une illusion de sécurité.

Revue minimale avant campagne

Périmètre, risques prioritaires, environnements, données, responsabilités, critères d’arrêt, mécanisme d’anomalie et autorité de décision.

Chapitre 7 — Cas pratique : appliquer la méthodologie

Retour d’expérience anonymisé

Les noms, identifiants et certaines données ont été adaptés. Les volumes et résultats décrivent ce contexte particulier ; ils ne constituent pas des benchmarks et n’ont pas fait l’objet d’une vérification indépendante.

Contexte et décision

Une entreprise industrielle prépare la migration du périmètre achats-stocks d’un ERP vers une solution SaaS. Deux conséquences dominent l’analyse : interruption de production en cas de réapprovisionnement incorrect et engagement financier sans autorisation. L’objectif de la campagne est d’éclairer la décision de mise en service et de rendre le risque résiduel explicite.

Du besoin au scénario

Une Job Story synthétise une situation, une motivation et un résultat :

Quand le stock projeté d’un composant critique passe sous son seuil de sécurité, je veux qu’une demande d’achat prioritaire soit créée afin de préserver la continuité de production.

La règle est ensuite déclinée en exemples : juste au-dessus du seuil, exactement au seuil, juste en dessous, commande déjà ouverte, fournisseur indisponible et calcul interrompu. Les cas couvrent aussi les transitions entre production, achats, stock et finance.

Dispositif retenu

Un cas représentatif vérifie qu’une consommation faisant passer le stock sous le seuil déclenche une demande d’achat, avec quantité, statut et date conformes. La suite de bout en bout poursuit le parcours jusqu’à l’approbation, la commande et la réception. Les données sont référencées par identifiant afin qu’un autre testeur puisse reproduire l’exécution.

Résultats observés

La campagne a signalé quatorze défauts classés critiques par l’équipe, notamment un décalage de dates de besoin lié aux jours non ouvrés. Après correction, les 85 scénarios prioritaires ont été rejoués en deux jours contre cinq lors d’une campagne antérieure jugée comparable. Les suites ont également servi de support à la formation opérationnelle.

Ces résultats suggèrent que la préparation des données et la standardisation des scénarios ont réduit le temps de remise en contexte. Ils ne permettent pas d’attribuer avec certitude tout le gain à la méthode : composition de l’équipe, stabilité de l’environnement et périmètre des versions ont aussi pu contribuer.

Décision et risque résiduel

La mise en service a été autorisée après correction des anomalies critiques, exécution des scénarios prioritaires et validation d’un plan de surveillance. Des limites restaient documentées : charge maximale non reproduite, dépendance à un service externe et procédure de repli partiellement manuelle. L’équipe a nommé les propriétaires de ces risques et prévu une revue après démarrage.

Enseignement transférable

La valeur du plan tient moins au nombre de cas qu’à la traçabilité entre risque, scénario, résultat observé et décision.

Sources

1. Manifesto for Agile Software Development, Kent Beck et al., 2001.

2. Le Guide Scrum, Ken Schwaber et Jeff Sutherland, version française, novembre 2020.

3. The Kanban Guide, Kanban Guides, mai 2025.

4. Evidence-Based Management Guide, Scrum.org, 2024.

5. Unskilled and unaware of it, Justin Kruger et David Dunning, Journal of Personality and Social Psychology, 1999.

6. Psychological Safety and Learning Behavior in Work Teams, Amy C. Edmondson, Administrative Science Quarterly, 1999.

7. Certified Tester Foundation Level — CTFL v4.0, ISTQB, page et syllabus officiels.

8. DORA metrics, DORA, guide officiel des indicateurs de performance de livraison logicielle.

9. Shape Up, Basecamp, ressource officielle en ligne.

10. Org Topologies — Mapping, Org Topologies, ressource officielle de cartographie.

11. The Kanban Guide for Scrum Teams, Scrum.org, guide officiel.

12. Turn the Ship Around!, L. David Marquet, page officielle de l’ouvrage.

13. Managing the Development of Large Software Systems, Winston W. Royce, actes IEEE WESCON, 1970.

14. Problems of Monetary Management: The U.K. Experience, Charles A. E. Goodhart, 1975.

15. Theory in Practice: Increasing Professional Effectiveness, Chris Argyris et Donald A. Schön, 1974.

16. Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin et Janet Gregory, Addison-Wesley, 2009.

17. Thinking, Fast and Slow, Daniel Kahneman, Farrar, Straus and Giroux, 2011.