Bugster

Une phrase pour présenter

Bugster est une plateforme de test AI bout en bout destinée aux applications web, permettant aux utilisateurs de décrire les processus en langage naturel ou à l’aide de spécifications de test structurées, puis aux agents d’exécuter des actions dans le navigateur, d’évaluer les résultats et de générer des preuves.

Il offre en même temps une console web, des outils en ligne de commande, l’application GitHub et des capacités d’intégration continue, ce qui le rend adapté pour relier l’acceptation du produit, les tests de régression et les tests automatisés après déploiement.

Qu’est-ce que Bugster ?

Bugster est fourni par Bugster Inc. et est conçu comme un agent de QA autonome destiné aux équipes d’ingénierie, et non comme un générateur de code universel. Les services de la plateforme sont principalement basés sur le SaaS cloud, et les cibles de test peuvent être un environnement de développement local, un environnement de prévisualisation, un environnement de test ou un environnement de production accessible.

Les développeurs peuvent gérer les tests YAML dans le dépôt de code, tandis que les équipes QA et produit peuvent décrire les flux d’utilisateurs en langage courant depuis l’interface web. Ces deux approches partagent les projets, les suites de tests et les résultats d’exécution, ce qui facilite la collaboration entre différents rôles autour des mêmes normes de qualité.

Fonction principale

Tests de création en langage naturel

L’interface web permet aux utilisateurs de décrire directement les processus tels que l’inscription, la connexion, l’achat ou la soumission de formulaires ; l’agent convertit ensuite ces exigences en tests bout en bout exécutables. Les utilisateurs peuvent également indiquer clairement les étapes et les résultats attendus, afin de réduire les ambiguïtés liées à une exploration libre.

Exécution dans un navigateur réel

En exécutant la commande, on peut consulter les spécifications de test du projet, lancer une instance du navigateur et faire en sorte que l’agent IA effectue les opérations sur la page étape par étape. Les moteurs de navigateur listés dans la documentation de la ligne de commande actuelle incluent Chromium, Firefox et WebKit ; Chromium est utilisé par défaut.

Preuves d’échec et rapports

Une fois le test terminé, un statut de réussite ou d’échec, un journal des étapes, des captures d’écran et des informations sur les résultats sont fournis. Pour les tests échoués, une vidéo est également enregistrée automatiquement. Les résultats peuvent être transmis en temps réel à la console web, ou être sauvegardés au format JSON pour être traités par des systèmes d’intégration continue ou d’autres outils.

Tester la synchronisation et la collaboration

Les développeurs peuvent télécharger les tests côté navigateur sous forme de YAML lisible par l’homme, les modifier dans Cursor, Claude Code ou un éditeur ordinaire, puis les renvoyer sur la plateforme. Les tests peuvent également être organisés en suites par fonction et synchronisés entre branches, environnements et membres d’équipe.

Tests de détection d’impact et mises à jour automatiques

Bugster permet de ne lancer que les tests liés aux modifications du code, et offre également un flux de travail pour mettre à jour les spécifications des tests. Cette fonctionnalité permet de réduire le temps nécessaire au lancement de l’ensemble des tests à chaque soumission, mais les tests de régression fixes doivent être conservés dans les processus clés afin d’éviter que des défauts ne passent inaperçus en raison du jugement relatif aux modifications.

Test d’exploration d’agent destructeur

L’Agent Destructif est utilisé pour explorer les conditions limites et les opérations destructrices facilement négligées par les voies de succès conventionnelles, et convient mieux à la détection de comportements inattendus après des modifications fonctionnelles. Il diffère de l’utilisation des tests bout en bout sur les processus clés connus, et le quota d’exécution actuel doit être configuré selon le forfait de l’équipe.

• Décrire les flux d’utilisateurs, les étapes opérationnelles et les résultats attendus en langage naturel ou en YAML.
• Exécuter dans le navigateur des clics, des saisies, de la navigation, des connexions et des validations de page.
• Générer des vidéos, des captures d’écran, des journaux détaillés et des étapes de reproduction pour les tests échoués.
• Exécuter tous les tests depuis la ligne de commande, un répertoire spécifié, un fichier unique ou des tests prompts temporaires.
• Prend en charge l’exécution parallèle, le fonctionnement sans tête, la transmission fluide des résultats et la sortie JSON.
• Exécuter automatiquement des tests via l’application GitHub sur les demandes de pull et les prévisualisations de déploiement.
• Prend en charge l’exécution planifiée, les tests dans plusieurs environnements ainsi que la gestion des suites de tests d’équipe.
• Intégrer d’autres plateformes de déploiement au processus de déclenchement des tests via un Webhook personnalisé.

Spécifications de test et modes de configuration

Contenu de test YAML

Le fichier de test peut enregistrer le nom, la page cible, le chemin de la page, la tâche, les étapes et les résultats attendus ; les scénarios de connexion peuvent également faire référence à des identifiants préconfigurés. Un format structuré facilite l’examen du code, la gestion des versions et les modifications assistées par des agents de codage.

Configuration au niveau du projet

La configuration du projet peut définir des options telles que l’adresse de base, les identifiants, le nombre de tâches en parallèle, l’emplacement de sortie, le mode sans interface ainsi que la possibilité de ne lancer que les tests affectés. Les paramètres de ligne de commande écrasent les paramètres du même nom dans le fichier de configuration, ce qui permet aux environnements d’intégration continue de conserver des stratégies de exécution indépendantes.

Mot de passe sensible

Les noms d’utilisateur, les mots de passe et les tokens des différents rôles doivent être fournis via des variables d’environnement ou des clés de plateforme, puis les identifiants de connexion doivent être référencés dans les fichiers de test. Ne pas écrire directement les clés réelles dans le YAML ni les soumettre à un dépôt de code.

Processus de travail complet

1. Créer l’organisation et le projet Bugster, et déterminer les applications Web à tester ainsi que l’environnement cible.
2. Connectez-vous à un dépôt GitHub ou installez la CLI localement, puis terminez l’authentification de votre compte et l’initialisation du projet.
3. Générer des tests en langage naturel, ou décrire les étapes et les résultats attendus dans une page web et un fichier YAML.
4. Configurer des variables d’environnement pour le rôle de connexion, afin d’éviter d’enregistrer les identifiants et mots de passe dans le dépôt.
5. Exécutez d’abord un petit nombre de processus clés localement pour vérifier les opérations du proxy, les assertions, les captures d’écran et les enregistrements en cas d’échec.
6. Synchroniser les tests validés sur la plateforme et les regrouper en suites pour l’authentification, le règlement ou la gestion backend.
7. Intégrez les tests dans des requêtes de pull, des déploiements en prévisualisation ou des tâches planifiées, et ajustez les règles de parallélisme et de déclenchement en fonction des résultats.
8. Réviser régulièrement les faux positifs, les faux négatifs et les normes obsolètes afin que la validation manuelle et les tests par IA se complètent.

Guide d’introduction à la ligne de commande

1. Vérifiez que l’appareil fonctionne dans un environnement Windows, macOS ou Linux pris en charge, et assurez-vous d’avoir Node.js 18 ou une version ultérieure.
2. Installez la CLI officielle et exécutez la commande d’authentification pour obtenir votre clé API personnelle depuis la console.
3. Exécuter l’initialisation dans le répertoire du projet pour permettre à l’outil de créer la configuration du projet et les répertoires de test.
4. Exécuter la commande de génération pour créer les premières spécifications de test, puis vérifier manuellement les tâches, les étapes et les résultats attendus.
5. Exécutez tous les tests ou un fichier spécifié ; pour une première utilisation, il est recommandé de maintenir un faible nombre de parallélisme et d’afficher des journaux détaillés.
6. Activez le mode sans interface, la sortie JSON et la transmission en flux des résultats lorsque l’intégration continue est nécessaire.

Le dépôt CLI officiel fournit des fichiers d’installation pour Windows ainsi que des instructions d’installation multiplateforme. Les exécutables Windows peuvent être signalés par le logiciel de sécurité en l’absence de signature numérique d’un éditeur reconnu ; l’équipe doit d’abord vérifier la version officielle et la source du fichier, avant de décider, selon les procédures de sécurité internes, s’il convient de les autoriser.

Tutoriel de tests rapides et de débogage

1. D’abord, lancez l’application locale ou préparez une adresse de test accessible.
2. Écrivez une tâche de test concrète ne dépassant pas 1000 caractères en utilisant un paramètre d’indication temporaire.
3. Vérifier que l’agent accède à la bonne page, utilise le bon compte et effectue les actions prévues.
4. En cas d’échec, consultez le journal des étapes, les captures d’écran et les vidéos pour déterminer s’il s’agit d’un défaut du produit, d’un problème d’environnement ou d’une description de test floue.
5. Organiser les tests temporaires stables et nécessitant une exécution répétée en YAML, puis les ajouter au ensemble de tests officiel.

Le test de rappel rapide a une capacité de concurrence maximale de 1, ce qui le rend plus adapté à l’exploration et à la validation de processus courts. Les tests de régression formels doivent utiliser des fichiers de test gérables en version, et prévoir des résultats attendus lisible par un humain pour les assertions clés.

Se connecter à GitHub et CI/CD

L’application GitHub de Bugster peut se connecter à une organisation et à des répertoires spécifiques, et déclencher des tests une fois que le déploiement de prévisualisation correspondant à la demande de pull est prêt. Les résultats des tests, les explications des échecs ainsi que les preuves vidéo peuvent être intégrés au processus de collaboration en développement, afin d’aider l’équipe à vérifier les régressions avant la fusion.

1. Installez l’application Bugster GitHub dans les paramètres de l’organisation, et autorisez uniquement les dépôts qui doivent être testés.
2. Connecter le dépôt cible au projet Bugster et vérifier que la portée des autorisations du dépôt correspond à celle de l’application.
3. Configurer Vercel, Railway, Netlify ou une autre plateforme de déploiement pour que l’environnement de prévisualisation envoie des événements une fois terminé.
4. Soumettre les configurations de projet et les dossiers de test dans l’entrepôt, mais conserver les clés API et les identifiants d’accès dans une gestion des secrets.
5. Choisissez d’exécuter à chaque soumission ou à chaque demande de pull, et configurez les environnements de production, de prévisualisation ou les deux.
6. Créer une échec contrôlé pour vérifier que les flux de retour des demandes de pull, les enregistrements vidéo, les e-mails ou les notifications Slack sont opérationnels.

Le site officiel indique actuellement GitHub comme intégration de stockage de code disponible, tandis que GitLab et Bitbucket sont toujours marqués comme étant bientôt pris en charge. Les publicités pour GitLab affichées sur d’autres pages ne doivent pas être considérées comme une mise à disposition officielle ; il convient de se référer aux options réelles de la plateforme avant de l’utiliser.

API Webhook personnalisée

La documentation officielle fournit une interface Webhook intégrée pour le déploiement ; les pipelines tiers peuvent soumettre l’adresse du projet, de l’organisation et de l’environnement ainsi que des informations de soumission après un déploiement réussi, afin de déclencher les tests Bugster. Cette interface utilise une authentification par clé API et convient aux plateformes de déploiement ne disposant pas de connecteurs intégrés.

Il s’agit d’une API déclenchée pour les événements de déploiement, et n’est pas équivalente à un SDK public général couvrant la gestion des projets, des tests, des résultats et des comptes. Aucun SDK client multilingue complet officiellement publié n’a été identifié pour l’instant ; le champ d’application doit se baser sur la documentation des interfaces publiques.

Support des frameworks, navigateurs et plateformes

Le site officiel liste actuellement des frameworks front-end tels que Next.js, React, Svelte, Angular et Vue, mais la génération automatique à différents niveaux de profondeur n’est pas tout à fait identique entre ces frameworks. La documentation officielle classe Next.js comme un support amélioré, tandis que les autres frameworks conviennent mieux à une génération assistée par des règles d’édition et des proxies de codage ; l’exécution des tests peut néanmoins être effectuée sur des applications Web accessibles.

• Systèmes en ligne de commande : Windows, macOS et Linux.
• Exigences d’exécution : Node.js 18 ou une version ultérieure, ainsi que le navigateur requis pour Playwright.
• Moteur de navigateur : Chromium, Firefox et WebKit ; la disponibilité concrète dépend de l’environnement d’exécution.
• Frameworks frontend : le site officiel cite Next.js, React, Vue, Angular et Svelte.
• Plateformes de déploiement : Vercel, Railway, Netlify, GCP et processus de déploiement personnalisés.
• Collaboration sur le code : GitHub est actuellement l’intégration officielle, tandis que GitLab et Bitbucket restent dans la feuille de route.
• Points d’accès de développement : tableau de bord web, CLI, GitHub App et webhook de déploiement.

La page de marketing mentionne la compatibilité avec les navigateurs et appareils principaux, mais la documentation CLI précise trois moteurs de navigateur. Si le projet nécessite des téléphones réels, des versions spécifiques de système ou un laboratoire d’appareils physiques, il convient de confirmer cela avec l’équipe avant l’achat, et de ne pas assimiler directement une simulation WebKit à un appareil Safari réel.

À qui s’adresse-t-il

• Ingénieur QA : Transformer les processus d’utilisateurs clés en tests répétables, et vérifier les échecs à l’aide de vidéos et de journaux.
• Développeur front-end : Exécuter des tests de régression sur le environnement local, les branches et les déploiements en prévisualisation, afin de réduire les problèmes imprévus causés par les modifications de l’interface.
• Chef de produit : Définir le processus d’acceptation en langage simple, puis compléter avec le QA les étapes précises et les résultats attendus.
• Responsable du projet : Intégrer les demandes de récupération pour les tests d’accès, afin de visualiser de manière centralisée l’état d’exécution, les raisons des échecs et le coût des tests.
• Petite équipe d’entrepreneuriat : en l’absence d’une grande équipe de tests automatisés, couvrir d’abord l’inscription, la connexion, le paiement et les processus clés de conversion.
• Équipe d’ingénierie de plateforme : intégrer les tests dans la chaîne de déploiement existante à l’aide de Webhooks et d’intégration continue.

Scénarios d'utilisation typiques

• Test de connexion : Vérifier le comportement de la connexion, du menu des permissions et des pages non autorisées en utilisant différents rôles.
• Processus de commerce en ligne : Vérifier que la recherche, les détails des produits, le panier d’achat, les offres et la page de paiement sont cohérents.
• Vérification des formulaires : test des champs obligatoires, des entrées incorrectes, de la soumission réussie et des messages d’erreur.
• Validation de la demande de pull : après le déploiement dans l’environnement de prévisualisation, les tests concernés sont exécutés automatiquement et les preuves sont renvoyées.
• Retour nocturne : exécution programmée du kit de stabilité pour détecter à l’avance les changements de dépendances, d’environnement ou de processus à long terme.
• Test exploratoire : Laisser l’Agent destructeur essayer des opérations aux limites, puis faire confirmer par le QA les risques et les voies de répétition.
• Vérification multi-environnements : utilisation des mêmes normes pour vérifier les processus clés dans les environnements de développement, de test, d’aperçu et de production.

Avantages du produit

• La description du test peut servir à la fois les utilisateurs non techniques sur le site web et les développeurs dans le dépôt de code.
• La norme YAML est lisible, auditable et gérable en termes de versions, ce qui réduit le risque que la logique de test ne se trouve uniquement dans des plateformes noires.
• L’agent gère l’interaction avec le navigateur et enregistre des captures d’écran, des journaux et des vidéos des échecs, afin de faciliter le suivi, au-delà du simple retour d’une lumière rouge.
• L’application GitHub, la plateforme de déploiement et les Webhook intégrent les points de déclenchement des tests dans le processus de livraison existant.
• La version gratuite offre un quota mensuel clairement défini, idéal pour valider d’abord les scénarios clés et le niveau de faux positifs.
• La CLI officielle met à disposition le code source sous licence MIT, permettant aux équipes d’examiner la mise en œuvre et la publication de la partie ligne de commande.

Restrictions d'utilisation et précautions

• Les agents d’IA peuvent interpréter de manière erronée des objectifs flous ou considérer des retards de chargement de page comme des échecs ; les tests critiques nécessitent des étapes claires, des données stables et une vérification manuelle.
• Les cibles de test doivent être accessibles depuis l’environnement de exécution ; les services locaux, les prévisualisations protégées et les réseaux d’entreprise peuvent nécessiter une configuration supplémentaire.
• Starter exécute un maximum de 5 tests bout en bout par demande de pull, avec une limite de 3 en parallèle ; les suites complexes nécessitent une évaluation de la capacité payante.
• L’astuce rapide ne peut contenir que 1000 caractères et fonctionne en parallèle qu’à un niveau unique, ce qui la rend inadaptée comme méthode de sauvegarde unique pour de grands ensembles de tests de régression.
• Un niveau de parallélisme trop élevé peut exercer une pression sur les comptes de test, les bases de données partagées, les interfaces à débit limité ou les services tiers.
• Pour les processus destructeurs tels que les paiements réels, la suppression et l’envoi de messages, il convient d’utiliser des environnements isolés, des comptes de test et des données restaurables.
• Le rythme de mise à jour du site officiel, des documents et du README de GitHub diffère ; le support du framework ainsi que le nombre maximal d’instructions doivent se baser sur la documentation actuelle du produit et la console.
• Les résultats de l’automatisation ne peuvent pas remplacer un processus de qualité complet qui prenne en compte l’accessibilité, les performances, la sécurité, les règles métier et l’exploration manuelle.

Prix et forfaits

Au 20 août 2026, la section de tarification principale du site officiel propose la version gratuite Starter et la version d’équipe Team. Une autre page officielle indique que le prix de base de Team est de 99 dollars par équipe et par mois, tout en précisant que la capacité et les fonctionnalités supplémentaires peuvent être personnalisées ; par conséquent, le montant final doit faire l’objet d’une consultation avec le service des ventes ou en consultant la page de facturation.

Starter peut être utilisé gratuitement sans aucun frais, et le site officiel indique qu’aucune carte de crédit n’est requise. Cependant, le fait d’être gratuit ne signifie pas que toutes les fonctionnalités soient utilisables à l’infini. Team apparaît sur la page d’accueil sous la carte de prix principale comme « Contacter un commercial » ; 99 dollars correspond au tarif de base affiché sur la page officielle du service. Avant d’acheter, il convient de vérifier le montant réel, les frais supplémentaires et les SLA.

Confidentialité et sécurité des données

Les instructions de sécurité indiquent que le calcul et le stockage principaux de Bugster utilisent AWS, les services auxiliaires utilisent GCP, et OpenAI ainsi qu’Anthropic sont sollicités pour l’inference. La transmission s’effectue via TLS 1.2 ou 1.3, et le code client ainsi que les résultats des tests ne sont pas utilisés pour entraîner ou affiner les modèles.

La page d’accueil du site officiel souligne que les tests s’effectuent sur des environnements déployés sans accès au code source, tandis que la page de sécurité indique que le code source de GitHub peut être obtenu temporairement en temps de exécution avant d’être supprimé. Ces deux descriptions couvrent des domaines différents ; avant de se connecter à un répertoire privé, il convient de vérifier les droits d’autorisation, les chemins de traitement temporaires et les engagements contractuels en fonction des fonctionnalités réelles.

• Le code source n’est pas stocké de manière permanente dans la base de données de Bugster ; la page de sécurité indique qu’il est supprimé une fois l’accès en temps réel terminé.
• Les journaux, les captures d’écran et les vidéos sont stockés par défaut dans le stockage d’objets pendant 30 jours et peuvent être supprimés sur demande.
• La demande de suppression sera retirée du système en activité dans un délai de 24 heures et effacée des sauvegardes dans un délai de 30 jours.
• Les suggestions de modèle et les réponses restent limitées au cadre de la session, et les journaux d’observation sont anonymisés aux fins de débogage et de surveillance de la fiabilité.
• Selon la déclaration officielle, les codes clients et les produits de test ne seront pas utilisés pour l’entraînement ou le retouche des modèles.
• Bugster n’a pas encore obtenu la certification SOC 2 ; la certification du fournisseur de services cloud ne peut être assimilée à une certification du produit.
• La page de sécurité avait indiqué que BYOK faisait partie des fonctionnalités prévues ; il convient de se renseigner auprès des responsables pour savoir s’il est désormais officiellement mis en service.

Les tests comprennent souvent des comptes, des informations clients et des opérations commerciales ; l’organisation doit néanmoins appliquer le principe du minimum de privilèges, un renouvellement régulier des mots de passe, une isolation des données de test et un contrôle d’accès aux enregistrements vidéo. Lorsque des données médicales, financières ou autres soumises à réglementation sont concernées, il convient de vérifier avant la signature l’accord de traitement des données, la localisation, les sous-traitants et la suppression des preuves.

API, CLI et open source

Bugster propose une CLI qui nécessite une clé API de compte ainsi que des Webhooks de déploiement, ces derniers permettant aux pipelines personnalisés de soumettre des événements de succès de déploiement et de déclencher des tests. La documentation publique ne présente ni une API REST universelle couvrant l’ensemble des ressources des plateformes, ni un SDK officiel multilingue ; par conséquent, il n’est pas approprié de la qualifier de plateforme API ouverte complète.

La plateforme web commerciale Bugster, les agents IA et les services d’exécution cloud ne sont pas des produits open source. Le dépôt officiel bugster-cli met en ligne le code source sous licence MIT, ce qui signifie uniquement que la composante CLI peut être utilisée conformément à cette licence ; le backend cloud, l’orchestration des modèles ou les services payants ne sont pas rendus accessibles.

Points clés des conditions de service

Les conditions du service en vigueur entrent en application le 5 janvier 2025 ; les utilisateurs doivent avoir au moins 18 ans et être en mesure de conclure des accords. Ils sont tenus de protéger leurs identifiants de connexion et d’assumer la responsabilité des activités de leur compte. Toute utilisation illégale ou préjudiciable à autrui est interdite.

Les conditions fournissent les services « tels qu’ils sont », et se réservent le droit de suspendre ou de résilier un compte en cas de violation des règles ; la loi applicable est celle du Delaware, aux États-Unis. Les descriptions relatives aux droits de propriété intellectuelle et aux limites de responsabilité sont assez succinctes ; les achats commerciaux doivent faire l’objet d’une analyse plus approfondie en tenant compte de la commande, de l’accord de traitement des données et du SLA.

Informations de base

Indice de recommandation

Le score de recommandation est de 4,3 sur 5. Bugster relie de manière assez complète les tests en langage naturel, le YAML lisible, les proxies navigateur, les enregistrements des échecs et les retours des requêtes de pull, permettant aux rôles de développement, de QA et de produit de collaborer au sein du même processus.

Les points déduits proviennent principalement du fait que le montant final du forfait d’équipe doit faire l’objet d’une demande de prix, de légères différences dans les informations sur différentes pages officielles, ainsi que des faux positifs possibles lors des tests avec le navigateur IA. Pour les équipes ayant des besoins clairs en matière de flux de travail GitHub et de tests de régression pour les applications web, il est approprié d’utiliser d’abord le forfait gratuit pour valider les processus clés.

Questions fréquentes

Est-ce que Bugster est gratuit ?

Une version gratuite Starter est disponible, offrant actuellement 70 exécutions de tests bout en bout par mois, jusqu’à 5 tests par demande de pull et jusqu’à 3 tests en parallèle. Selon les informations sur le site officiel, il est possible de commencer à l’utiliser sans carte de crédit.

Combien coûte le forfait Team ?

La page officielle dédiée aux services indique un prix de base de 99 dollars par équipe et par mois, mais la carte de tarification principale sur la page d’accueil demande de contacter le service des ventes. Étant donné que le volume d’utilisation, l’agent destructeur, le parallélisme, les fonctionnalités supplémentaires et les SLA peuvent être personnalisés, le prix final doit se fonder sur la page de devis ou de facturation.

Est-ce que c’est utilisable sans savoir écrire du code ?

Il est possible de décrire le processus de test en langage courant sur la page web, ou bien d’énumérer clairement les étapes et les résultats attendus. Les assertions complexes, les données de test, l’isolation de l’environnement et la configuration de l’intégration continue doivent néanmoins faire l’objet de la participation du QA ou des développeurs.

Quels navigateurs sont pris en charge ?

La documentation CLI énumère les trois moteurs de navigateur Chromium, Firefox et WebKit. Pour une version spécifique de navigateur, un appareil mobile réel ou un laboratoire d’appareils physiques, il convient de demander des informations auprès des responsables officiels séparément.

Peut-on l’exécuter localement ?

CLI peut exécuter des tests localement sur des adresses de développement accessibles, mais l’exécution de l’IA, l’authentification et la transmission en flux des résultats restent connectées au service Bugster. Ce n’est pas un cadre de test local entièrement hors ligne.

Prend-il en charge CI/CD ?

Prend en charge GitHub App, GitHub Actions, Vercel, Railway, Netlify, GCP Cloud Build et des Webhooks personnalisés. L’équipe doit conserver les clés API dans une gestion secrète pour l’intégration continue.

Y a-t-il une API ?

Une API Webhook est fournie pour personnaliser l’intégration des déploiements, permettant de déclencher des tests après un déploiement réussi. Les informations actuellement publiques ne suffisent pas à la décrire comme une API universelle couvrant l’ensemble des capacités de gestion de projets et de tests.

Bugster est-il open source ?

Les plateformes cloud commerciales ne sont pas open source ; le dépôt officiel de CLI est soumis à la licence MIT. L’utilisation d’une CLI open source nécessite néanmoins un compte Bugster et un service de hébergement.

Le code source sera-t-il sauvegardé ?

La page de sécurité indique que le code source n’est pas conservé de manière permanente dans la base de données, et que le code obtenu depuis GitHub en temps de exécution est supprimé après traitement. La page d’accueil affirme quant à elle que des environnements de test ont été déployés et qu’aucun accès au code n’est possible ; les utilisateurs de dépôts privés doivent vérifier leurs droits réels en fonction des fonctionnalités activées.

Les données de test seront-elles utilisées pour entraîner le modèle ?

Selon les instructions de sécurité officielles, les codes clients et les produits de test ne seront pas utilisés pour entraîner ou affiner les modèles. Les tests continueront d’appeler des modèles externes et des services d’observation ; les projets sensibles exigent une vérification plus approfondie des contrats, des sous-traitants et des chemins de données.

Bugster a-t-il déjà obtenu SOC 2 ?

Non. La page de sécurité indique clairement que Bugster n’a pas encore obtenu la certification SOC 2 ; la certification mentionnée concerne des fournisseurs tels qu’AWS et GCP, et ne peut donc pas être considérée directement comme une certification pour le produit Bugster.

Peut-il remplacer complètement le QA manuel ?

Non. Il convient à l’élargissement de la couverture des tests de retour et de déploiement bout en bout, mais les décisions commerciales, les tests exploratoires, la sécurité, les performances, l’accessibilité et les déploiements à haut risque nécessitent toujours l’intervention de professionnels.