Ihre Tester wissen bereits, was kaputtgegangen ist.
Snag sendet den Beweis mit.

Ein Tester, der gerade einen Regressionstest durchführt, erstellt einen besseren Bericht als jedes Tool. Was er jedoch nicht liefern kann, ist die Anfrage, die einen Fehler zurückgegeben hat, die Ausnahme, die nie auf dem Bildschirm angezeigt wurde, oder der Zustand der Seite zum Zeitpunkt des Fehlers. Ein einziges Skript-Tag im Entwicklungs-, Staging- oder UAT-Build fügt all diese Informationen dem Bericht hinzu, den der Tester ohnehin erstellen wollte.

Das Problem

Ein Testlauf liefert genau das, was jeder Tracker verlangt, aber selten erhält: echte Schritte, ein erwartetes, ein tatsächliches Ergebnis. Die Lücke liegt im Detail. Schritte erfassen lediglich die Aktionen einer Person – sie können weder die fehlgeschlagene Anfrage hinter dem Ladekreis, noch den unterdrückten Konsolenfehler oder den Klick, der ins Leere führte, dokumentieren. So kommt das Ticket zwar lesbar, aber ohne konkrete Handlungsoptionen an. Ein Entwickler durchläuft den Build erneut, um die vom Tester bereits beobachteten Aktionen nachzuvollziehen, und derselbe Lauf wird doppelt bezahlt. Hinzu kommen die zweiten, weniger offensichtlichen Kosten: Bei einer Abrechnung pro Person muss entschieden werden, welche externen Mitarbeiter und funktionsübergreifenden Prüfer überhaupt einen Fehler melden dürfen. Das ist eine Rationierungsentscheidung, und Fehler sollten nicht rationiert werden.

Wie Snag hilft

Ein einziges Skript-Tag im Vorproduktions-Build setzt auf jeder Seite eine dauerhaft sichtbare Pille, und jeder Tester hat sie ohne Einladung und ohne Konto. Ein Klick startet die Aufzeichnung; „Stopp“ öffnet das Berichtsformular, an dem Wiedergabe, Konsole und Netzwerk bereits hängen – der Bericht wird also einmal geschrieben und kommt mit seinen Belegen darunter an. Die Aufzeichnung folgt der Sitzung über Seitenwechsel hinweg, genau das braucht ein mehrstufiger Ablauf, und die Pille bleibt dort, wo jeder Tester sie abgelegt hat. Persönliche Daten werden im Browser maskiert, bevor irgendetwas hochgeladen wird – Eingaben werden nie aufgezeichnet, sodass ein Tester, der mit einem vorbefüllten Konto arbeitet, dessen Inhalte nicht an uns schickt. Nichts davon wird pro Kopf gezählt: unbegrenzte Mitglieder in jedem Tarif.

Was Sie zurückbekommen

Ein Entwickler kann ein Ticket einmalig öffnen, inklusive der zugehörigen Sitzung – ohne die übliche Nachfrage „Welcher Browser, worauf haben Sie geklickt?“. Bei einem Fix-Plan erhalten Sie außerdem einen Testversuch: Der Agent liest die aufgezeichnete Sitzung, arbeitet in einer privaten Kopie des Repositorys und führt Ihre eigene Testsuite für die Änderung aus. Ein Fix, der Ihre Tests nicht besteht, wird nicht als Fix angeboten. Ohne menschliches Eingreifen findet kein Merge statt. Sie erhalten also einen Diff zur Überprüfung, keine Deployment-Aktualisierung zum Rückgängigmachen. Für ein Testteam ist das zweite Artefakt besonders nützlich: eine Änderung, die bereits von Ihrer eigenen Testsuite getestet wurde und mit der Aufzeichnung verknüpft ist, die sie erzeugt hat. Die gesamte Pipeline finden Sie unter Funktionsweise des Agenten.

Fragen, die die Leute tatsächlich stellen

Benötigt jeder Tester einen kostenpflichtigen Zugang, um einen Fehler zu melden?

Nein, und es fallen keine Kosten pro Person an: Unbegrenzte Mitgliederzahl in jedem Tarif, auch im kostenlosen. Für die Einreichung ist nicht einmal ein Konto erforderlich – ein Tester klickt einfach auf die Schaltfläche, und der Bericht wird über den eigenen Hash-Schlüssel des Arbeitsbereichs authentifiziert, anstatt über einen Login. Das ist besonders wichtig für diejenigen, die am schwierigsten zu lizenzieren sind: externe Tester, Designer, die vor der Freigabe einen Testlauf durchführen, und der Support-Mitarbeiter, den Sie gebeten haben, den neuen Workflow zu testen.

Können wir es auf einer Staging- oder UAT-Version ausführen, die nicht öffentlich ist?

Ja – genau für diese Konfiguration ist die Always-On-Funktion gedacht. Es handelt sich um ein einzelnes Skript-Tag auf der Entwicklungs-, Staging- oder UAT-Umgebung. Die Aufzeichnung ist auf die verifizierten Domains beschränkt, sodass ein Staging-Host genauso in diese Liste aufgenommen wird wie ein Produktionshost. Der Ablauf für den Tester ändert sich in den verschiedenen Umgebungen nicht.

Was passiert mit einem Ticket, das der Agent nicht bearbeiten kann?

Es landet wieder bei Ihrem Team, anstatt zu einem plausibel wirkenden Pull Request zu werden, den niemand angefordert hat. Wenn im Code keine Hinweise gefunden werden, die mit den aufgezeichneten Daten übereinstimmen, stoppt der Agent und übermittelt seine Ergebnisse und den Suchort. Dieser Durchlauf wird mit der Hälfte der Kosten abgerechnet. Die aufgezeichnete Sitzung bleibt in jedem Fall erhalten, sodass ein Fehler, den der Agent nicht erkennt, nicht zu einem Verlust der Beweise führt.

Woher diese Details stammen

Diese Seite enthält keinerlei Angaben zu anderen Produkten – alle Informationen stammen von Snag. Ist etwas veraltet? Schreiben Sie eine E-Mail an admin@dvcllc.io, und wir korrigieren es.