Découvrez GoogleTest certifié TÜV avec Agentic AI pour les tests C/C++ !
Plus de détails »
Aller à la section
Blog Parasoft
Découvrez notre série sur l'alignement de la vérification avec le développement axé sur l'IA. La première partie examine comment la simulation autonome d'API et la virtualisation de services permettent de gérer les dépendances indisponibles. La deuxième partie explore la vérification Java automatisée . Dans cette troisième partie, nous intégrons les exigences, les tests d'API et la virtualisation de services avec état dans un flux de travail de vérification automatisée unique.
Aller à la section
Une exigence est saisie dans Jira le lundi. Dès le mardi, un agent de codage IA l'a transformée en une API fonctionnelle.
Impressionnant, jusqu'à ce que quelqu'un pose la question délicate mais nécessaire : comment savons-nous que cela fonctionne réellement ?
Générer l'API n'est que le début.
Avant de pouvoir considérer l'API comme vérifiée avec certitude, l'équipe de test doit déterminer :
C'est un travail considérable qui se cache derrière un simple mot : vérification.
Avec l'accélération du développement logiciel par l'IA, il devient de plus en plus difficile de demander aux testeurs de coordonner chacune de ces activités de test à grande échelle. Générer un cas de test isolé peut certes faire gagner du temps, mais ne résout pas le problème global du flux de travail.
La plus grande opportunité réside dans les tests d'API automatisés : donner aux agents d'IA l'accès à des capacités de test spécialisées pour transformer l'intention de développement en vérification exécutable.
L'agent peut coordonner le flux de travail et activer des fonctionnalités de test spécialisées pour créer des tests d'API exécutables et des services virtuels. Les fonctionnalités de test établies et la supervision humaine garantissent la cohérence et la gouvernance nécessaires pour assurer la fiabilité des résultats.
Les exigences constituent un point de départ logique pour les tests, car elles décrivent ce que le logiciel est censé faire. Une user story Jira, un ensemble de critères d'acceptation, une définition d'API ou un recueil d'exemples de messages peuvent décrire les entrées attendues, les règles métier, les conditions de succès, la gestion des erreurs, les séquences d'interaction et les dépendances de service.
Les tests d'API à partir des exigences nécessitent toujours de traduire l'intention documentée en tests exécutables.
Avant de créer des tests exécutables, l'équipe doit encore traduire cette intention en un plan de vérification.
Cette étape de planification permet aux équipes de mettre à profit leur expertise en matière de tests et de domaine avant même que l'IA ne commence à générer les ressources de test. Face à l'accélération du rythme des modifications d'API induites par le développement axé sur l'IA, les équipes ont besoin d'un moyen plus rapide de passer d'une intention documentée à un plan de vérification clair et à des tests exécutables.
Les agents d'IA accélèrent ce processus en utilisant le contexte approuvé disponible, comme les exigences, les critères d'acceptation, les définitions de service et les ressources de test existantes, pour proposer un plan de vérification. Une fois l'intention suffisamment établie, ils activent des capacités de test spécialisées afin de créer des ressources de test d'API exécutables.
Il existe cependant une limite importante : l’IA ne peut retrouver que les intentions métier documentées. Par conséquent, des exigences claires et un jugement humain éclairé demeurent essentiels à l’élaboration d’un plan de vérification fiable.
Les équipes peuvent également intégrer au flux de travail des compétences permettant de repérer les informations manquantes ou contradictoires et de les acheminer vers un service de clarification plutôt que de laisser l'agent combler les lacunes.
La génération de tests assistée par l'IA et les tests d'API automatisés sont liés, mais ne sont pas identiques.
Pour atteindre cet objectif, l'agent pourrait avoir besoin de faire ce qui suit.
Le changement majeur ne réside pas dans le fait que l'IA générative prenne en charge l'intégralité des tests, mais plutôt dans la possibilité, offerte par MCP aux outils de test d'entreprise, d'exploiter des fonctionnalités spécialisées permettant aux agents d'IA de les intégrer à leur flux de travail.
Les compétences fournissent des instructions spécifiques aux tests, aidant les agents à déterminer comment et quand utiliser ces fonctionnalités : de la création de tests et d’assertions à la génération de données de test, en passant par la simulation des dépendances et l’analyse des résultats. L’agent peut ensuite coordonner ces fonctionnalités dédiées tout au long du flux de travail de vérification, tout en créant des ressources de test persistantes et exécutables.
Cela transforme l'IA, d'un outil de génération basé sur des invites dans une interface de chat, en un flux de travail intelligent et orchestré capable de coordonner les activités de test et d'aider la vérification à suivre le rythme des changements accélérés par l'IA.
À quoi cela ressemble-t-il en pratique?
Il n'existe pas de flux de travail unique et prédéfini pour les tests automatisés. Les équipes décident de la place de l'IA, des fonctionnalités de test accessibles aux agents, des actions autorisées et des cas où une vérification ou une approbation humaine est requise.
L'intervention humaine dans le processus ne signifie pas exiger une approbation humaine à chaque étape. Les équipes peuvent intégrer des points de contrôle de validation au flux de travail en fonction de leurs politiques de gouvernance et de leur niveau de confiance dans l'automatisation. Dans ce cadre, l'agent passe de manière autonome d'une activité de test à l'autre.
Prenons l'exemple d'un flux de travail possible.
Une équipe développe une nouvelle API documentée dans Jira, qui dépend d'un service en aval encore en développement. L'organisation a mis en place un flux de travail automatisé pour faciliter la vérification.
Il offre à l'agent un accès aux exigences approuvées, aux capacités de test d'API via Parasoft SOAtest et à la virtualisation de services via Parasoft Virtualize, tout en maintenant les points de contrôle définis sous contrôle humain.
Le processus débute par un objectif de vérification, et non par une longue séquence d'instructions de test manuel. Selon la configuration du processus au sein de l'organisation, un agent d'IA peut récupérer une user story Jira, des critères d'acceptation, une définition d'API et d'autres éléments de contexte auxquels il est autorisé à accéder.
À partir de ces sources, l'agent peut identifier les opérations attendues, les entrées, les règles métier, les conditions de succès et les comportements en cas d'erreur. Il examine également les ressources de test existantes afin d'identifier des scénarios réutilisables. Lorsqu'il ne dispose pas de suffisamment d'informations pour poursuivre son analyse avec assurance, il signale les données manquantes ou ambiguës.
Cela réduit le temps que les testeurs passent à collecter des informations provenant de différents systèmes et à traduire manuellement les exigences en tâches de test, permettant ainsi de commencer la vérification dès que le contexte nécessaire est disponible.
Comprendre les exigences n'est que le point de départ. Il reste à déterminer ce qui doit être testé.
Traditionnellement, cela nécessite un testeur possédant suffisamment de connaissances du domaine et de l'API pour traduire les critères d'acceptation en scénarios positifs et négatifs, conditions limites, cas d'erreur et flux de travail métier en plusieurs étapes.
En s'appuyant sur ses compétences et le contexte approuvé à sa disposition, l'agent peut proposer un plan de test initial et identifier les scénarios nécessaires à la vérification de l'exigence. Le testeur examine ce plan initial, demande à l'agent d'affiner ou d'étoffer les scénarios, comble les lacunes et poursuit ce processus d'échanges jusqu'à ce que le plan reflète fidèlement ce qui doit être vérifié.
Une fois le plan approuvé par le testeur, l'agent peut guider les activités de test suivantes. Au lieu de partir de zéro et de déterminer manuellement chaque chemin de test, le testeur commence avec un plan généré par l'IA, revu et optimisé avant que le flux de travail ne passe à la création des tests exécutables.
C’est là que les équipes peuvent réduire considérablement le travail manuel.
La création d'un test d'API nécessite généralement soit d'écrire du code de test, soit de configurer le test via une plateforme de test sans code. Dans les deux cas, pour tester le scénario métier, le testeur doit comprendre et déterminer comment les différentes opérations de l'API doivent interagir pour le représenter.
À partir de là, le testeur doit encore consacrer du temps à configurer les requêtes et les charges utiles individuelles, l'authentification et les en-têtes, les sources de données, les assertions et autres détails nécessaires pour rendre le scénario exécutable et déterminer si l'API se comporte correctement.
Pour les flux de travail métier à plusieurs étapes, cela peut signifier extraire des valeurs d'une réponse et les transmettre aux requêtes suivantes, maintenir les informations entre les interactions, séquencer correctement les opérations ou ajouter une logique personnalisée pour connecter les appels d'API individuels dans un flux de travail métier de bout en bout.
Les assertions de test d'API peuvent également nécessiter la validation des codes d'état, des valeurs de charge utile, des en-têtes, des réponses d'erreur, des règles métier, des relations entre les messages et des changements d'état attendus lors des interactions. Cela prend du temps et exige souvent une connaissance approfondie des API, des tests et du domaine.
Une fois le plan de vérification approuvé, l'agent peut utiliser les fonctionnalités de test d'API de Parasoft SOAtest via MCP pour créer et configurer des tests exécutables. À l'aide de ce plan, des exigences, des définitions d'API et des autres éléments de contexte approuvés disponibles pour le flux de travail, l'agent peut traduire les scénarios métier définis en ressources de test SOAtest fonctionnelles.
Au lieu de concevoir manuellement chaque étape de test, les équipes passent beaucoup plus rapidement d'un plan de vérification approuvé à un scénario de test d'API exécutable et réutilisable. L'avantage ne se limite pas à une génération de tests plus rapide. Il réduit la configuration manuelle et l'expertise technique nécessaires pour traduire les éléments à vérifier — et la manière dont les opérations de l'API doivent interagir pour y parvenir — en un scénario de test fonctionnel.
Les scénarios de test d'API nécessitent des données représentatives des conditions testées. Il peut être nécessaire de demander, de provisionner, de masquer ou de nettoyer les données issues de la production, tandis que les conditions négatives, les valeurs limites et les scénarios métier inhabituels peuvent exiger des équipes qu'elles définissent et créent des données spécifiques qui n'existent pas déjà.
Dans un flux de travail automatisé, l'agent peut utiliser le scénario de test et le contexte disponible pour générer les données requises à la demande. Cela réduit le travail manuel de préparation des données pour chaque scénario, tout en respectant les politiques de gouvernance et de confidentialité des données en vigueur au sein de l'organisation.
Les tests, les assertions et les données sont peut-être prêts, mais un service en aval requis ne l'est pas encore.
Il se peut qu'une autre équipe soit encore en train de le développer. Le service est peut-être instable, coûteux d'accès, contrôlé par un tiers ou difficile à configurer avec l'état et les données requis par le scénario.
Traditionnellement, cela peut interrompre les tests. Il peut être nécessaire d'attendre la disponibilité de la dépendance, de se coordonner avec une autre équipe, ou de changer d'outil et de construire manuellement une simulation avant que les tests puissent reprendre.
Dans un flux de travail automatisé utilisant SOAtest et Virtualize, une compétence guide l'agent pour identifier les dépendances indisponibles bloquant un test et déterminer la nécessité d'un service virtuel. À partir des exigences de test, de la définition du service, d'exemples de messages ou d'autres contextes approuvés, l'agent peut invoquer Virtualize via MCP afin de créer et de déployer la simulation requise et de débloquer les tests.
Au lieu d'une nouvelle phase d'attente ou d'un transfert manuel, le flux de travail passe de la reconnaissance de la dépendance à la création des éléments nécessaires pour que les tests puissent se poursuivre.
Pour une interaction simple, renvoyer une réponse prédéfinie peut suffire. Cependant, les flux de travail métier réels nécessitent souvent davantage.
Un service en aval peut avoir besoin de renvoyer des réponses différentes selon l'ordre des interactions précédentes. Une commande peut passer de l'état « soumise » à « approuvée », puis à « expédiée ». Un solde peut évoluer après un paiement. Une ressource créée par une requête peut devoir être renvoyée par une autre.
La mise en place manuelle de ces comportements peut s'avérer très chronophage et nécessiter une expertise pointue en virtualisation de services. Il est indispensable de comprendre les dépendances, de configurer les réponses, de modéliser les transitions d'état et les relations entre les données, et de s'assurer que la simulation reproduit le comportement attendu par le test.
Grâce au serveur MCP de Parasoft Virtualize , l'agent peut exploiter les fonctionnalités de virtualisation de services pour générer la ressource virtuelle avec état nécessaire au scénario de test. L'agent disposant déjà du contexte relatif à l'objectif de vérification et au scénario de test, la création des tests et la simulation des dépendances deviennent des activités intégrées, et non plus des projets distincts nécessitant des transferts de responsabilité.
C’est ici que les tests d’API et la virtualisation de services deviennent des éléments interdépendants d’un même flux de travail de vérification automatisée. Lorsqu’un test requiert un comportement que l’environnement ne peut fournir, le flux de travail peut passer de la création du test à la simulation des dépendances sans autre intervention manuelle.
Cela réduit considérablement la barrière technique à la virtualisation de services sophistiquée, tout en diminuant le temps que les équipes passent à attendre les dépendances ou à configurer manuellement le comportement nécessaire pour poursuivre les tests.
Une fois le test, les données, les assertions et les dépendances virtuelles requises disponibles, l'agent peut invoquer SOAtest pour exécuter le scénario. SOAtest exécute le test et produit des résultats basés sur les requêtes, les validations, les données et le comportement simulé configurés.
Le flux de travail ne doit pas nécessairement s'arrêter à la réussite ou à l'échec. Les équipes peuvent configurer leur flux de travail automatisé pour qu'il se poursuive en fonction des résultats, en utilisant des compétences pour guider les actions suivantes et des serveurs MCP pour connecter l'agent aux outils nécessaires à la mise en œuvre.
Selon la conception de ce flux de travail, l'agent peut recueillir des informations contextuelles supplémentaires, résoudre un problème de configuration de test, signaler un défaut d'implémentation probable ou transmettre les résultats à un autre système ou à une autre personne.
L'organisation détermine le degré d'autonomie du processus. Les équipes définissent les autorisations, les garde-fous et les points de contrôle par vérification humaine en fonction de leurs politiques qualité, de leur tolérance au risque et de leur niveau de confiance dans l'automatisation. L'intervention humaine ne signifie pas nécessairement une intervention humaine à chaque étape.
L'objectif n'est pas de supprimer la vérification des API pour les testeurs, mais d'éliminer les configurations répétitives, les temps d'attente, les transferts de responsabilité et les obstacles techniques qui leur font perdre du temps.
Le processus débute par une intention définie par l'humain et se termine par une vérification. Ce qui change, c'est la rapidité avec laquelle l'équipe peut passer de l'une à l'autre et la manière dont le travail intermédiaire peut être orchestré intelligemment grâce aux outils de test d'entreprise qu'elle utilise déjà.
Il n'existe pas de modèle unique pour les tests d'API automatisés. Parasoft propose des fonctionnalités de test que les agents peuvent activer via MCP. Les équipes déterminent comment ces fonctionnalités s'intègrent au flux de travail automatisé global. Elles choisissent les compétences, intégrations, autorisations, séquencements et points de contrôle humains, fournis ou personnalisés, les plus adaptés à leur processus de développement et à leur niveau de risque.
Cela signifie que pour démarrer, il n'est pas nécessaire de mettre en place un flux de travail autonome à l'échelle de l'entreprise. Commencez par un cas d'utilisation précis et reproductible, et répondez à quelques questions pratiques.
Les équipes peuvent optimiser leurs processus à mesure qu'elles gagnent en confiance dans les ressources, les résultats et le modèle de gouvernance. L'objectif n'est pas une autonomie maximale, mais une autonomie appliquée là où elle allège la charge de travail sans compromettre la confiance.
Partie 1 : Comment la simulation d’API autonome comble le fossé
Partie 2 : Maintenir la vérification Java au même rythme que le code généré par l’IA
Partie 3 : Des exigences à la vérification fiable des API grâce à l’IA agentique
Vous êtes en train de lire cet article.
Découvrez comment votre équipe peut connecter les exigences, les tests d'API et la virtualisation des services avec état dans un flux de travail de vérification automatisée.
