Testy automatyczne to powód, dla którego zmiana na stronie za rok nie zepsuje formularza kontaktowego, koszyka ani numeru telefonu. Przed każdą publikacją program przechodzi przez stronę tak jak klient i sprawdza, czy to, co przynosi zapytania, nadal działa. Jeśli nie, zmiana nie trafia do sieci.
Piszę dla osoby, która za stronę płaci, nie dla tej, która ją buduje, więc nie ma tu kodu, a narzędzia pojawiają się tylko z nazwy. Chodzi o to, co zmienia się dla firmy, kiedy wykonawca mówi „strona ma testy automatyczne”, i jak sprawdzić, czy to prawda.
Co właściwie sprawdza test
Test automatyczny to krótki scenariusz zapisany raz, który komputer powtarza przy każdej zmianie. Na stronie firmowej zwykle wygląda tak:
- Otwórz stronę główną i sprawdź, czy się wyświetla.
- Wejdź w kontakt, wypełnij formularz, wyślij go i sprawdź, czy pojawiło się potwierdzenie.
- Sprawdź, czy numer telefonu w nagłówku da się kliknąć i czy prowadzi do właściwego numeru.
- W sklepie: dodaj produkt do koszyka, przejdź do zamówienia, sprawdź, czy suma się zgadza.
- Otwórz to samo na szerokości telefonu i sprawdź, czy menu się rozwija.
Nic z tego nie jest skomplikowane. Różnica jest taka, że człowiek robi to raz, przy oddaniu strony, a test za każdym razem, bez zmęczenia i bez pomijania kroków, „bo przecież tego nie ruszałem”.
Rodzaje testów automatycznych: od jednej funkcji po całą ścieżkę klienta
Scenariusz w stylu „otwórz stronę, wyślij formularz, sprawdź koszyk” to tak zwane testy E2E (od end-to-end, „od początku do końca”): program otwiera prawdziwą przeglądarkę i przechodzi ścieżkę klienta. Dobry zestaw łączy kilka rodzajów testów:
- Testy jednostkowe sprawdzają jedną małą część w oderwaniu od reszty, na przykład czy cena z VAT liczy się poprawnie albo czy numer telefonu ma właściwy format. Trwają ułamki sekundy, więc może ich być dużo.
- Testy backendowe (zaplecza) sprawdzają to, czego klient nie widzi: czy zamówienie zapisało się w bazie, czy wysłał się mail z potwierdzeniem, czy uprawnienia puszczają tylko tych, których powinny.
- Testy E2E sprawdzają całość oczami klienta. Są najbliżej prawdziwego użycia, ale też najwolniejsze i najbardziej kapryśne, więc warto je mieć tylko dla najważniejszych ścieżek.
- Testy techniczne pilnują rzeczy, które łatwo przeoczyć: martwych linków, tytułów dla Google, dostępności dla osób korzystających z klawiatury albo czytnika ekranu.
- Testy wyglądu robią zrzut każdej podstrony i porównują go z poprzednim. Wyłapują przesunięty przycisk albo zniknięte zdjęcie, których żaden inny test nie zauważy.
W Google, według książki Software Engineering at Google, mniej więcej 80% testów to małe testy jednostkowe, 15% testy średniej wielkości, a tylko 5% testy E2E. Mała strona nie musi trzymać się tych proporcji, ale kierunek warto zachować: dużo szybkich testów, kilka wolnych.
Jak to wygląda w praktyce, pokażę na czterech moich projektach:
- ZapiszPrzepis, aplikacja do zapisywania przepisów, ma ponad 70 testów jednostkowych i zestaw testów E2E. Jednostkowe stoją tam, gdzie najłatwiej o cichą pomyłkę: przy rozpoznawaniu, skąd pochodzi przepis, i przy odczytywaniu składników.
- Panel do zarządzania serwisem (klienci, pojazdy, faktury) ma testy backendowe i około 140 testów E2E. Kiedy przebudowałem sposób ich uruchamiania, cały zestaw zamiast ponad 34 minut trwa około 5. Ma to znaczenie, bo testy, na które trzeba czekać pół godziny, zaczyna się pomijać.
- spoko.space, czyli ta strona, ma głównie testy techniczne: linki, tytuły, dane dla Google, wersje językowe i dostępność w obu motywach. Piszę o nich w sekcji o tym, jak testuję własną stronę i strony klientów.
- filament-ops-notify, mój pakiet open source dla Laravela, ma 271 testów jednostkowych, które przy każdej zmianie uruchamiają się na sześciu kombinacjach wersji PHP i Laravela, w niecałą minutę.
Dlaczego zmiana za rok psuje to, czego nikt nie dotykał
Strona po oddaniu nie stoi w miejscu. Dochodzi nowa sekcja, zmienia się cennik, aktualizuje się wtyczka, ktoś podmienia zdjęcia w nagłówku. Każda z tych zmian dotyczy jednego miejsca, ale strona jest całością: te same style, te same skrypty, ten sam szablon.
Dlatego właściciele stron przychodzą do mnie najczęściej z drobną zmianą, po której przestało działać coś zupełnie gdzie indziej, a nie z awarią po dużej przebudowie. Przy naprawach WordPressa „padła po aktualizacji” to osobny punkt na liście objawów, bo zdarza się tak często.
Aktualizacji nie da się przy tym po prostu odpuścić. Według raportu Patchstack w 2025 roku w ekosystemie WordPressa znaleziono 11 334 nowe luki bezpieczeństwa, z czego 91% we wtyczkach. Oficjalna dokumentacja WordPressa radzi więc aktualizować zawsze, a przed aktualizacją zrobić kopię zapasową, żeby było do czego wrócić, kiedy coś się posypie. Sam WordPress od wersji 6.6 po automatycznej aktualizacji wtyczki sprawdza, czy strona główna nie zwraca błędu krytycznego, i jeśli zwraca, przywraca poprzednią wersję wtyczki. To dobre zabezpieczenie, ale sprawdza tylko jedno: czy strona główna w ogóle się otwiera. Formularz, który przestał wysyłać wiadomości, przechodzi przez nią bez problemu.
Najgorsze w usterkach po aktualizacji jest to, że są ciche. Strona się wyświetla, wygląda dobrze, tylko formularz od dwóch tygodni nie wysyła wiadomości. Właściciel dowiaduje się o tym dopiero, kiedy klient dzwoni z pytaniem, dlaczego nikt nie odpisał, albo nie dowiaduje się wcale, bo klient poszedł do konkurencji.
Testy przy każdym wdrożeniu
Ręczne sprawdzenie strony przed publikacją to dobry zwyczaj, ale ma dwie słabości. Pierwsza: ktoś musi o nim pamiętać, także przy poprawce literówki w piątek o 17:00. Druga: sprawdza się to, co się zmieniło, a psuje się zwykle coś obok.
Testy automatyczne uruchamiają się same, zanim zmiana trafi na działającą stronę, i sprawdzają zawsze ten sam komplet, niezależnie od tego, jak mała była poprawka. Jeśli któryś nie przejdzie, publikacja się zatrzymuje, a klienci dalej widzą poprzednią, działającą wersję.
Nie wymyśliłem tego sam. Program badawczy DORA, prowadzony przez Google Cloud, podaje, że testy uruchamiane przy każdej zmianie przekładają się na mało błędów w wersji, z której korzystają klienci, i na spokojniejsze wdrożenia.
To samo dotyczy aktualizacji. Nową wersję wtyczki albo systemu można najpierw przepuścić przez testy na kopii strony. Jeśli psuje formularz, dowiaduję się o tym ja, a nie klient, który próbował wysłać zapytanie.
Rachunek: błąd u klientów kontra test napisany raz
Nie podam tu uniwersalnej kwoty, bo każda firma liczy inaczej. Rachunek da się jednak zrobić samemu, w dwóch kolumnach:
| Błąd, który trafił do klientów | Test, który go zatrzymał | |
|---|---|---|
| Kiedy go widać | Gdy ktoś zauważy, czasem po tygodniach | Przed publikacją, w kilka minut |
| Kto płaci | Ty: w zapytaniach, które nie doszły | Wykonawca: czas na napisanie testu |
| Ile razy | Przy każdej kolejnej usterce od nowa | Raz, potem test pilnuje przy każdej zmianie |
| Co zostaje | Klient, który uznał, że firma nie odpisuje | Nic, klient nie wie, że był problem |
Żeby policzyć lewą kolumnę dla swojej firmy, wystarczą dwie liczby: ile zapytań tygodniowo przychodzi przez formularz i ile warte jest przeciętne zlecenie. Pomnóż to przez liczbę tygodni, przez które formularz mógłby milczeć, zanim ktoś to zauważy (kiedy ostatnio sam wysłałeś zapytanie przez własną stronę?). Wynik zwykle jest wyższy niż koszt napisania kilku testów dla najważniejszych ścieżek.
W sklepie dochodzą klienci, którzy trafią na błąd i po prostu wyjdą. Baymard Institute, który od lat bada zakupy w internecie, podaje, że 13% kupujących porzuciło koszyk, bo strona miała błędy albo się zawiesiła.
Najlepiej udokumentowany przykład na to, że testy automatyczne się opłacają, ma Google. W 2005 roku zespół serwera, który obsługuje zapytania do wyszukiwarki Google, miał problem: ponad 80% publikacji zawierało błędy widoczne dla użytkowników i trzeba je było wycofywać. Wprowadzono zasadę, że każda zmiana musi mieć testy, a testy uruchamiają się stale. W ciągu roku liczba awaryjnych poprawek spadła o połowę, choć zmian było więcej niż kiedykolwiek. Tak opisuje to książka Software Engineering at Google. Twoja strona jest nieporównywalnie mniejsza, ale psuje się w ten sam sposób.
Tabela nie pokazuje jeszcze jednego: za rok ani ja, ani ktokolwiek inny nie będzie pamiętał, że zmiana w stopce kiedyś zepsuła przycisk w koszyku. Test będzie.
Jak testuję własną stronę i strony klientów
Ta strona, spoko.space, nie trafia do sieci, dopóki nie przejdzie kompletu sprawdzeń. Przed każdą publikacją automatycznie sprawdzam, czy żaden link nie prowadzi donikąd, czy każda podstrona ma poprawny tytuł i opis dla Google, czy wersja polska i angielska wskazują na siebie nawzajem i czy strona jest czytelna i obsługiwalna z klawiatury, w jasnym i w ciemnym motywie. Jeśli którekolwiek z tych sprawdzeń nie przejdzie, zmiana czeka, aż ją poprawię. Co dokładnie mierzę w części o dostępności, opisuję na stronie o dostępności WCAG.
Te sprawdzenia nie raz zatrzymały moją własną zmianę, która na oko wyglądała dobrze.
Przy stronach i aplikacjach webowych klientów zakres testów automatycznych dobieram do tego, co w danej firmie przynosi pieniądze: w pensjonacie będzie to formularz rezerwacji i telefon, w sklepie koszyk i zamówienie, w firmie usługowej formularz wyceny. Tych kilka ścieżek sprawdzam automatycznie przy każdej zmianie, także długo po oddaniu strony.
Testy w czasach AI: łatwo o dużo, trudniej o dobre
AI napisze dziś setki testów w godzinę, więc testów rzadko brakuje. Częściej jest ich niepotrzebnie dużo, a część sprawdza nie to, co trzeba.
Wynik „na zielono” nie zawsze znaczy, że strona działa. Test może przejść, bo sprawdza, że formularz się wyświetla, a nie że wiadomość dochodzi do skrzynki. Może też sprawdzać coś tak ogólnego, że przejdzie zawsze, cokolwiek się zepsuje. Taki test jest gorszy niż brak testu, bo daje spokój, na który nikt nie zapracował.
Dlatego same testy też trzeba przeglądać, tak samo jak kod strony. Przy testach napisanych z pomocą AI najpierw sprawdzam, czy test w ogóle potrafi się nie udać: psuję na chwilę to, czego pilnuje, i patrzę, czy to zauważy. Jeśli nie zauważy, test idzie do poprawki albo do kosza.
Liczba testów też ma swoją cenę. Setka testów sprawdzających to samo na różne sposoby wydłuża każdą publikację i nic nie dodaje. Kilka dobrze wybranych, które pilnują formularza, telefonu i koszyka, jest warte więcej niż kilkaset przypadkowych.
Gdzie i kiedy uruchamiać testy
To, gdzie i kiedy testy się uruchamiają, jest równie ważne jak to, co sprawdzają. Najprościej uruchamiać wszystko w chmurze przy każdej zmianie, na przykład w GitHub Actions. Przy większym zestawie to jednak albo sporo kosztuje, albo szybko kończą się darmowe limity. Znam to z własnego konta: kiedy darmowe minuty się skończą, testy w chmurze w ogóle nie startują, a zmiany dalej trzeba jakoś sprawdzać.
Dlatego dzielę testy na trzy poziomy:
- Szybkie, przed każdym wysłaniem zmian. Uruchamiają się same na moim komputerze (tzw. hook, np. przez Husky), zanim zmiana w ogóle opuści komputer. Trwają kilka minut: budowanie strony, sprawdzenie linków, tytułów i testy najważniejszych funkcji.
- Wolne, przed połączeniem zmiany z wersją, która idzie do sieci. Pełne sprawdzenie dostępności wszystkich podstron w obu motywach trwa u mnie około pół godziny, więc nie odpalam go przy każdej literówce, tylko raz, zanim zmiana trafi na stronę.
- Na działającej stronie, po publikacji. Krótkie sprawdzenie konkretnej ścieżki tam, gdzie korzystają z niej klienci. Wersja robocza bywa wolna albo działa inaczej niż produkcyjna (inny serwer, inna pamięć podręczna), więc niektóre przypadki da się wiarygodnie sprawdzić dopiero na żywej stronie.
Pytania do wykonawcy przed podpisaniem umowy
Nie trzeba znać się na programowaniu, żeby ocenić odpowiedź. Zadaj je każdemu wykonawcy, także mnie:
- Co na mojej stronie jest sprawdzane automatycznie? Dobra odpowiedź wymienia konkretne rzeczy: formularz, telefon, koszyk, logowanie. Słaba to „testujemy wszystko” albo „sprawdzam na kilku przeglądarkach” (to też ważne, ale to test ręczny, jednorazowy).
- Co się dzieje, gdy test nie przejdzie? Chcesz usłyszeć, że zmiana wtedy nie trafia na stronę. Jeśli test tylko wysyła komuś maila, który można zignorować, to połowa ochrony.
- Czy testy działają też po oddaniu strony? Testy, które uruchomiono raz przed startem i nigdy więcej, nie ochronią Cię przed zmianą za rok.
- Jak wygląda aktualizacja wtyczek i systemu? Najpierw na kopii, przez testy, potem na działającej stronie? Czy prosto na żywym organizmie?
- Kto sprawdza same testy? Jeśli pisze je AI, ktoś powinien je przejrzeć i upewnić się, że test potrafi się nie udać. Samo „wszystko na zielono” niczego nie dowodzi.
- Co dostanę, jeśli kiedyś zmienię wykonawcę? Testy powinny być częścią strony, którą dostajesz, tak jak kod, żeby nie odeszły razem z wykonawcą.
Więcej pytań, które warto zadać przed wyborem, zebrałem w tekście jak wybrać web developera.
Czego testy nie wyłapią
Testy pilnują, żeby działało to, co już działało. To dużo, ale nie wszystko.
- Złej decyzji projektowej. Jeśli przycisk „Zadzwoń” jest schowany na dole strony, test sprawdzi, że działa. Nie powie, że nikt go nie znajdzie.
- Słabego tekstu. Test nie oceni, czy opis oferty przekonuje, ani nie wyłapie literówki w cenie, jeśli nikt mu nie kazał sprawdzać tej konkretnej kwoty.
- Rzeczy, których nikt nie opisał. Test sprawdza tylko scenariusze, które ktoś zapisał. Dlatego wybór, co testować, jest ważniejszy niż liczba testów. Edsger Dijkstra, jeden z pionierów informatyki, ujął to w 1969 roku jednym zdaniem: testy pokazują obecność błędów, nigdy ich brak.
- Problemów poza stroną. Jeśli skrzynka mailowa, na którą trafiają zapytania, jest pełna, formularz wyśle wiadomość poprawnie, a Ty i tak jej nie przeczytasz.
Nawet Google przyznaje, że nie wszystko da się sprawdzić automatycznie, a o jakości wyników wyszukiwania często decyduje ocena człowieka. Testy nie zastępują więc kogoś, kto patrzy na stronę oczami klienta, tylko zdejmują z niego najnudniejszą część pracy: przeklikiwanie tego samego po każdej zmianie.
Podsumowanie
- Test automatyczny to scenariusz zapisany raz, który przy każdej zmianie sprawdza formularz, telefon, koszyk i inne ścieżki przynoszące klientów.
- Najdroższe usterki to te ciche: strona wygląda dobrze, a formularz od tygodni nie wysyła wiadomości.
- Testy automatyczne działają tylko wtedy, gdy uruchamiają się przy każdym wdrożeniu i zatrzymują zmianę, która coś psuje, także po oddaniu strony.
- Ważniejsze od liczby testów jest to, co sprawdzają. Testy pisane z AI trzeba przeglądać, a zielony wynik nie zawsze znaczy, że strona działa.
- Przed podpisaniem umowy zapytaj, co jest sprawdzane automatycznie, kto sprawdza same testy i co się dzieje, gdy test nie przejdzie.
- Testy nie ocenią projektu ani tekstu, to zostaje pracą dla człowieka.
Jeśli masz stronę, która już raz „padła po aktualizacji”, albo planujesz nową i chcesz, żeby następna zmiana jej nie zepsuła, zobacz, jak buduję strony.
