Tests, die bei jedem Deploy laufen, und Fehler, die sich selbst anlegen
QA Spider testet Ihre App in einem echten Browser und über ihre API, führt die Suite bei jedem Deploy aus und legt jede bestätigte Regression in dem Tracker an, den Ihr Team ohnehin nutzt. Enterprise-Plan: Kontakt aufnehmen.
Das bekommen Sie
- UI-Tests im echten Browser
- REST- und GraphQL-Vertragsprüfungen
- Fehlerberichte, geschrieben aus dem fehlgeschlagenen Lauf: Schritte, Screenshot, Schweregrad. Auf Duplikate geprüft, erst nach Ihrer Freigabe angelegt.
- Fehler angelegt in Jira, ClickUp, GitHub Issues, Linear, Azure DevOps
- Warnungen in Slack, Discord, Telegram
- KI-Triage: instabiler Test oder echter Fehler
- Ursache aus Ihrem Repository, nur lesend
- Schweregrad
- P1
- Schritte
- Artikel hinzufügen, /checkout öffnen, einen abgelaufenen Code anwenden, mit einer Testkarte bezahlen.
- Erwartet
- Der Code wird mit einer Meldung abgelehnt.
- Tatsächlich
- „Code angewendet“ wird angezeigt und der volle Betrag berechnet.
- Angelegt in
- Jira, nach Freigabe. Slack-Warnung gesendet.
Wie ein Fehler reist
Ein Deploy startet die Suite. Ein fehlschlagender Test wird zum Fehlerbericht; sobald Sie ihn freigeben, landet er in Ihrem Tracker, und Ihr Team-Chat erfährt davon.
Nach einem Deploy laufen die Tests, einer schlägt fehl, und sein Fehlerbericht wandert in den Tracker des Teams, während eine Slack-Nachricht ihn ankündigt.
Ein Lauf schlägt fehl
Bei jedem Deploy, in einem echten Browser und gegen Ihre API.
Die Triage entscheidet
Instabiler Test, Infrastruktur-Aussetzer oder echter Produktfehler.
Der Bericht schreibt sich selbst
Schritte aus dem, was tatsächlich lief, der Screenshot, ein Schweregrad.
Sie geben frei
Er landet in Ihrem Tracker und Ihrem Chat, nicht vorher.
Standardmäßig sicher
Lesende Prüfungen laufen auf Produktion. Alles, was Daten anlegt oder ändert, läuft nur auf Dev oder Staging. Ein Ticket anzulegen oder in den Chat zu posten wartet auf Ihre Freigabe. Wir verstecken nie einen echten Fehler, um einen Lauf grün zu machen.
Auch mit Pro
Pro ($29/mo) enthält 1.000 Test-Credits pro Monat: erzeugte Tests auf Abruf ausführen, Tests auswählen, Suites speichern, einen Test aus einer Beschreibung erzeugen und visuell bearbeiten. Zeitplanung, Anlage im Tracker, Chat-Warnungen und KI-Triage gibt es mit Enterprise.
Auch Web3. dApps bekommen dieselbe Behandlung: Der Spider steuert Wallet-Abläufe mit emulierten Wallets (verbinden, Netzwerk wechseln, signieren, ablehnen), ruft Contracts gegen Testnets auf und prüft, ob das, was Ihre UI zeigt, mit der Chain übereinstimmt.
Fragen von Teams
Wie unterscheidet sich das davon, Tests selbst zu schreiben?
Nichts hält Sie davon ab. QA Spider schreibt gängigen Testcode, den Ihr Team auch schreiben könnte. Der Unterschied ist, wer die Arbeit macht: Es entwirft die Tests, führt sie bei jedem Deploy aus, repariert Locators, wenn sich Ihre UI ändert, und legt die Fehler an. Ihre Entwickler prüfen die Ergebnisse.
Überschwemmt es unseren Tracker?
Nein. Jeder Fehlschlag durchläuft zuerst die Triage: Instabile Tests werden repariert, Infrastruktur-Aussetzer wiederholt, und nur bestätigte Produktfehler werden zu Tickets. Das Anlegen braucht Ihre Freigabe, und jedes Ticket wird auf Duplikate geprüft.
Was passiert, wenn sich unsere UI ändert?
Wenn ein Locator durch ein Redesign gebrochen ist, repariert der Spider den Test und vermerkt es. Wenn sich das Verhalten verschlechtert hat, legt er einen Fehler an, statt den Test stillschweigend zu ändern, damit er grün bleibt.
Wie gehen Sie mit Login, Zahlungen und Testdaten um?
Sie geben dem Spider Testkonten für Staging. Er meldet sich an, zahlt dort mit Testkarten und sendet Formulare ab. Ändernde Abläufe laufen nur auf Dev und Staging; die Produktion bekommt nur lesende Prüfungen.
Brauchen Sie unseren Quellcode?
Nicht für Tests: Der Spider testet Ihre App so, wie ein Nutzer ihr begegnet. Optional können Sie ein Repository verbinden, nur lesend, damit ein Fehlschlag die dahinterstehende Datei und den Commit nennt.
Ist es sicher, gegen die Produktion zu laufen?
Läufe auf der Produktion beschränken sich auf lesende Smoke-Prüfungen. Alles, was Daten anlegt, bearbeitet oder löscht, ist als ändernd gekennzeichnet und läuft nur auf Dev oder Staging.