Bugster

Eine kurze Beschreibung

Bugster ist eine AI-basierte End-to-End-Testplattform für Webanwendungen. Nutzer können Prozesse in natürlicher Sprache oder mit strukturierten Testvorgaben beschreiben, wobei ein Agent im Browser die Aktionen ausführt, Ergebnisse bewertet und Beweise erzeugt.

Es bietet gleichzeitig eine Web-Oberfläche, Befehlszeilenwerkzeuge, die GitHub App sowie Funktionen für kontinuierliche Integration – ideal, um Produktprüfungen, Regressionstests sowie automatische Tests nach dem Deployment miteinander zu verbinden.

Was ist Bugster?

Bugster wird von Bugster Inc. bereitgestellt und ist als selbstständiger QA-Agent für Entwicklerteams konzipiert – und nicht als allgemeiner Code-Generator. Die Plattformdienste basieren hauptsächlich auf Cloud-SaaS-Lösungen. Die Tests können in lokalen Entwicklungsumgebungen, Prüfumgebungen, Testumgebungen oder in zugänglichen Produktionsumgebungen durchgeführt werden.

Entwickler können YAML-Tests im Code-Repository verwalten, während QA- und Produktmitarbeiter die Benutzerprozesse in einer einfachen Sprache auf der Webseite beschreiben können. Beide Ansätze teilen sich Projekte, Testsets sowie Ausführungsergebnisse, was eine Zusammenarbeit verschiedener Rollen unter Einhaltung derselben Qualitätsstandards erleichtert.

Hauptfunktionen

Tests zur Erstellung natürlicher Sprache

Die Webversion ermöglicht es den Benutzern, die Prozesse wie Registrierung, Anmeldung, Kauf oder Formularabsendung direkt zu beschreiben. Der Agent wandelt diese Anforderungen in ausführbare End-to-End-Tests um. Die Benutzer können außerdem die Schritte sowie die erwarteten Ergebnisse klar festlegen, um Unklarheiten durch freie Exploration zu vermeiden.

Echter Browser-Start

Durch Ausführung des Befehls werden die Testvorgaben des Projekts angezeigt. Anschließend wird eine Browserinstanz gestartet, und der AI-Agent führt die Schritte zur Bearbeitung der Seite aus. Zu den in der aktuellen Befehlszeilendokumentation aufgeführten Browserenginen gehören Chromium, Firefox und WebKit; standardmäßig wird Chromium verwendet.

Beweise und Berichte über Misserfolge

Nach Abschluss des Tests werden der Erfolgs- oder Misserfolgsstatus, das Schritt-für-Schritt-Protokoll, Screenshots sowie Ergebnisinformationen angezeigt. Bei fehlgeschlagenen Tests wird außerdem automatisch ein Video aufgezeichnet. Die Ergebnisse können in Echtzeit an die Web-Oberfläche übertragen werden oder als JSON gespeichert werden, damit sie von Continuous-Integration-Systemen oder anderen Tools weiterverarbeitet werden können.

Testen von Synchronisation und Zusammenarbeit

Entwickler können Tests für die Webversion in menschenlesbaren YAML-Dateien exportieren, diese in Cursor, Claude Code oder einem herkömmlichen Editor bearbeiten und anschließend wieder auf die Plattform hochladen. Die Tests können außerdem nach Funktionen in Pakete gegliedert werden und zwischen Branches, Umgebungen sowie Teammitgliedern synchronisiert werden.

Betroffene Tests und automatische Aktualisierungen

Bugster ermöglicht es, nur die Tests auszuführen, die mit Codeänderungen zusammenhängen, und bietet außerdem einen Workflow zur Aktualisierung der Testanforderungen. Dadurch wird die Zeit, die bei jedem Commit für den Ausführung des gesamten Testsets benötigt wird, reduziert. Dennoch sollten in den kritischen Prozessen weiterhin feste Rückgabetests durchgeführt werden, um zu vermeiden, dass durch Entscheidungen bezüglich der Änderungen wichtige Tests übersehen werden.

Explorativer Test mit zerstörerischen Mitteln

Der Destructive Agent wird eingesetzt, um Grenzbedingungen und zerstörerische Abläufe zu untersuchen, die bei herkömmlichen Vorgehensweisen oft übersehen werden. Er eignet sich besonders gut dazu, unerwartetes Verhalten nach Funktionsänderungen aufzudecken. Im Gegensatz zu den End-to-End-Tests bekannter Schlüsselprozesse muss die aktuelle Nutzungsmenge gemäß dem Team-Paket konfiguriert werden.

• Beschreiben Sie den Benutzerprozess, die Schritt für Schritt-Anleitung sowie die erwarteten Ergebnisse in natürlicher Sprache oder YAML.
• In dem Browser werden Klicks, Eingaben, Navigationen, Anmeldungen sowie Seitenvalidierungen durchgeführt.
• Erstellen Sie für fehlgeschlagene Tests Videoaufnahmen, Screenshote, detaillierte Protokolle sowie Schritt-für-Schritt-Anleitungen zur Wiederholung.
• Aus der Befehlszeile ausführen alle Tests, einen bestimmten Ordner, eine einzelne Datei oder temporäre Hinweistests.
• Unterstützung der parallelen Ausführung, des headless-Betriebs, der streambasierten Übertragung von Ergebnissen und der JSON-Ausgabe.
• Durch die GitHub App werden Tests automatisch bei Pull-Requests und Vorab-Deployments ausgeführt.
• Unterstützung für die zeitgesteuerte Ausführung, Tests in mehreren Umgebungen sowie die Verwaltung von Testsets für Teams.
• Andere Bereitstellungsplattformen können über benutzerdefinierte Webhooks in den Testauslösungsprozess integriert werden.

Testspezifikationen und Konfigurationsmöglichkeiten

YAML-Testinhalt

Testdateien können Namen, Zielseiten, Seitenpfade, Aufgaben, Schritte sowie erwartete Ergebnisse speichern. Bei Anmelde-Szenarien können außerdem vordefinierte Anmeldeinformationen verwendet werden. Das strukturierte Format erleichtert die Code-Überprüfung, das Versionieren sowie Änderungen mit Hilfe von Coding-Agenten.

Projektbezogene Konfiguration

Die Projektkonfiguration ermöglicht es, Optionen wie die Basisadresse, Anmeldeinformationen, die Anzahl der parallelen Ausführungen, den Ausgabepfad, den Headless-Modus sowie die Ausführung nur der betroffenen Tests festzulegen. Die Parameter der Befehlszeile überschreiben die entsprechenden Einstellungen in der Konfigurationsdatei, sodass Umgebungen für kontinuierliche Integration eigene Ausführungsstrategien beibehalten können.

Sensible Anmeldeinformationen

Die Benutzernamen, Passwörter und Token der verschiedenen Rollen sollten über Umgebungsvariablen oder Plattformschlüssel übergeben werden, wobei die Zugangsdaten anschließend in den Testdateien referenziert werden. Echte Schlüssel sollten nicht direkt in YAML-Dateien geschrieben oder in Code-Repositories hochgeladen werden.

Vollständiger Arbeitsablauf

1. Erstellen Sie die Bugster-Organisation und -Projekte sowie bestimmen Sie die zu testenden Webanwendungen und die Zielumgebungen.
2. Verbinden Sie sich mit dem GitHub-Repo oder installieren Sie die CLI lokal, um anschließend die Kontoverifizierung und die Initialisierung des Projekts durchzuführen.
3. Erstellen Sie Tests in natürlicher Sprache oder geben Sie die Schritte und erwarteten Ergebnisse auf der Webseite sowie in YAML-Dateien an.
4. Konfigurieren Sie Umgebungsvariablen für die Anmelderolle, um zu vermeiden, dass Benutzernamen und Passwörter im Repository gespeichert werden.
5. Führen Sie zunächst einige Schlüsselprozesse lokal aus, um die Proxy-Aktionen, Aussagen, Screenshots sowie Aufnahmen von Fehlern zu überprüfen.
6. Synchronisieren Sie die validierten Tests mit der Plattform und erstellen Sie daraus Pakete für Anmelden, Abrechnung oder Backend-Verwaltung.
7. Fügen Sie die Tests zu Pull-Requests, Vorschau-Deploys oder zeitgesteuerten Aufgaben hinzu und passen Sie die Parallelisierungs- und Auslösungsregeln entsprechend den Ergebnissen an.
8. Regelmäßige Überprüfung von Fehlmeldungen, Unterberichtungen und veralteten Vorschriften, um manuelle Prüfungen mit AI-Tests zu ergänzen.

Einführung in die Kommandozeile

1. Stellen Sie sicher, dass die Geräte in einer unterstützten Windows-, macOS- oder Linux-Umgebung verwendet werden, und bereiten Sie Node.js 18 oder eine neuere Version vor.
2. Installieren Sie die offizielle CLI und führen Sie den Authentifizierungs-Befehl aus, um Ihre persönliche API-Schlüssel von der Konsole abzurufen.
3. Führen Sie die Initialisierung im Projektverzeichnis aus, damit das Tool die Projektkonfiguration sowie die Testverzeichnisse erstellt.
4. Ausführen des Erstellungsbefehls zur Erstellung der ersten Testspezifikationen, anschließend manuelle Überprüfung der Aufgaben, Schritte und erwarteten Ergebnisse.
5. Führen Sie alle Tests oder die angegebenen Dateien aus. Bei erster Verwendung wird empfohlen, eine geringe Anzahl an Parallelverarbeitungen zu verwenden und detaillierte Protokolle anzuzeigen.
6. Für die kontinuierliche Integration sollten Modus ohne Benutzeroberfläche, JSON-Ausgabe sowie die streambasierte Übertragung der Ergebnisse aktiviert werden.

Das offizielle CLI-Repository bietet Windows-Installationspakete sowie Anleitungen für die Installation auf verschiedenen Plattformen. Die Windows-Exekutabeln können von Sicherheitssoftware wegen fehlender digitaler Signaturen durch namhafte Verleger als bedrohlich eingestuft werden. Das Team sollte zunächst die offizielle Version sowie die Quelle der Dateien überprüfen und anschließend gemäß den internen Sicherheitsrichtlinien entscheiden, ob sie freigegeben werden dürfen.

Lehrbuch zur schnellen Testung und Fehlerbehebung

1. Starten Sie zunächst die lokale Anwendung oder bereiten Sie eine zugängliche Test-Adresse vor.
2. Schreiben Sie mit einem temporären Hinweisparameter eine konkrete Testaufgabe, die nicht länger als 1000 Zeichen ist.
3. Überwachen Sie, ob der Agent die richtige Seite aufruft, das richtige Konto verwendet und die erwarteten Aktionen ausführt.
4. Bei Fehlern sollten die Schrittprotokolle, Screenshots und Videos überprüft werden, um festzustellen, ob es sich um einen Produktfehler, Umweltprobleme oder eine unklare Testbeschreibung handelt.
5. Ordnen Sie die stabilen und wiederholt auszuführenden temporären Tests in YAML an und fügen Sie sie dem offiziellen Testset hinzu.

Die maximale Konkurrenzzahl bei schnellen Hinweistests beträgt 1; sie eignet sich besser zur Erkundung und zur Überprüfung kurzer Abläufe. Für formelle Regressionstests sollten testbezogene Dateien verwendet werden, die einer Versionsverwaltung unterliegen, und für wichtige Aussagen sollten lesbare, manuell festgelegte Erwartungsergebnisse hinterlegt werden.

Anbindung an GitHub und CI/CD

Die GitHub-App von Bugster kann mit Organisationen und bestimmten Repositorien verbunden werden, um Tests auszulösen, sobald die Vorbereitungen für den Prüfverlauf im Zuge eines Pull Requests abgeschlossen sind. Die Testergebnisse, Fehlerbeschreibungen sowie Videoaufnahmen können in den Entwicklungsprozess zurückgeführt werden, um dem Team dabei zu helfen, Rückfälligkeiten vor dem Merge zu überprüfen.

1. Installieren Sie die Bugster GitHub App in den Organisationseinstellungen und erteilen Sie Berechtigungen nur für die Repositorien, die getestet werden sollen.
2. Verbinden Sie das Ziel-Repository mit dem Bugster-Projekt und überprüfen Sie, ob der Berechtigungsumfang des Repositories mit dem der Anwendung übereinstimmt.
3. Konfigurieren Sie Vercel, Railway, Netlify oder andere Deployment-Plattformen, damit die Vorschauumgebung nach Abschluss Ereignisse sendet.
4. Übergeben Sie die Projektkonfiguration sowie die Testverzeichnisse im Lager, aber speichern Sie die API-Schlüssel und Anmeldedaten in einer Geheimnisverwaltung.
5. Wählen Sie aus, ob es bei jeder Übermittlung oder jedem Pull-Request ausgeführt werden soll, und legen Sie die Umgebung als Produktiv, Vorabversion oder beide fest.
6. Erzeugen Sie einen kontrollierten Fehler, um zu überprüfen, ob die Rückmeldungen zu Pull-Requests, Videoaufnahmen sowie E-Mails oder Slack-Benachrichtigungen verfügbar sind.

Die aktuelle Website listet GitHub als verfügbare Integration für Code-Hosting auf, während GitLab und Bitbucket weiterhin als künftig unterstützt angezeigt werden. Werbematerialien zu GitLab auf anderen Seiten sollten nicht als bereits offiziell verfügbar angesehen werden; vor der Nutzung sollte man sich an den tatsächlichen Optionen in der Plattform orientieren.

Benutzerdefinierte Webhook-API

Die offiziellen Dokumentationen bieten eine integrierte Webhook-Schnittstelle zur Bereitstellung. Dritte Tools können nach erfolgreicher Bereitstellung die Adresse des Projekts, der Organisation sowie des Umfelds sowie weitere Informationen übermitteln, wodurch Tests mit Bugster ausgelöst werden. Die Schnittstelle wird über API-Schlüssel authentifiziert und eignet sich für Bereitstellungsplattformen, die keinen integrierten Connector haben.

Es handelt sich um eine API zur Auslösung von Bereitstellungsereignissen; sie entspricht nicht einem allgemeinen, öffentlichen SDK für die Verwaltung von Projekten, Tests, Ergebnissen und Konten. Derzeit gibt es kein offiziell veröffentlichtes, vollständiges, mehrsprachiges Client-SDK – die Nutzung ist gemäß den Dokumentationen zu den öffentlichen Schnittstellen zu regeln.

Rahmenwerk, Browser und Plattformunterstützung

Die offizielle Website listet derzeit Frontend-Frameworks wie Next.js, React, Svelte, Angular und Vue auf, doch die automatische Generierung unterscheidet sich je nach Framework nicht vollständig. In den offiziellen Dokumenten wird Next.js als Framework mit erweitertem Support aufgeführt, während andere Frameworks eher für die Generierung mithilfe von Editor-Regeln und Coding-Proxy-Tools geeignet sind. Die Tests können weiterhin an zugänglichen Webanwendungen durchgeführt werden.

• Befehlszeilsysteme: Windows, macOS und Linux.
• Systemanforderungen: Node.js 18 oder eine neuere Version sowie der für Playwright erforderliche Browser.
• Browser-Engine: Chromium, Firefox und WebKit; die tatsächliche Verfügbarkeit hängt vom Betriebssystem ab.
• Frontend-Frameworks: Auf der offiziellen Website werden Next.js, React, Vue, Angular und Svelte aufgeführt.
• Deployment-Plattformen: Vercel, Railway, Netlify, GCP sowie eigene Deployment-Prozesse.
• Code-Zusammenarbeit: Derzeit ist GitHub die offizielle Integration, GitLab und Bitbucket sind weiterhin im Roadmap enthalten.
• Entwicklungs-Eingänge: Web-Workbench, CLI, GitHub App und bereitgestellte Webhooks.

Auf der Vermarktungsseite wird eine Abdeckung durch gängige Browser und Geräte erwähnt, doch in den CLI-Dokumenten werden ausdrücklich drei Browser-Engines genannt. Falls das Projekt echte Handys, bestimmte Systemversionen oder Laborgeräte erfordert, sollte man vor dem Kauf mit dem Team Rücksprache halten – man sollte WebKit-Simulatoren nicht einfach mit echten Safari-Geräten gleichsetzen.

Für welche Benutzer geeignet

• QA-Engineer: Schreibt die wichtigen Benutzerprozesse als wiederholbar ausführbare Tests nieder und überprüft die Fehlschläge mithilfe von Videoaufnahmen und Protokollen.
• Frontend-Entwickler: Führen von Regressionstests auf lokaler Ebene, in Branches sowie bei Vorabveröffentlichungen durch, um unerwünschte Probleme durch Änderungen an der Benutzeroberfläche zu vermeiden.
• Produktmanager: Definieren Sie den Abnahmeprozess in alltäglicher Sprache und ergänzen Sie anschließend gemeinsam mit dem QA die genauen Schritte sowie die erwarteten Ergebnisse.
• Projektleiter: Pull-Requests für die Testung der Zutrittskontrolle einreichen, um den Ausführungszustand, die Ursachen für Misserfolge sowie die Testkosten zentral zu überprüfen.
• Kleine Unternehmensteams: Wenn es keine große Team für automatisierte Tests gibt, sollten zunächst die Prozesse der Registrierung, Anmeldung, Bezahlung sowie die wichtigsten Konvertierungsprozesse abgedeckt werden.
• Plattform-Entwicklerteam: Nutzt Webhooks und kontinuierliche Integration, um Tests in die bestehende Deployment-Pipeline einzubinden.

Typische Anwendungsszenarien

• Anmelde-Rückkehr: Überprüfung des Anmeldevorgangs mit verschiedenen Rollen, des Berechtigungs-Menüs sowie des Verhaltens auf nicht autorisierten Seiten.
• E-Commerce-Prozess: Überprüfen, ob Suchfunktion, Produktdetails, Warenkorb, Rabattangebote und Zahlseite zusammenhängend sind.
• Formvalidierung: Überprüfung von Pflichtfeldern, fehlerhaften Eingaben, erfolgreicher Abschluss der Übermittlung und Fehlermeldungen.
• Pull-Request-Prüfung: Nach dem Bereitstellen in der Vorschauumgebung werden automatisch die betroffenen Tests ausgeführt und die Ergebnisse zurückgesendet.
• Nächtlicher Rückruf: Regelmäßige Ausführung des stabilen Sets, um Änderungen in Abhängigkeiten, der Umgebung oder langfristigen Prozessen frühzeitig zu erkennen.
• Explorativer Test: Lassen Sie den Destructive Agent Grenzbedingungen ausprobieren, wobei die QA die Risiken sowie die Wege zur Wiederholung überprüft.
• Mehrfach-Überprüfung in verschiedenen Umgebungen: Verwendung derselben Spezifikationen zur Überprüfung der Schlüsselprozesse in den Entwicklungs-, Test-, Vorschau- und Produktionsumgebungen.

Vorteile des Produkts

• Die Testbeschreibung kann gleichzeitig technikunbelehrte Benutzer auf der Webseite sowie Entwickler im Code-Repository bedienen.
• Die YAML-Spezifikation ist lesbar, überprüfbar und versionierbar, wodurch die Testlogik nicht nur in Black-Box-Plattformen vorhanden ist.
• Der Agent ist für die Interaktion mit dem Browser verantwortlich und erstellt Screenshots, Protokolle sowie Aufnahmen von Fehlern, um die Probleme leichter lokalisieren zu können – anstatt nur ein rotes Licht anzuzeigen.
• GitHub App, Deployment-Plattformen und Webhooks integrieren die Testauslösepunkte in den bestehenden Lieferprozess.
• Die kostenlose Version bietet eine klare monatliche Nutzungsgrenze, die geeignet ist, um zunächst Schlüsselszenarien und das Ausmaß an Fehlalarmen zu überprüfen.
• Die offizielle CLI stellt den Quellcode unter der MIT-Lizenz zur Verfügung, sodass das Team die Implementierung sowie die Veröffentlichung des Befehlszeilen-Teils überprüfen kann.

Einsatzbeschränkungen und Hinweise

• KI-Agenten könnten vage Ziele falsch interpretieren oder Verzögerungen bei der Seitenladung als Misserfolg ansehen; wichtige Tests erfordern klare Schritte, stabile Daten sowie menschliche Überprüfung.
• Die Testziele müssen aus der Ausführungsumgebung zugänglich sein; lokale Dienste, geschützte Vorschauen und Unternehmensnetzwerke können eine zusätzliche Konfiguration erfordern.
• Starter führt pro Pull-Request maximal 5 End-to-End-Tests aus, wobei die maximale Anzahl gleichzeitig 3 beträgt. Für komplexe Testpakete muss eine kostenpflichtige Kapazität in Betracht gezogen werden.
• Der Schnellhinweis umfasst maximal 1000 Zeichen und die Konkurrenzfähigkeit liegt bei 1; er eignet sich daher nicht als einzige Speichermethode für große Regressionstests.
• Eine zu hohe Parallelisierung kann Druck auf Testkonten, gemeinsam genutzte Datenbanken, rate-limitede Schnittstellen oder Drittanbieterdienste ausüben.
• Für zerstörerische Abläufe wie tatsächliche Zahlungen, Löschung und Versendung von Nachrichten sollten isolierte Umgebungen, Testkonten sowie wiederherstellbare Daten verwendet werden.
• Die Aktualisierungsfrequenz der offiziellen Website, der Dokumentationen sowie der GitHub READMEs unterscheidet sich. Die Unterstützung durch das Framework sowie die Anzahl der zulässigen Befehle richten sich nach den aktuellen Produktdokumentationen und der Konsole.
• Automatisierte Ergebnisse können einen vollständigen Qualitätsprozess mit Barrierefreiheit, Leistung, Sicherheit, Geschäftsregeln und manueller Untersuchung nicht ersetzen.

Preise und Pakete

Stand dem 20. August 2026 bieten die offiziellen Preistabellen die kostenlose Starter-Version sowie die Team-Version an. Auf einer weiteren offiziellen Seite wird angegeben, dass der Grundpreis für die Team-Version 99 US-Dollar pro Team pro Monat beträgt. Zudem können Kapazitäten und Funktionen weiter angepasst werden; daher sollte der endgültige Preis immer anhand der Informationen auf der Verkaufs- oder Rechnungsseite ermittelt werden.

Starter kann kostenlos gestartet werden, und auf der offiziellen Website steht, dass kein Kreditkarten erforderlich ist. Allerdings bedeutet die Kostlosigkeit nicht, dass alle Funktionen unbegrenzt genutzt werden können. Unter den Hauptpreisen auf der Startseite wird Team als „Kontaktieren Sie den Verkäufer“ angezeigt. 99 Dollar sind der offiziell angegebene Basispreis – vor dem Kauf sollten die tatsächlichen Kosten, zusätzliche Gebühren sowie die SLA-Konditionen überprüft werden.

Datenschutz und Sicherheit

Laut den Sicherheitsanweisungen wird für die Kernberechnungen und -speicherung von Bugster AWS verwendet, für unterstützende Dienste GCP. Zudem werden OpenAI und Anthropic zur Durchführung von Inferenzen herangezogen. Die Übertragung erfolgt über TLS 1.2 oder 1.3. Klientencodes sowie Testergebnisse werden nicht zur Schulung oder Feinabstimmung von Modellen verwendet.

Die Startseite der offiziellen Website betont, dass die Tests in bereits eingesetzten Umgebungen durchgeführt werden und dabei nicht auf den Quellcode zugegriffen wird. Auf der Sicherheitsseite hingegen wird erklärt, dass der GitHub-Quellcode während des Betriebs vorübergehend abgerufen und anschließend wieder verworfen werden kann. Die Aussagen beider Seiten sind unterschiedlich; bevor auf private Repositorien zugegriffen wird, müssen die Berechtigungen, die vorübergehenden Handlungsweisen sowie die vertraglichen Vereinbarungen entsprechend der tatsächlichen Funktionalitäten überprüft werden.

• Der Quellcode wird nicht dauerhaft in der Bugster-Datenbank gespeichert; auf der Sicherheitsseite heißt es, er werde nach Abschluss des Zugriffs während der Ausführung gelöscht.
• Protokolle, Screenshot und Videos werden standardmäßig 30 Tage lang im Objektspeicher gespeichert und können nach Bedarf gelöscht werden.
• Die Löschanfrage wird innerhalb von 24 Stunden aus dem aktiven System entfernt und innerhalb von 30 Tagen aus den Backups gelöscht.
• Modellhinweise und -antworten sind auf den Session-Ablauf beschränkt, und die Protokolle der Beobachtungen werden zur Fehlerbehebung und zur Überwachung der Zuverlässigkeit anonymisiert.
• Offiziell wird erklärt, dass Kundencodes und Testprodukte nicht für das Training oder Feinabstimmen von Modellen verwendet werden.
• Bugster selbst verfügt noch nicht über eine SOC 2-Zertifizierung; die Zertifizierung eines Cloud-Anbieters ist nicht gleichzusetzen mit einer Produktzertifizierung.
• Die Sicherheitsseite hat BYOK als geplante Funktion aufgeführt; ob es derzeit bereits offiziell verfügbar ist, muss noch bei den Verantwortlichen bestätigt werden.

Tests umfassen oft Kontoinformationen, Kundendaten sowie Geschäftsprozesse. Die Organisation muss weiterhin ein Prinzip der Mindestberechtigungen einhalten, regelmäßig Passwörter ändern, Testdaten isolieren und den Zugang zu Aufzeichnungen kontrollieren. Bei der Verarbeitung von medizinischen, finanziellen oder anderen regulierten Daten sollten vor Abschluss eines Vertrags die Datenverarbeitungsvereinbarungen, der Standort, die Zulieferer sowie die Löschung von Beweismitteln überprüft werden.

API, CLI und Open Source

Bugster bietet eine CLI sowie Webhooks für die Bereitstellung, die eine Account-API-Schlüssel erfordern. Letztere ermöglichen es, Ereignisse über erfolgreiche Bereitstellungen in benutzerdefinierten Pipelines zu melden und Tests auszulösen. In den offiziellen Dokumentationen wird weder eine universelle REST-API, die alle Plattformressourcen abdeckt, noch ein formelles mehrsprachiges SDK vorgestellt; daher kann sie nicht pauschal als vollständige, offene API-Plattform bezeichnet werden.

Die Bugster-Webplattform für Geschäftszwecke, die AI-Agenten sowie die Cloud-Bereitstellungs-Dienste sind keine Open-Source-Produkte. Das offizielle Bugster-cli-Repositorium macht den Quellcode unter der MIT-Lizenz öffentlich – das bedeutet lediglich, dass die CLI-Komponenten gemäß dieser Lizenz verwendet werden können. Der Cloud-Backend, die Modellverwaltung sowie die kostenpflichtigen Dienste sind hingegen nicht zugänglich.

Schwerpunkte der Dienstleistungsbedingungen

Das aktuelle Nutzungsrecht tritt am 5. Januar 2025 in Kraft. Es wird vorausgesetzt, dass die Nutzer mindestens 18 Jahre alt sind und in der Lage sind, Verträge abzuschließen. Die Nutzer müssen ihre Anmeldedaten schützen und für die Aktivitäten auf ihrem Konto verantwortlich sein. Eine Nutzung zum Zweck von Rechtsverstößen oder zum Schaden Dritter ist untersagt.

Die Bedingungen stellen die Dienstleistungen in ihrem aktuellen Zustand zur Verfügung und behalten sich das Recht vor, Konten aufgrund von Verstößen gegen die Regeln vorübergehend zu sperren oder zu beenden. Geltendes Recht ist das Recht des Bundesstaates Delaware in den USA. Die Beschreibungen zu Urheberrechten und Haftungsbeschränkungen sind eher knapp gehalten; Unternehmen sollten bei Einkäufen die Bestellunterlagen, Datenverarbeitungsvereinbarungen sowie SLA-Dokumente genauer prüfen.

Grundlegende Informationen

Empfehlungswert

Die Empfehlungsbewertung liegt bei 4,3 von 5 Punkten. Bugster verbindet Tests in natürlicher Sprache, lesbares YAML, Browser-Proxy-Systeme, Aufnahmen von Fehlern sowie Rückmeldungen zu Pull-Requests auf eine ziemlich umfassende Weise miteinander. Entwickler, QA-Mitarbeiter und Produktmanager können somit im selben Prozess zusammenarbeiten.

Die Abzüge entstehen hauptsächlich dadurch, dass für die endgültige Grenze des Team-Pakets ein Preis angefragt werden muss, durch leichte Unterschiede in den Angaben auf verschiedenen offiziellen Seiten sowie durch mögliche Fehlberichte bei Tests mit dem AI-Browser. Für Teams, die klare Anforderungen an Workflows in GitHub sowie an Regressionstests für Webanwendungen haben, eignet es sich, zunächst die kostenlosen Ressourcen zu nutzen, um die wichtigsten Prozesse zu überprüfen.

Häufige Fragen

Ist Bugster kostenlos?

Es wird eine kostenlose Starter-Version angeboten, die derzeit 70 End-to-End-Tests pro Monat umfasst, jeweils bis zu 5 Tests pro Pull-Request sowie maximal 3 parallele Tests. Laut der Offiziellen Website kann man ohne Kreditkarte beginnen zu nutzen.

Wie viel kostet das Team-Paket?

Auf der offiziellen Unternehmensseite steht, dass der Grundpreis 99 US-Dollar pro Team pro Monat beträgt. Auf der Hauptpreistabelle auf der Startseite wird jedoch empfohlen, sich an den Verkauf zu wenden. Da die Nutzungsmenge, Destructive Agent, Parallelisierung, zusätzliche Funktionen sowie SLA-Anforderungen angepasst werden können, gilt letztendlich der Preis auf der Angebots- oder Rechnungsseite.

Kann man es auch ohne Programmieren verwenden?

Am Webbrowser kann der Testablauf in allgemeiner Sprache beschrieben werden, oder es können die Schritte sowie die erwarteten Ergebnisse ausdrücklich aufgeführt werden. Für komplexe Aussagen, Testdaten, Umgebungsisolation sowie Konfigurationen für kontinuierliche Integration wird weiterhin die Beteiligung von QA-Experten oder Entwicklern empfohlen.

Welche Browser werden unterstützt?

Die CLI-Dokumentation listet die drei Browser-Engines Chromium, Firefox und WebKit auf. Für spezielle Browser-Versionen, echte Mobilgeräte oder Laborumgebungen mit physischen Geräten ist eine gesonderte Anfrage bei den Herstellern erforderlich.

Kann es lokal ausgeführt werden?

Die CLI kann lokal Tests an den zugänglichen Entwicklungsadressen ausführen, doch die Ausführung der KI, die Authentifizierung sowie die Übertragung der Ergebnisse sind weiterhin mit dem Bugster-Service verbunden. Es handelt sich dabei nicht um ein vollständig offline-fähiges lokales Testframework.

Wird CI/CD unterstützt?

Unterstützung für GitHub App, GitHub Actions, Vercel, Railway, Netlify, GCP Cloud Build sowie benutzerdefinierte Webhooks. Teams sollten API-Schlüssel in einer zentralen Verwaltung für Geheimnisse im Rahmen der kontinuierlichen Integration speichern.

Wird eine API bereitgestellt?

Es wird eine Webhook-API zur Anpassung der Deployment-Integration bereitgestellt, die nach einem erfolgreichen Deployment Tests auslösen kann. Die derzeit verfügbaren Informationen reichen nicht aus, um sie als universelle API zu bezeichnen, die alle Projekt- und Testverwaltungsfunktionen abdeckt.

Ist Bugster Open Source?

Kommerzielle Cloud-Plattformen sind nicht open source; das offizielle CLI-Repositorium verwendet die MIT-Lizenz. Um eine open source CLI zu verwenden, ist dennoch ein Bugster-Konto sowie ein Hosting-Dienst erforderlich.

Wird der Quellcode gespeichert?

Auf der Sicherheitsseite wird angegeben, dass der Quellcode nicht dauerhaft in der Datenbank gespeichert wird. Der aus GitHub abgerufte Code wird nach der Verarbeitung wieder gelöscht. Auf der Startseite heißt es, dass ein Testumfeld eingerichtet wurde und der Code nicht zugänglich ist. Benutzer privater Repositorien sollten ihre tatsächlichen Rechte entsprechend den aktivierten Funktionen überprüfen.

Wird die Testdaten zur Trainierung des Modells verwendet?

Laut den offiziellen Sicherheitsanweisungen werden die Kundencodes sowie die Ergebnisse der Tests nicht zur Schulung oder Anpassung von Modellen verwendet. Bei den Tests werden weiterhin externe Modelle und Überwachungsdienste genutzt; bei sensiblen Projekten müssen Verträge, Auftragnehmer sowie Datenflüsse zusätzlich überprüft werden.

Hat Bugster bereits SOC 2 zertifiziert?

Nein. Auf der Sicherheitsseite wird ausdrücklich darauf hingewiesen, dass Bugster selbst noch keine SOC 2-Zertifizierung besitzt. Die in der Seite erwähnten Zertifizierungen gelten für Anbieter wie AWS und GCP und können daher nicht direkt als Zertifizierung für die Produkte von Bugster angesehen werden.

Kann es die manuelle QA vollständig ersetzen?

Nein. Es eignet sich dazu, die Abdeckung von End-to-End-Regressionstests und Deployment-Prüfungen zu erweitern, doch für Geschäftsentscheidungen, explorativen Tests, Sicherheit, Leistung, Barrierefreiheit sowie die Veröffentlichung hochriskanter Versionen sind weiterhin Fachleute erforderlich.