Le QA classique a fait son temps : ce qui est arrivé aux tests

Cas de test, régression, couverture : l'industrie du QA s'appuie sur ces outils depuis des décennies. Ils semblaient universels. On écrit les vérifications, on les lance avant la release, on s'assure que rien n'est cassé. Ce modèle s'effondre pourtant dans les conditions actuelles du développement, où releases continues, microservices et systèmes cloud sont devenus la norme.

Comment le développement a radicalement changé

Autrefois, les entreprises publiaient une nouvelle version de leur produit une fois par trimestre ou par semestre. Les testeurs travaillaient en cascade : le développeur écrit le code, le QA le vérifie, puis vient le déploiement. Aujourd'hui, Uber, Netflix et Spotify effectuent de 10 à 100 déploiements par jour. Les modifications partent en production plusieurs fois par heure.

L'architecture a elle aussi radicalement changé. Les monolithes ont éclaté en microservices qui tournent sur une infrastructure cloud. Les ressources sont créées et supprimées à la demande. Une nouvelle classe de problèmes est apparue : pannes réseau, désynchronisation entre services, pertes de données dans les transactions distribuées.

Au même moment, des composants d'IA ont fait leur entrée dans les systèmes. Ils sont par nature non déterministes : une même entrée peut produire des sorties différentes. Comment tester ce qui se comporte de façon imprévisible ?

Pourquoi l'approche classique ne fonctionne plus

Le problème ne tient ni aux tests eux-mêmes ni à la paresse des équipes QA. C'est le modèle tout entier qui pose problème.

Les cas de test exigent une mise à jour permanente, mais les fonctionnalités se multiplient plus vite que les tests ne peuvent suivre. Il en résulte un retard et un faux sentiment de sécurité.

La couverture de code est devenue une fin en soi au lieu d'un outil. Une couverture de 100% ne garantit pas l'absence de bugs : elle indique seulement que toutes les lignes de code ont été exécutées.

Le temps nécessaire aux tests de régression croît de façon exponentielle : chaque nouvelle fonctionnalité oblige à vérifier tout l'existant en plus du nouveau. En quelques années, la charge devient insoutenable.

La recette avant release s'est transformée en goulet d'étranglement. Elle ralentit le cycle et devient un point de défaillance.

L'automatisation a aidé, mais elle a créé un nouveau problème : les scripts cassent à chaque modification de l'interface ou de l'API.

Ce qui prend le relais

Au lieu de tester de façon statique en laboratoire, les entreprises adoptent des approches adaptées à la réalité du développement :

• Tests de contrat : les microservices vérifient entre eux la cohérence de leurs contrats d'API
• Chaos engineering : les ingénieurs cassent volontairement le système pour éprouver sa tolérance aux pannes
• Observabilité et monitoring : détection des problèmes en production à partir des métriques et des logs
• Feature flags : déploiement progressif des nouvelles fonctionnalités et rollback en quelques secondes
• Continuous testing en production : vérification sur des données réelles, avec de vrais utilisateurs

Le changement de paradigme est évident. Auparavant, les tests intervenaient en début de cycle, avant la mise en production. Désormais, ils se poursuivent en production. Le déploiement n'est plus la fin du cycle de vérification, mais son point de départ.

Ce que cela signifie

Le QA cesse d'être un garde-frontière pour devenir un ingénieur chargé de gérer les risques en production. Cela suppose une reconversion : plutôt que de savoir rédiger des cas de test, il faut maîtriser le monitoring, l'ingénierie de la fiabilité et l'architecture microservices.

L'IA n'est pas la coupable : elle n'a fait qu'accélérer l'inévitable.