QA et Testing : passer d’une logique de recette à une logique de qualité produit

Dans de nombreuses organisations, la qualité logicielle intervient encore trop tard.

Les équipes développent, puis transmettent l’application à une équipe de recette qui doit identifier les anomalies avant la mise en production. Cette organisation peut fonctionner sur un périmètre limité. Elle devient fragile lorsque les versions s’accélèrent, que les dépendances se multiplient et que les applications deviennent critiques.

La recette reste indispensable, mais elle ne peut pas porter seule la qualité du produit.

Une recette finale ne suffit pas

Une anomalie détectée tardivement coûte généralement plus cher à analyser et à corriger qu’un problème identifié pendant la conception ou le développement.

La recette finale ne permet pas toujours de répondre aux questions suivantes :

• Les exigences sont-elles suffisamment précises ?

• Les règles métier ont-elles été comprises de la même manière ?

• Les interfaces avec les autres systèmes ont-elles été testées ?

• Les données de test sont-elles représentatives ?

• Les performances sont-elles compatibles avec les usages réels ?

• Les scénarios critiques ont-ils été rejoués après chaque évolution ?

La qualité doit donc être pensée comme une responsabilité partagée entre produit, métier, développement, exploitation et QA.

Première évolution : passer de la détection à la prévention

La QA ne consiste pas uniquement à trouver des bugs.

Elle contribue aussi à :

• clarifier les exigences ;

• identifier les risques ;

• définir les critères d’acceptation ;

• préparer les jeux de données ;

• organiser les scénarios de test ;

• anticiper les impacts d’une évolution ;

• documenter les résultats.

Cette approche évite de découvrir en recette que la fonctionnalité demandée ne répond pas au besoin réel ou qu’elle rend impossible un processus existant.

Deuxième évolution : tester en fonction des risques

Tous les éléments d’une application ne présentent pas le même niveau de criticité.

Une fonctionnalité peut être prioritaire parce qu’elle :

• traite des données sensibles ;

• génère du chiffre d’affaires ;

• intervient dans la facturation ;

• est utilisée par un grand nombre de personnes ;

• dépend d’un système externe ;

• doit respecter une contrainte réglementaire ;

• est difficile à corriger après mise en production.

La stratégie de test doit tenir compte de ces risques. Tester tout de la même manière est rarement réaliste. Il faut concentrer les efforts là où une défaillance aurait les conséquences les plus importantes.

Troisième évolution : automatiser avec discernement

L’automatisation peut améliorer la couverture et réduire le temps de rejouabilité. Elle n’est cependant pas une solution automatique à tous les problèmes.

Un test automatisé peut devenir coûteux lorsqu’il est :

• instable ;

• trop dépendant de l’interface ;

• mal documenté ;

• difficile à maintenir ;

• exécuté sans analyse des résultats ;

• utilisé sur des scénarios qui changent constamment.

Avant d’automatiser, il faut déterminer :

• ce qui doit être rejoué souvent ;

• ce qui est stable ;

• ce qui est critique ;

• ce qui peut être contrôlé automatiquement ;

• qui maintiendra les tests ;

• comment seront traités les échecs.

Une automatisation bien ciblée apporte de la valeur. Une automatisation non maîtrisée ajoute une dette technique.

Quatrième évolution : intégrer la performance et les usages réels

Une application peut être fonctionnellement correcte et rester inutilisable.

Il faut également vérifier :

• les temps de réponse ;

• le comportement en charge ;

• la stabilité sur des volumes importants ;

• la compatibilité avec les environnements utilisés ;

• l’accessibilité des parcours ;

• les comportements en cas d’erreur ;

• la récupération après interruption.

Ces tests doivent être prévus en fonction du contexte de production. Une application testée avec dix utilisateurs et quelques centaines de lignes ne réagira pas nécessairement de la même façon avec plusieurs milliers d’utilisateurs et des volumes réels.

Cinquième évolution : mesurer la qualité autrement

Le nombre d’anomalies recensées ne suffit pas à mesurer la qualité.

Il est plus utile de suivre plusieurs indicateurs :

• taux de réussite des scénarios critiques ;

• anomalies bloquantes ouvertes à la mise en production ;

• taux de régression ;

• délai moyen de correction ;

• taux de tests automatisés réellement exécutés ;

• incidents post-production ;

• couverture des risques prioritaires ;

• satisfaction des utilisateurs.

L’objectif n’est pas d’obtenir un score parfait. Il consiste à disposer d’une vision suffisamment fiable pour décider si une version peut être mise en production et dans quelles conditions.

À retenir

Une démarche QA mature repose sur quatre principes :

1. Impliquer la qualité dès la conception.

2. Prioriser les tests selon les risques.

3. Automatiser ce qui est stable, répétitif et critique.

4. Mesurer les incidents réels, pas uniquement le volume de tests.

pragmaIT intervient sur la stratégie de test, la recette fonctionnelle, l’automatisation, la performance, la qualité logicielle et l’AMOA, avec des profils capables de travailler avec les équipes métier, produit et IT.

Nous connectons les talents IT aux besoins des entreprises.

Vous souhaitez être contacté ?

© 2025. pragmaIT S.A.S - Tous droits réservés
Mentions légales

Offre Consulting

Offre Formation

Nos engagements RSE

Nos offres