BaseRock AI

Qu’est-ce que BaseRock AI ?

BaseRock AI est une plateforme de QA agente destinée aux équipes de développement, de test et d’ingénierie qualité. Elle peut lire le code source, les exigences du produit, les tickets Jira et la documentation des interfaces, détecter automatiquement les points de terminaison serveur et générer des cas de test exécutables ainsi que des Playbooks.

L’accent actuel de la plateforme est mis sur le Business Use Case Testing, abrégé en BUCT. Il ne s’agit pas seulement de déterminer si l’interface renvoie un état de succès, mais aussi de vérifier que les processus inter-services tels que l’enregistrement, les commandes, les paiements, les stocks, les factures et les notifications produisent réellement les résultats commerciaux escomptés.

À quels types d’équipes BaseRock convient-il ?

• Équipe de développement backend : découverte automatique des interfaces à partir du code et génération de tests d’intégration.
• Équipe d’automatisation QA : réduire le travail de rédaction et de maintenance des scripts de test.
• Équipe de microservices : Valider les processus métier bout en bout à travers plusieurs services.
• Équipe de programmation en IA : mettre en place des garde-fous de qualité pour la génération et la modification rapide du code.
• Équipe d’ingénierie de plateforme : intégrer les ensembles de tests dans les processus CI/CD et de déploiement.
• Équipe financière et e-commerce : protéger en priorité les flux de paiement, de commandes et de revenus.
• Entreprises soumises à des exigences de conformité élevées : exécuter dans un environnement privé et conserver les résultats d’audit.
• Équipes disposant de systèmes hérités : étendre la couverture sans réécrire l’ensemble du cadre de tests.

Fonction principale

• Découverte de code : Scanner la bibliothèque de code pour identifier les points d’entrée API, les schémas et les dépendances.
• Génération de tests d’intégration : création automatique de cas d’utilisation à partir du code du service, des documents explicatifs et des indications.
• Test des cas d’utilisation métier : extraction des processus métier et des résultats attendus à partir du PRD ou du BRD.
• Génération de playbook : conversion des intentions de test en langage naturel en étapes exécutables.
• Exécution par l’agent local : exécution des tests sur la machine du client, dans une VPC ou sur un nœud de travail.
• Orchestration inter-services : appeler plusieurs microservices dans l’ordre métier et valider le résultat global.
• Maintenance des tests : ajustement automatique des tests en cas de modification du code ou des exigences.
• Vérification manuelle : Voir et modifier les actions spécifiques générées par l’IA avant leur exécution.
• Intégration CI/CD : exécuter des ensembles de tests par smoke testing, tests de régression, étiquetage ou points d’entrée.
• Rapport centralisé : visualiser les résultats aux niveaux des cas d’utilisation et des processus métier.

Qu’est-ce que le testing des cas d’utilisation métier ?

Les tests traditionnels vérifient souvent si une interface individuelle, des codes d’état et un schéma fonctionnent correctement, mais peuvent manquer les échecs logiques entre services. BUCT relie les exigences du produit à la mise en œuvre du code, en vérifiant en continu les résultats métier qui ont réellement un impact sur les clients, les revenus et la conformité.

Le flux de travail de BaseRock

Sources de données supportées

• Repos de code GitHub, GitLab et Bitbucket.
• Le code source sur la machine locale du développeur.
• PRD, BRD et règles de business en texte brut.
• Systèmes de gestion de demandes tels que Jira, Confluence, Notion, etc.
• Description de l’API, exemples de réponses aux requêtes et spécifications de l’interface.
• Les contextes externes tels qu’Atlassian et MongoDB fournis par le serveur MCP.
• Instructions en langage naturel saisies directement par le testeur.

Connexion du code au dépôt

• GitHub Cloud : lecture du code via l’autorisation OAuth.
• GitLab : prend en charge la connexion OAuth et les connexions de dépôts.
• Bitbucket Cloud : peut servir de source de code à distance.
• Bitbucket Data Center : la documentation est indiquée comme méthode de support.
• Code local : il est possible de créer des services sans se connecter à un dépôt distant.
• Une connexion OAuth initiale nécessite généralement l’approbation de l’administrateur du dépôt.
• La documentation officielle indique que les droits d’accès au code source distant sont en lecture seule.

Langages de programmation et architectures pris en charge

La documentation officielle indique qu’il est possible de se connecter à des bibliothèques de code en Java, Python, Go ou d’autres langages majeurs, l’accent étant mis sur la découverte d’interfaces via la routage, les contrôleurs et la structure des services. La plateforme convient également aux projets microservices et monolithiques.

Test d’interfaces et de protocoles

• REST : Génération de tests selon la méthode, l’URL, le corps de la requête et les règles de réponse.
• GraphQL : type de protocole pouvant servir de kit d’exécution d’agent.
• Kafka : peut être filtré et exécuté selon le protocole au sein du kit.
• Interface à plusieurs étapes : enregistrer les variables de réponse précédentes et les transmettre aux étapes suivantes.
• Authentification préalable : effectuer la connexion ou l’obtention d’un token avant le test officiel.
• Nettoyage postérieur : Supprimer les données générées ou restaurer l’environnement une fois le test terminé.
• Valeurs dynamiques : identifiants de traitement, timestamps et variables générées pendant l’exécution.

Comment commencer à utiliser BaseRock

1. Contactez les ventes de BaseRock pour demander un compte et des droits d’accès au plan de contrôle.
2. Choisissez le plan de contrôle SaaS ou une déploiement auto-hébergé d’entreprise.
3. Inviter les membres de l’équipe et définir les rôles du projet.
4. Configurer les clés de modèle pour OpenAI, Anthropic, Azure, Bedrock ou Vertex.
5. Se connecter au dépôt de code via OAuth, ou préparer le code local.
6. Ajouter le premier service et confirmer les endpoints trouvés.
7. Téléchargez selon les besoins les spécifications d’interface, le PRD ou le BRD pour ajouter du contexte métier.
8. Installez et lancez le BaseRock Agent, puis exécutez un petit nombre de cas d’usage dans l’environnement de test.
9. Après vérification des étapes de génération et des résultats, intégrer dans le processus CI/CD.

Clé de modèle massif intégrée

BaseRock adopte le modèle Bring Your Own LLM : les entreprises doivent fournir une clé API pour les services de modèles pris en charge. La plateforme utilise ces modèles pour comprendre le code, les exigences et le contexte métier, puis génère des cas de test et des Playbooks.

Comment se connecter au premier service

1. Cliquez sur « Ajouter un service » dans le plan de contrôle.
2. Sélectionnez le dépôt et la branche cible, ou utilisez le code source local.
3. Spécifier le chemin du code de module, la route ou le contrôleur pour un projet monolithique.
4. Vérifier les points d’extrémité détectés par le système et les dépendances inter-services.
5. Vous pouvez télécharger, si vous le souhaitez, des instructions d’interface au format TXT ou PDF d’une taille maximale de 10 MB.
6. Fournir des indications sur le domaine, ou laisser la plateforme générer automatiquement des tests à partir du code.
7. Ajouter des adresses d’environnement, des certifications, des variables de contexte et des règles de nettoyage des données.
8. Après la création du playbook, vérifier progressivement les actions spécifiques.

Génération de tests d’intégration

• Deduire les endpoints, les paramètres, ainsi que la structure des requêtes et des réponses à partir du code source.
• Identifier des règles supplémentaires et des exemples en combinant les documents de spécifications optionnels.
• Compléter les limites du service et les exigences de validation en fonction des indications du domaine.
• Générer des cas d’usage pour les chemins normaux, les conditions aux limites et les entrées incorrectes.
• Mettre en place des étapes d’authentification, de préparation et de nettoyage des données.
• Convertir un playbook en langage naturel en actions d’exécution déterministes.
• Voir les résultats de test pour une interface individuelle dans le rapport de niveau de service.

Processus de test des cas d’utilisation métier

1. Créez les processus métier à protéger dans la zone Business Flows.
2. Téléchargez des BRD, PRD ou règles métier au format TXT ou PDF.
3. Permettre à l’IA d’extraire des cas d’usage métier concrets à partir de documents.
4. Associer chaque cas d’usage aux services déjà intégrés.
5. Associer les cas d’utilisation métier aux tests d’interface et compléter par des étapes de validation.
6. Créer des playbooks métier couvrant les scénarios normaux, limites et négatifs.
7. Le processus complet est exécuté par un agent local à travers les services.
8. Voir les résultats respectivement depuis la vue Test Case et la vue Use Case.

Exemple de processus métier

Qu’est-ce que un playbook ?

Un Playbook est un programme de test structuré décrit en anglais, qui permet à l’IA de convertir les étapes en langage naturel en workflows exécutables. Un Playbook comprend généralement trois phases : la préparation, l’exécution et le nettoyage.

• Playbook de niveau de service : un ensemble de tests pour un service.
• Playbook au niveau des points d’extrémité : organisation de la validation autour d’une seule interface.
• Playbook de cas de test : exécution de scénarios normaux ou anormaux spécifiques.
• Playbook des processus métier : Vérification des résultats métier finaux à travers plusieurs services.
• Les états comprennent en cours de traitement, prêt et erreur.
• Il est possible de l’ajuster en langage naturel, ainsi que d’éditer directement les requêtes et la logique.

Vérification manuelle et éditable

• Vérifiez toutes les étapes de l’inférence de l’IA avant d’exécuter.
• Vérifier l’interface cible, les en-têtes de requête, la charge et les paramètres.
• Vérifier comment la variable de réponse est sauvegardée et transmise.
• Vérifier les codes d’état, le schéma et les assertions métier.
• Modifier le Playbook en langage naturel tout en maintenant la synchronisation de l’intention.
• Modifiez directement la charge et la logique sur l’interface du flux de travail si nécessaire.
• Un environnement à haut risque doit être mis en œuvre après approbation du personnel.

BaseRock Agent

Le BaseRock Agent s’exécute dans l’environnement du client et est chargé de relier le plan de contrôle, de recevoir les instructions de test et d’appeler les services réels. Il peut être déployé sur le poste du développeur, dans une VPC, sur un serveur physique ou sur des nœuds de travail CI spécialisés.

• Exécuter un seul cas de test depuis l’interface web.
• Exécuter un ensemble de tests depuis la ligne de commande.
• Démarrer les suites de tests de fumée et de régression depuis la pipeline CI/CD.
• Accéder aux services depuis du code local, sans avoir besoin de se connecter à un dépôt distant.
• Envoyer les journaux d’exécution et les résultats de échec vers le plan de contrôle.
• Laissez le flux de production et les données opérationnelles sensibles dans l’environnement du client.

Intégration CI/CD

• Exécuter les tests par nom de service et environnement cible.
• Spécifier l’adresse de base du service de test.
• Filtrer selon les protocoles REST, GraphQL ou Kafka.
• Exécuter par ID de cas de test, étiquette ou endpoint.
• Distinguer les scénarios normaux des scénarios négatifs.
• Combinez les ensembles de tests par version, méthode ou portée des retours.
• Utiliser l’échec comme porte d’entrée pour la fusion, la publication ou le déploiement.

Mode de déploiement

Tarification et méthodes d’achat

BaseRock ne propose pas de forfait mensuel fixe en public ; la page des prix officielle indique que les frais sont calculés en fonction du nombre de services testés, et des devis sont fournis selon que le service est fourni en mode SaaS ou auto-hébergé. Les entreprises doivent également assumer séparément les coûts liés aux grands modèles qu’elles mettent en place elles-mêmes, aux ressources cloud et à l’environnement de fonctionnement interne.

Il est nécessaire de confirmer avant l’achat

• Méthode de calcul du nombre de services testés et taille minimale du contrat.
• Différences de prix entre SaaS, self-hébergement et cloud privé.
• Responsabilités en matière de plan de contrôle, de mise à niveau des agents et de maintenance des connecteurs.
• Les frais de mise en œuvre du modèle sont-ils entièrement à la charge du client ?
• Tâches concurrentes, nombre d’utilisateurs, limites de stockage et de journalisation.
• Le pilote, la mise en œuvre, la formation et le soutien continu sont-ils inclus dans le devis ?
• Mode d’exportation des actifs de test, des Playbooks et des rapports après la fin du contrat.

Scénarios d’application typiques

• Test d’intégration des interfaces : génération automatique de scénarios normaux et d’erreurs à partir du code.
• Retour aux microservices : Vérification des contrats et de la collaboration après la mise à niveau de plusieurs services.
• Protection des flux de revenus : vérification continue des commandes, des paiements, des abonnements et des remboursements.
• Gouvernance du code généré par l’IA : génération rapide de tests pour un code en évolution constante.
• Déploiement du contrôle d’accès : exécution de tests de fumée et de suites critiques métier dans CI/CD.
• Conformité des exigences : Vérifier que le comportement du code est conforme au PRD et à Jira.
• Modernisation des tests hérités : remplacer une partie des scripts fragiles par des Playbooks en langage naturel.
• Audit de conformité : conserver les résultats des tests et les enregistrements de vérification des règles métier.

Avantages du produit

• Orientation vers les résultats commerciaux : on vérifie non seulement les interfaces, mais aussi les processus clients et les revenus.
• Découverte automatique du code : il n’est pas nécessaire de maintenir manuellement un document de spécifications complet au préalable.
• Orchestration inter-services : adapté aux microservices complexes et aux modules monolithiques.
• Playbook de langage naturel : abaisser la barrière à l’écriture de scripts de test.
• Modèles intégrés : Les entreprises peuvent utiliser les protocoles et clés de modèles cloud existants.
• Exécution locale : L’agent permet au trafic de rester dans le réseau du client.
• Déploiement flexible : options SaaS, auto-hébergé et environnement privé.
• Contrôle manuel : il est possible de vérifier et d’éditer les actions spécifiques avant leur exécution.
• Maintenance continue : adaptation automatique des tests en cas de modifications du code et des exigences.

Restrictions d'utilisation

• Pas de prix public : il faut contacter le service des ventes pour obtenir un devis en fonction du nombre de services.
• Compte à ouvrir : ce n’est pas actuellement un outil d’inscription automatique pour particuliers.
• Clé de modèle requise : Les coûts liés aux LLM et les conditions relatives aux données sont gérés séparément par l’entreprise.
• Première connexion complexe : nécessite des droits de stockage, un environnement, ainsi que la configuration de l’agent et des services.
• L’IA peut mal interpréter les affaires : la génération de cas d’utilisation et de playbooks doit encore être revue par des experts du domaine.
• Risque des données de test : une configuration incorrecte peut modifier les systèmes de test ou en production.
• Augmentation de la dépendance MCP : les besoins externes et les connexions aux sources de données nécessitent une gouvernance supplémentaire.
• La gestion propre comporte des coûts d’exploitation : les mises à niveau, la surveillance, les ressources et la sécurité font l’objet d’une répartition claire entre les deux parties.

Sécurité et frontières des données

La page officielle actuelle et les documents indiquent que BaseRock a atteint un niveau de conformité SOC 2 Type II, et offre chiffrage, autorisations par rôle, isolation de l’environnement du client ainsi que des journaux d’audit. La connexion au dépôt distant utilise des droits en lecture seule, tandis que l’agent local exécute les tests dans l’environnement du client.

• Utiliser des comptes OAuth de entrepôt et des comptes de service avec les minimums de privilèges.
• Traiter le code et les exigences sensibles dans une VPC ou un environnement local.
• Imposer des restrictions de conservation des données d’entreprise et de formation pour les modèles tiers.
• Restreindre les cibles réseau et l’environnement exécutable pour l’agent.
• Par défaut, les tests destructifs sont interdits dans l’environnement de production.
• Définir une période de conservation pour les données de test, les journaux et les rapports.
• Vérifier régulièrement les permissions des rôles, des entrepôts, du MCP et des clés de modèle.

Recommandations pour le déploiement de la sécurité

1. Vérifiez d’abord la plateforme dans un dépôt de tests indépendant et en environnement non productif.
2. Créer une connexion de code en lecture seule et un compte de test dédié pour BaseRock.
3. Liste des adresses réseau autorisées et permissions minimales du système pour l’agent.
4. Utiliser des données synthétiques pour éviter de copier des informations sensibles de clients réels.
5. Vérifier les actions d’écriture, de suppression, de paiement et de notification dans le Playbook.
6. Ajouter des approbations manuelles et des règles de protection de l’environnement pour les opérations dangereuses.
7. Rotation des entrepôts, des modèles et des identifiants MCP, ainsi que surveillance des accès anormaux.
8. Préparer les processus d’arrêt d’urgence, de rollback et de prise en main manuelle.

Précautions relatives à la vie privée

BaseRock gère les données relatives aux comptes, à l’utilisation et au diagnostic ; les projets d’entreprise comprennent également du code source, des exigences et des métadonnées de test. Lorsque des grands modèles tiers sont activés, les données relevant du cadre de la tâche peuvent être envoyées au fournisseur correspondant du modèle, le traitement étant déterminé par les accords d’entreprise et les configurations de déploiement.

GitHub et l’état open source

BaseRock a rendu publics sur GitHub des documents et des exemples d’applications en attente, mais le plan de contrôle d’Agentic QA, ainsi que l’Agent et le système de génération principal, ne sont pas qualifiés de logiciels libres. Le dépôt de documents public ne signifie pas que le code source du produit commercial est accessible, et il ne doit pas être confondu avec le projet de base de données Baserow.

API et capacités d’extension

BaseRock s’étend grâce aux connexions de entrepôt, aux serveurs MCP, aux fournisseurs de modèles, aux agents en ligne de commande et aux paramètres CI/CD. La documentation publique met l’accent sur l’intégration d’entreprise et le fonctionnement des agents, plutôt que sur une API SaaS de test universelle destinée aux développeurs tiers.

Informations de base

Indice de recommandation

L’indice de recommandation global est de 4,5 sur 5. BaseRock convient aux équipes de développement d’entreprises disposant d’interfaces complexes et de chaînes métier critiques, mais nécessite des ressources pour l’intégration, les modèles, l’environnement et la révision métier ; il n’est pas adapté aux projets personnels qui se contentent de tests unitaires simples.

Questions fréquentes

Que fait principalement BaseRock AI ?

Il génère, exécute et maintient des tests d’intégration ainsi que des tests de processus métier inter-services à partir du code et des exigences.

Que signifie BUCT ?

Il s’agit du Business Use Case Testing, qui vise à valider les résultats métier plutôt que de se concentrer uniquement sur l’état des interfaces.

Quelles langages de code sont pris en charge ?

Les autorités affirment leur soutien à Java, Python, Go et à d’autres langages majeurs.

Quels dépôts de code sont pris en charge ?

Prend en charge GitHub, GitLab, Bitbucket, et permet également une connexion depuis du code local.

Avez-vous besoin de votre propre clé de modèle ?

Nécessaire : BaseRock utilise les clés de grands modèles fournies par le client.

Est-ce que c’est compatible avec l’hébergement auto-géré ?

Soutien, il est également possible de choisir une mise en œuvre SaaS, dans le cloud privé ou via VPC.

Combien coûte BaseRock ?

Les devis sont personnalisés en fonction du nombre de services à tester et du mode de déploiement ; aucun forfait fixe n’est publié sur le site officiel.

Peut-on intégrer CI/CD ?

Oui, l’agent peut exécuter les suites par service, environnement, étiquette, protocole et catégorie de test.

BaseRock est-il open source ?

La plateforme principale n’est pas open source, GitHub ne met en ligne que des documents et des projets d’exemple.

Le code source sera-t-il modifié ?

La documentation officielle indique que la connexion au dépôt distant utilise des droits en lecture seule.

Est-il possible de tester l’environnement de production ?

Techniquement, l’adresse cible peut être configurée, mais il n’est pas recommandé d’exécuter des tests automatisés en environnement de production qui pourraient écrire ou supprimer des données.

Est-ce adapté aux projets personnels ?

C’est généralement plus adapté aux entreprises et aux équipes ; pour les projets personnels, on peut d’abord utiliser des outils de test plus légers.