Fragen, die wir selbst vor dem Einsatz stellen würden.

Du beschreibst ein Nutzerziel in normaler Sprache. FD Verify führt den Flow auf einem echten Browser oder gekoppelten Gerät aus, probiert erlaubte Fehlerpfade, sammelt Evidence und kann erfolgreiche AI-Pfade danach als editierbare Regressionstests sichern.

Vor allem für SaaS-Teams, Agenturen und interne Produktteams, die Webanwendungen testen möchten, aber nicht jede neue Funktion zuerst in eine große Testautomation übersetzen wollen. Der Einstieg ist bewusst einfach; technische Tiefe bleibt für komplexe Workflows verfügbar.

Die Firma ist dein geschützter Workspace. Benutzer, Geräte und Berechtigungen gehören hierher. Eine Software ist das Produkt, das du testest, z. B. portal_v2. Ein Environment ist ein konkretes Ziel wie Staging, Preview oder Production.

FD Verify führt dich nach dem Signup durch sechs Schritte: Software anlegen, Environment verifizieren, Hosted Agent integrieren, Gerät koppeln, Gerät online bringen und erste AI-Mission starten. Für eine vorhandene Staging-App ist das Setup bewusst auf wenige Minuten ausgelegt.

Für die tiefe Browsersteuerung ja: ein kleines Script-Tag lädt den Hosted FD Verify Agent. Der Loader enthält keine dauerhaften geheimen Schlüssel und bleibt außerhalb einer autorisierten, kurzlebigen Testsession inaktiv. Die eigentliche Runtime wird zentral von FD Verify versioniert.

Nein. Die Runtime arbeitet primär mit Browser-Standards und ist für Vue, React, Angular, Svelte, klassisches HTML und serverseitig gerenderte Anwendungen ausgelegt. Open Shadow DOM und Same-Origin-Iframes werden unterstützt. Closed Shadow DOM, Cross-Origin-Iframes und Canvas-only UIs benötigen Sonderlösungen.

Unter „Geräte“ erzeugst du einen kurz gültigen QR-Code. Nach dem Scan wird das Gerät einmalig mit deiner Firma gekoppelt und bleibt danach im Firmen-Gerätepool. Es muss nicht für jedes Software-Projekt neu registriert werden.

Weil Rendering, Touch, PWA-Verhalten, Viewport, Browser-Version, Wake/Push und reale Netzwerkbedingungen auf echten Geräten Probleme zeigen können, die in synthetischen Browsern nicht identisch auftreten. FD Verify ersetzt Headless-Tests nicht grundsätzlich – es ergänzt sie dort, wo reale Nutzung zählt.

Formuliere das Ziel wie für einen menschlichen Tester: „Logge dich ein, öffne den Kalender, teste ein leeres Pflichtfeld und eine ungültige Uhrzeit und lege danach einen Testtermin an.“ Beschreibe Erfolg und Grenzen; einzelne Klicks musst du nicht vorgeben.

Im normalen Produktfluss nicht einfach deshalb, weil sie es im Prompt beschließt. Navigieren, Lesen, lokale Formularänderung, Absenden, Erstellen und Aktualisieren sind getrennte Capabilities. Destruktive Bereiche wie Löschen, Payment oder Security-Einstellungen werden nicht als normale öffentliche Mission-Capabilities freigegeben. Production ist zusätzlich geschützt.

FD Verify probiert bewusst plausible Fehler aus: Pflichtfeld leer, ungültiger Wert oder Grenzwert. Danach prüft der Test, ob die Anwendung sinnvoll reagiert und stellt – wenn der Flow weitergehen soll – wieder einen gültigen Zustand her.

Aktive Tests benötigen ein verifiziertes Environment. Dafür muss eine kurzlebige Challenge auf dem Zielsystem bereitgestellt werden. Zusätzlich begrenzt FD Verify Ziel-Origin, Requests, Laufzeit und Netzbereiche. Ohne Verifikation bleiben aktive Funktionen gesperrt.

Production wird absichtlich anders behandelt: AI ist serverseitig auf Read-only reduziert, API-Loadtests sind dort deaktiviert und Security bleibt auf passive Prüfungen beschränkt. Das Release Gate verweist für aktive Tests auf ein Staging-/Preview-Release-Candidate statt einen irreführenden Production-Score zu erzeugen.

Die tatsächlichen Kosten hängen von Modell, Mission und Anzahl der AI-Entscheidungen ab. Vor dem Start siehst du aber eine harte Obergrenze. Der Workspace-Admin definiert das maximale Budget pro Mission und Monat; du kannst für den einzelnen Test noch ein niedrigeres Limit wählen.

Der Server prüft vor jedem weiteren kostenpflichtigen Modellaufruf, ob dessen konservativ geschätzte Kosten noch in das Run-Budget passen. Ist das Limit ausgeschöpft, wird kein weiterer AI-Call gestartet. Provider-Usage wird pro Call dauerhaft verbucht.

Nein. Die normale Kundenansicht zeigt nur den FD-Verify-Verbrauch, Kosten des Runs, Monatsverbrauch und Restbudget. Provider-Einkauf und Marge sind einer getrennten Operator-Admin-Ansicht vorbehalten.

Je nach Test unter anderem Mission, Subgoals, einzelne Aktionen, erwartetes und tatsächliches Verhalten, besuchte Bereiche, blockierte Aktionen, Fehler, Timing-Daten und Screenshots/Evidence. Artefakte werden tenantautorisiert ausgeliefert; rohe Speicherpfade werden nicht einfach an den Browser gegeben.

Ein erfolgreicher AI-Pfad kann als editierbarer Test-Entwurf in den Test Builder übernommen werden. Dort prüfst du Locators und Assertions und speicherst ihn anschließend als versionierten Regressionstest. FD Verify macht also aus Exploration bewusst nicht stillschweigend einen Release-Test.

Eine gemeinsame Freigabeansicht für aktuelle AI-, Regression-, Performance- und Security-Evidence. Fehlende Tests gelten nicht als grün, High/Critical-Security-Findings blockieren und Evidence aus einem anderen Environment zählt nicht für das ausgewählte Ziel.

Credential Sets werden verschlüsselt gespeichert und sollen nicht in normalen Reports oder Logs erscheinen. Für sensible Anwendungen empfehlen wir trotzdem eigene Testaccounts mit minimalen Rechten und Testdaten statt produktiver Kundendaten.

Die Plattformgebühr beträgt aktuell 0 €. Eigene Geräte, Test Builder, Reports, Performance und defensive Security sind ohne monatliche Plattformgebühr enthalten. AI Explorer wird nach tatsächlicher Nutzung gemessen; im Early Access ist ein konfigurierbarer Betriebsaufschlag vorgesehen. Details stehen auf der Preisseite.

Für die V1-Architektur nicht zwingend. FD Verify ist als einzelne Node.js-Anwendung mit MySQL ausgelegt und kann auf passendem Managed-Node-Hosting betrieben werden.