DefinicjaTesty oprogramowania to sprawdzanie, czy aplikacja albo strona działa zgodnie z założeniami. Testy automatyczne to krótkie programy, które za każdym razem w ten sam sposób sprawdzają wybrane funkcje, np. logowanie czy wyliczenie ceny, i od razu pokazują, gdy zmiana w kodzie coś zepsuła.
Po co testy, skoro programista sprawdza kod?
Bo programista sprawdza zwykle to, co właśnie zmienił, a błędy najczęściej pojawiają się gdzie indziej. Zmiana w koszyku potrafi popsuć wysyłkę faktury, a nowe pole w formularzu, z pozoru niezwiązane, potrafi zablokować rejestrację.
Testy automatyczne sprawdzają za każdym razem całość tego, co zostało nimi objęte. Im starszy i większy projekt, tym bardziej to się opłaca: po roku rozwoju nikt nie pamięta wszystkich zależności, a testy tak.
Jakie są rodzaje testów?
Najczęściej mówi się o pięciu rodzajach. Różnią się tym, jak dużą część aplikacji sprawdzają naraz, jak szybko działają i ile kosztuje ich utrzymanie.
| Rodzaj | Co sprawdza | Przykład |
|---|---|---|
| Manualne | Człowiek klika w aplikację według scenariusza albo swobodnie | Czy nowy ekran jest zrozumiały i dobrze wygląda na telefonie |
| Jednostkowe | Mały fragment kodu w izolacji, np. jedną funkcję | Czy rabat 10% od kwoty 250 zł daje 225 zł |
| Integracyjne | Współpracę kilku części, np. kodu z bazą danych albo płatnościami | Czy zamówienie zapisuje się w bazie i trafia do systemu płatności |
| E2E (end-to-end) | Całą ścieżkę użytkownika w prawdziwej przeglądarce | Rejestracja, logowanie, zakup i e-mail z potwierdzeniem |
| Wydajności | Jak aplikacja działa pod obciążeniem | Czy strona wytrzyma ruch w dniu kampanii |
Czym jest piramida testów?
To zasada, według której testów małych i szybkich powinno być dużo, a dużych i wolnych mało. Testy jednostkowe działają w ułamku sekundy, więc można ich mieć setki. Testy E2E klikają w prawdziwą przeglądarkę, są wolniejsze i łatwiej się psują przy zmianach wyglądu, dlatego obejmują tylko najważniejsze ścieżki.
Co testy dają klientowi?
Przede wszystkim spokój przy zmianach. Projekt bez testów z czasem zwalnia: każda nowa funkcja wymaga ręcznego sprawdzania wszystkiego dookoła, więc zmiany trwają dłużej i częściej coś się psuje po wdrożeniu.
- Mniej błędów u Twoich klientów: część problemów zostaje złapana, zanim ktokolwiek je zobaczy.
- Szybsze zmiany w dłuższym okresie: programista nie musi ręcznie sprawdzać całej aplikacji po każdej poprawce.
- Łatwiejsza zmiana wykonawcy: testy opisują, jak aplikacja ma działać, więc nowa osoba szybciej ją rozumie i mniej ryzykuje.
- Bezpieczniejsza praca z AI: gdy programista korzysta z narzędzi AI, testy od razu pokazują, czy wygenerowany kod niczego nie zepsuł. Więcej o tym w artykule Co to jest Claude Code?.
Ile testów to „dość”?
Tyle, żeby automatycznie sprawdzać to, co najdroższe w razie błędu: logowanie, płatności, wyliczenia cen, formularze, z których przychodzą zamówienia. Pokrycie całego kodu testami w 100% rzadko się opłaca, bo część kodu jest prosta albo często się zmienia.
Dobra miara to pytanie: „co musi działać, żeby firma zarabiała?”. Te ścieżki powinny mieć testy E2E, a logika pod spodem testy jednostkowe. Reszta zależy od budżetu i tego, jak długo aplikacja będzie rozwijana. Prosta strona firmowa nie potrzebuje rozbudowanych testów; aplikacja, z której codziennie korzystają klienci, potrzebuje.
Kiedy uruchamia się testy?
Najlepiej automatycznie przy każdej zmianie kodu. Programista zapisuje zmianę w systemie kontroli wersji, a serwer sam uruchamia testy i nie pozwala opublikować wersji, w której coś nie przechodzi. O tym, jak działa zapisywanie zmian, piszę w artykule Kontrola wersji po ludzku.
Testy manualne robi się przed ważnym wdrożeniem i po większych zmianach wyglądu. Warto, żeby uczestniczył w nich ktoś z Twojej firmy: wy najlepiej wiecie, jak klienci korzystają z aplikacji.
O co zapytać wykonawcę
- Jakie testy automatyczne będą w projekcie i co obejmą?
- Które ścieżki użytkownika będą sprawdzane testami E2E?
- Czy testy uruchamiają się same przy każdej zmianie?
- Kto i kiedy robi testy manualne przed wdrożeniem?
- Czy testy zostaną ze mną, jeśli zmienię wykonawcę?
Najczęstsze pytania
Czy testy podnoszą koszt projektu?
Na starcie tak, bo pisanie testów to dodatkowa praca. W projektach rozwijanych dłużej zwykle się zwracają: mniej błędów po wdrożeniu i szybsze zmiany. Przy prostej stronie wystarczą zwykle testy manualne i kilka automatycznych sprawdzeń.
Czy testy gwarantują, że nie będzie błędów?
Nie. Testy sprawdzają tylko to, co zostało w nich opisane. Zmniejszają ryzyko i szybko pokazują, gdy coś zepsuje się ponownie, ale nie zastąpią myślenia i testów manualnych.
Czym jest test akceptacyjny?
To sprawdzenie przez klienta, czy gotowa funkcja robi to, co było ustalone. Często odbywa się na wersji testowej aplikacji, zanim zmiana trafi do wszystkich użytkowników.