Testy automatyczne aplikacji webowej to skrypty, które po każdej zmianie w kodzie same sprawdzają, czy najważniejsze funkcje nadal działają. W umowie z software housem dobrze mieć co najmniej trzy rzeczy: testy jednostkowe, testy end-to-end dla krytycznych ścieżek i uruchamianie ich w pipeline CI. Ten poradnik piszę dla zamawiającego, który nie czyta kodu, a mimo to musi ocenić wycenę i zakres testów. Znajdziesz tu rodzaje testów opisane prostym językiem, kolejność automatyzacji i listę pytań do wykonawcy.
Table of contents
Czym są testy automatyczne aplikacji webowej i po co zamawiającemu?
To kod, który sprawdza inny kod. Odpala się sam, bez testera klikającego po ekranach. Tester ręczny za każdym razem przechodzi scenariusz od nowa, a przy częstych zmianach po prostu nie nadąża (albo coś pomija, bo jest piątek po 16:00). Automat powtarza te same kroki identycznie, w kilka minut, przy każdej poprawce. Co z tego ma firma? Mniej błędów na produkcji, spokojniejsze wdrażanie nowych funkcji i łatwiejszą zmianę wykonawcy w przyszłości, bo nowy zespół od razu widzi, co psuje. Testy to część jakości, nie dodatek. A ich pominięcie to jeden z typowych problemów, o których piszemy przy temacie błędy przy tworzeniu aplikacji.
Rodzaje testów: jednostkowe, integracyjne, end-to-end i regresji
Każdy rodzaj sprawdza aplikację na innym poziomie, od pojedynczej funkcji po całą ścieżkę użytkownika. Różnice trzeba znać, bo w ofertach nazwy często lecą zamiennie:
- Testy jednostkowe - sprawdzają jedną funkcję w izolacji, np. wyliczenie ceny z rabatem. Działają w ułamkach sekundy. Piszą je programiści, często w narzędziach takich jak PHPUnit albo Jest.
- Testy integracyjne - weryfikują, jak elementy ze sobą współpracują: aplikacja z bazą danych, z bramką płatności, z zewnętrznym API. Są wolniejsze, bo angażują kilka systemów naraz.
- Testy end-to-end (E2E) - udają człowieka w przeglądarce i przechodzą całą ścieżkę, od kliknięcia do wyniku. Przykładowe narzędzia to Playwright i Cypress. Trwają najdłużej, piszą je programiści albo testerzy automatyzujący.
- Testy regresji - to nie osobna technika, tylko cel: upewnić się, że nowa zmiana nie zepsuła czegoś, co działało. Realizuje go komplet powyższych testów puszczonych razem.
Piramida testów: ile czego potrzeba
Zasada jest prosta. Najwięcej szybkich testów jednostkowych, mniej integracyjnych i najmniej wolnych, drogich w utrzymaniu E2E. Projekt oparty wyłącznie na E2E? Długie czekanie na wynik, testy sypiące się przy każdej zmianie wyglądu i żmudne szukanie przyczyny błędu. Same jednostkowe też nie wystarczą, bo nie wyłapią problemów na styku modułów ani w przeglądarce. I uważaj na procent pokrycia kodu wpisany do umowy jako norma. Mówi on tylko, ile kodu zostało uruchomione. Nie mówi, czy sprawdzono to, co ważne dla biznesu.
Co automatyzować najpierw? Krytyczne ścieżki aplikacji
Na start idą ścieżki, których awaria zatrzymuje biznes: logowanie, płatność, zapis danych. Moim zdaniem rozsądna kolejność wygląda tak:
- Logowanie, rejestracja i uprawnienia użytkowników.
- Płatność i składanie zamówienia (checkout).
- Zapis, edycja i odczyt kluczowych danych.
- Integracje z systemami zewnętrznymi.
- Obliczenia biznesowe: ceny, rabaty, podatki.
A z czym poczekać? Z ekranami, które na etapie MVP zmieniają się co tydzień, z samą warstwą graficzną i z funkcjami jednorazowymi. Szkoda czasu. Zakres testów ma rosnąć razem z produktem, co dobrze widać, gdy przejrzysz etapy budowy aplikacji webowej od pierwszej wersji do skali.
Kiedy testy się uruchamiają: testy w CI/CD
W porządnie ustawionym projekcie testy startują same przy każdej zmianie w repozytorium, w pipeline CI, zanim kod trafi na serwer. CI, czyli ciągła integracja, to automat: programista wysyła kod, a on buduje aplikację i odpala testy. Czerwony wynik blokuje wdrożenie. Błąd zatrzymuje się więc u programisty, a nie u klienta. Zwykle najpierw lecą szybkie testy jednostkowe, a E2E uruchamia się na środowisku testowym tuż przed publikacją na produkcji. No i przy pracy w sprintach, typowej dla podejścia zwinne zarządzanie projektami IT, pełna regresja przechodzi po każdej iteracji.
Testy automatyczne w umowie i wycenie: o co zapytać wykonawcę
Umowa powinna mówić wprost: jakie rodzaje testów powstają, które ścieżki obejmują, gdzie się uruchamiają i kto je utrzymuje po odbiorze. Przed podpisaniem zadaj software house’owi te pytania:
- Jakie testy są uwzględnione w wycenie?
- Które ścieżki dostaną testy E2E?
- Czy testy działają w CI i blokują wdrożenie przy błędzie?
- Czy otrzymam kod testów i dostęp do ich wyników?
- Kto aktualizuje testy przy zmianach w aplikacji?
- Jak wygląda środowisko testowe i skąd pochodzą w nim dane?
Czerwone lampki? Odpowiedź „testujemy ręcznie przed wdrożeniem” bez żadnej automatyzacji. Brak testów w repozytorium. Testy wyceniane jako płatny dodatek bez określonego zakresu. W praktyce zakres testów najlepiej omówić już przy pierwszej rozmowie o projekcie, obojętnie, czy chodzi o tworzenie oprogramowania na zamówienie, czy o aplikacje oparte na AI.
Testy automatyczne aplikacji webowej mają być zapisem w umowie, a nie ustną obietnicą. Minimum jest krótkie: testy jednostkowe dla logiki biznesowej, testy end-to-end dla krytycznych ścieżek i całość odpalana w CI przy każdej zmianie. Z takim zapisem łatwiej porównać oferty, odebrać projekt i spokojnie go rozwijać.
Najczęstsze pytania
Czy mała aplikacja lub MVP potrzebuje testów automatycznych?
Tak. Przynajmniej dla logowania, płatności i zapisu danych, bo ich awaria od razu uderza w użytkowników. Resztę można objąć testami później, gdy produkt się ustabilizuje. Taki skromny zestaw chroni najważniejsze ścieżki bez dużego kosztu na starcie.
Czym różnią się testy end-to-end od testów jednostkowych?
E2E sprawdzają całą ścieżkę użytkownika w przeglądarce, jednostkowe pojedynczą funkcję w izolacji. Pierwsze pokazują, że proces działa jako całość. Drugie szybko wskazują, która część logiki zawiodła. Potrzebne są oba rodzaje, nie ma co wybierać.
Kto utrzymuje testy po oddaniu aplikacji?
Zależy od umowy, więc lepiej to w niej doprecyzować. Dobry zapis: testy są częścią kodu przekazywanego zamawiającemu i są aktualizowane przy każdej zmianie w ramach wsparcia. Dzięki temu nie tracą wartości po pierwszych poprawkach.
