Tester un SaaS B2B complexe : comment les agents de QA.tech gèrent les rôles, les autorisations et les parcours fondés sur les données

Les produits simples sont faciles à tester, et presque plus personne ne crée de produits simples aujourd’hui. Les plateformes SaaS B2B avec lesquelles nous travaillons chez QA.tech ont un profil commun : plusieurs rôles utilisateurs avec des autorisations différentes, des écrans dont la forme dépend entièrement des données qui les alimentent, des workflows qui s’étendent sur une douzaine d’étapes et plusieurs dépendances, et de plus en plus de fonctionnalités qui couvrent le web, l’API et le mobile au sein d’un même parcours utilisateur.

C’est précisément le domaine où l’automatisation des tests par scripts coûte le plus cher et couvre le moins de cas. Chaque rôle multiplie les parcours. Chaque état de données les multiplie à nouveau. Une suite de tests qui couvrirait honnêtement toutes les combinaisons serait plus volumineuse que le produit lui-même – en pratique, les équipes automatisent donc les parcours nominaux, vérifient manuellement le reste par sondage et acceptent cette lacune.

Cet article explique en détail comment les agents de QA.tech gèrent différemment chacune de ces dimensions de la complexité, à partir de l’intégration d’équipes dans les domaines de la fintech, des technologies RH, des infrastructures de commerce électronique et de la santé – des produits pour lesquels « il suffit d’enregistrer le parcours » n’a jamais pu fonctionner.

Le bon modèle mental : vous intégrez un nouveau collègue

L’idée qui permet de comprendre tout ce qui suit vient en réalité d’un client. En regardant l’agent explorer sa plateforme pour la première fois, un responsable QA a demandé : « Il agit donc comme un nouveau venu dans l’entreprise ? » C’est exactement cela. L’agent rejoint votre équipe comme le ferait un nouveau testeur QA compétent – il explore le produit, construit un modèle mental, pose des questions lorsqu’il rencontre quelque chose d’ambigu et reçoit occasionnellement des corrections au cours de ses premières semaines. La différence se situe dans ce qui suit : la compréhension qu’il construit devient un graphe de connaissances persistant, il n’oublie jamais une correction et applique chaque élément de contexte à tous les tests futurs.

Ce modèle mental est important, car c’est précisément avec les produits complexes que la période de « nouveau venu » porte ses fruits. Un script connaît un parcours dans votre produit. Un agent entraîné connaît votre produit.

Rôles et autorisations : enseignez-lui toute la carte, puis donnez-lui n’importe quelle clé

Les systèmes d’autorisations sont le domaine où les suites basées sur des scripts abandonnent discrètement. Si votre plateforme comporte des rôles d’administrateur, de responsable et de membre – ou cinquante configurations de rôles propres à chaque client –, une approche fondée sur les scripts nécessite une couverture distincte et rédigée pour chaque rôle, et devient obsolète dès que les autorisations changent.

L’approche agentique inverse cette logique. Tout d’abord, l’agent explore votre produit avec un compte administrateur, de sorte que son graphe de connaissances couvre toute la surface : chaque écran, chaque action, chaque parcours existant. Ensuite, vous lui fournissez des comptes restreints. En se connectant comme membre, l’agent voit moins d’options – et parce qu’il connaît la carte complète, il comprend ce qui manque et pourquoi, au lieu d’être désorienté par une interface plus limitée.

À partir de là, le permission testing devient une conversation. Dites à l’agent : « En tant que cette catégorie d’utilisateur, vous ne devez voir que X, Y et Z », et il vérifie la limite. Et voici le détail que les équipes apprécient particulièrement : lorsqu’un utilisateur restreint ne peut réellement pas accéder à un écran, l’agent enregistre un succès – la preuve que le système d’autorisations fonctionne comme prévu. Vous confirmez cette attente une fois, l’agent l’encode, et toute une catégorie de vérifications liées à la sécurité s’exécute en continu sans que personne n’ait besoin de la programmer.

Parcours pilotés par les données : même objectif, données différentes, aucune nouvelle rédaction

Dans les logiciels SaaS riches en données, le parcours est rarement la partie difficile – ce sont les permutations qui le sont. Créer un enregistrement constitue un test ; le créer avec cinquante profils de données différents, dont certains doivent réussir et d’autres être rejetés, est le point où les tests manuels s’enlisent et où les scripts se transforment en matrices de paramètres impossibles à maintenir.

Comme l’agent fonctionne à partir d’objectifs plutôt qu’à partir d’étapes enregistrées, la variation des données ne nécessite qu’une seule instruction : « Exécute à nouveau ce cas de test avec ces données. » Les connaissances du parcours sont conservées ; seules les entrées changent. Les cas négatifs fonctionnent de la même manière : décrivez ce qui doit être rejeté et l’agent vérifie que le produit refuse lorsque c’est nécessaire. Pour les champs de texte libre dont tout produit complexe regorge, l’agent s’appuie sur le contexte du produit que vous lui avez fourni pour saisir des valeurs pertinentes et, lorsqu’il se trompe, vous corrigez sa compréhension une seule fois au lieu de modifier un script.

Flux de travail longs : l’agent connaît déjà les prérequis

Les workflows des logiciels SaaS d’entreprise comportent des chaînes de dépendances – vous ne pouvez pas modifier une opportunité tant qu’elle n’existe pas, ne pouvez pas approuver une demande tant que quelqu’un n’en a pas soumis une, ni tester la dixième étape sans avoir effectué les neuf premières. Dans les suites de tests basées sur des scripts, cela devient du code de préparation : des fixtures, des jeux de données initiaux et des scripts auxiliaires qui constituent eux-mêmes une charge de maintenance.

L’agent gère les chaînes comme le ferait une personne : en se souvenant. Une fois qu’il a terminé un flux, tout ce qui suit s’appuie sur ces connaissances. Demandez-lui de tester des sous-allocations sur une transaction, et il sait que la création de la transaction vient en premier – parce qu’il l’a déjà fait, et que le parcours figure dans son graphe de connaissances. Les flux préalables, comme la connexion, sont configurés une seule fois et réutilisés partout. Plus vos flux de travail sont complexes, plus cet effet cumulatif est important, car chaque étape que l’agent connaît déjà est une étape que personne n’a besoin de recréer dans un script.

Parcours multisurfaces : web, API et mobile dans un seul test

Les parcours réels des utilisateurs dans les solutions SaaS modernes ne respectent pas les limites des outils de test. Un utilisateur configure quelque chose sur le web, un webhook se déclenche, un enregistrement est mis à jour via l’API et une notification arrive dans l’application mobile. La plupart des équipes testent chaque surface dans un outil distinct, avec des scripts distincts, en espérant que les jonctions tiennent.

QA.tech exécute ces scénarios sous la forme de tests de bout en bout uniques : un flux peut commencer dans le produit web, inclure des étapes de test d’API au milieu et se terminer dans l’application iOS ou Android native, en vérifiant le parcours tel que votre client le vit réellement. Pour les plateformes où les jonctions entre les surfaces sont précisément l’endroit où se cachent les bugs – paiements, notifications, synchronisation –, cela comble une lacune que les outils propres à chaque surface ne peuvent structurellement pas résoudre.

Ce que cela représente au total

Le schéma observé dans les équipes qui travaillent sur des produits complexes est constant. Les premières semaines sont collaboratives – l’agent explore, pose des questions et est corrigé, tandis que votre équipe apprend à lui donner des consignes. Puis les questions diminuent, et l’effort de test se découple de la complexité du produit : les nouveaux rôles, les nouveaux états de données et les nouvelles étapes de flux sont intégrés au graphe de connaissances au lieu de générer de nouveaux travaux de script.

Le résultat se mesure en heures. Pricer, une entreprise de technologie de la vente au détail, dont la plateforme est précisément ce type de produit complexe et riche en données, a mesuré 390 heures d’assurance qualité économisées par trimestre après avoir transféré la vérification à des agents QA – une capacité réinvestie dans la mise en production plutôt que dans la maintenance de l’infrastructure de test.

Les responsables de l’ingénierie mentionnent également un avantage plus discret : l’exploration de l’agent fait apparaître des combinaisons que personne n’avait pensé à tester. Lorsque votre couverture provient d’un système qui a cartographié l’ensemble du produit plutôt que d’un carnet de tickets de test, « y avez-vous pensé ? » devient une question que la plateforme vous pose.

FAQ

Les agents de QA.tech peuvent-ils tester le contrôle d’accès basé sur les rôles dans une solution SaaS B2B ?

Oui. L’agent cartographie l’application complète depuis un compte administrateur, puis effectue les tests comme n’importe quel utilisateur restreint, en vérifiant que chaque rôle voit exactement ce qu’il doit voir. Les blocages d’autorisation attendus sont encodés comme des résultats réussis.

Comment les agents de QA.tech gèrent-ils les scénarios de test pilotés par les données ?

Le même cas de test s’exécute avec des données différentes sur instruction – “exécute à nouveau ceci avec ces données” – sans devoir recréer le script. Les cas positifs et négatifs sont tous deux dérivés de l’objectif que vous décrivez.

QA.tech prend-il en charge les tests web, API et mobile dans un seul flux ?

Oui. Un seul test QA.tech peut combiner des étapes web, des étapes de test d’API et des étapes natives iOS ou Android, en vérifiant les parcours multisurfaces de bout en bout.

Combien de temps faut-il à QA.tech pour apprendre un produit SaaS complexe ?

L’exploration initiale prend quelques minutes ; une compréhension bien formée des rôles, des données et des flux de travail s’acquiert généralement en quelques semaines d’utilisation normale, les questions de l’agent diminuant à mesure que son graphe de connaissances se complète.

---

Votre produit met-il les outils de test en difficulté ? Orientez les agents de QA.tech vers votre environnement de préproduction – ils ont été conçus pour les situations complexes.