Zdarzyło mi się to już kilkanaście razy. Pracuję nad stroną, wszystko działa, a potem jeden mały commit wywala układ wizualny. Klient dzwoni, że przycisk zniknął albo tekst nachodzi na obrazek. I zaczyna się gonitwa. Przez lata nauczyłem się, że projektowanie stron to nie tylko pisanie kodu, ale też planowanie testów. Gdy brakuje porządnego środowiska do sprawdzania poprawek, drobny błąd potrafi kosztować godziny debugowania. Dlatego coraz częściej polecam korzystanie ze sprawdzonych narzędzi, takich jak www.swlab.pl, które oferują laboratoria testowe dla aplikacji webowych. Bez nich łatwo wpaść w pułapkę chaotycznej weryfikacji.
Jak jedna linijka kodu rozwala responsywność
Pamiętam projekt sklepu internetowego. Klient poprosił o zmianę marginesu w stopce. Wpisałem nową wartość, zapomniałem sprawdzić na tablecie. Efekt? Na ekranie 768 pikseli stopka zakrywała ostatni produkt. Zajęło mi to trzy godziny, żeby znaleźć, że brakowało media query. Takie sytuacje pokazują, że poprawki kosmetyczne wymagają takiej samej uwagi jak nowe funkcjonalności. Nawet zmiana paddingówwymusza przetestowanie w kilku rozdzielczościach.
Dlaczego sam blind test nie wystarczy
Wielu developerów testuje tylko na swoim laptopie. To błąd. U siebie wszystko działa, na produkcji nie. Różne przeglądarki, różne wersje silników, różne rozmiary ekranów. Jeden projekt, który prowadziłem, miał błąd tylko w Safari na macOS Monterey. Klient go nie widział, u mnie działało, ale użytkownicy zgłaszali problem. Bez dostępu do środowiska testowego z różnymi konfiguracjami takie błędy wychodzą dopiero po wdrożeniu. To kosztuje.
Automatyzacja testów wizualnych to nie fanaberia
Firmy, które robią wdrożenia co tydzień, potrzebują narzędzi do porównywania zrzutów ekranu. Ręczne przeglądanie każdej strony po zmianie to syzyfowa praca. Automatyzacja pozwala wychwycić, że przycisk przesunął się o jeden piksel albo czcionka zmieniła rozmiar. W praktyce używałem skryptów, które porównywały 200 ekranów w 10 minut. Ludzkie oko nie wyłapie takiej ilości szczegółów bez wsparcia.
Błędy wynikające z lokalnych konfiguracji
Kiedyś dostałem zgłoszenie, że formularz kontaktowy nie wysyła danych. Na moim serwerze lokalnym działał. Okazało się, że klient miał ustawioną strefę czasową UTC+2, a serwer UTC. Różnica powodowała rozjazd w zapisie daty. Taka historia to norma. Nie chodzi tylko o strefy, ale też o wersje PHP, moduły serwera, ustawienia plików. Każda z tych zmiennych może wywrócić aplikację. Bez środowisk izolowanych od lokalnych zmiennych nie da się tego przewidzieć.
Testowanie to nie sprawdzanie, czy kod dziala. To odkrywanie, gdzie kod przestaje dzialac, zanim odkryją to uzytkownicy.
Dlaczego zespoły powinny dzielić odpowiedzialność za testy
Często widzę, że testy wykonuje tylko jedna osoba. To ryzykowne. Programista nie widzi swoich błędów, bo je zakodował. Kolega z zespołu może je wyłapać, ale jeśli ma podobny sprzęt, też nie zobaczy problemu z rozdzielczością. Lepsze jest testowanie rotacyjne – każdy członek zespołu przez godzinę sprawdza w środowisku, które nie jest mu znajome. W jednym z teamów, które prowadziłem, wprowadziliśmy zasadę, że przed releaseem testuje zawsze ktoś, kto nie pisał kodu. Liczba błędów produkcyjnych spadła o połowę.
Praktyczne kroki do poprawy jakości kodu
Zacznij od prostej listy kontrolnej. Przed każdym wdrożeniem sprawdź: czy zmiana działa na trzech różnych przeglądarkach, czy na dwóch systemach operacyjnych, czy na ekranie o szerokości 320 i 1440 pikseli. Jeśli używasz frameworka, włącz tryb reaktywny. Nie pomijaj testów na urządzeniach mobilnych z niższej półki, bo tam często występują opóźnienia i słaba obsługa CSS. Zapisuj błędy w repozytorium, nawet te drobne. Po miesiącu zobaczysz, które komponenty najczęściej się psują. To daje konkretne dane do planowania poprawek.
Koszt pośpiechu w testowaniu
Presja czasu zawsze jest duża. Klient chce wdrożyć w piątek, bo ma szefa. Deweloper skraca testy, bo myśli, że to pojedyncza linijka. A potem w poniedziałek wpada alert o błędzie krytycznym. W jednej firmie, w której pracowałem, pośpiech spowodował, że zmiana w pliku CSS zepsuła cały layout na stronie produktowej przez weekend. Straty finansowe były liczone w tysiącach złotych. Lepiej opóźnić release o jeden dzień niż ryzykować awarię. Testowanie to inwestycja, a nie wydatek.