Testy automatyczne dzielę według tego, jak duży kawałek systemu sprawdza pojedynczy test: od jednej funkcji po cały przepływ użytkownika w przeglądarce. Im większy kawałek, tym test wolniejszy, droższy w utrzymaniu i bliższy temu, co widzi klient. Z tej zależności wynika kolejność, w jakiej wprowadzam je do projektu, który nie ma jeszcze żadnych testów.
Jakie są rodzaje automatycznych testów?
Testy jednostkowe
Sprawdzają pojedynczą funkcję albo klasę w izolacji, bez bazy danych i sieci. Wykonują się w milisekundach, więc kilka tysięcy takich testów przechodzi w minutę. Piszą je developerzy razem z kodem; jako tester pomagam ustalić, które przypadki brzegowe mają pokryć.
Testy integracyjne
Sprawdzają współpracę dwóch albo więcej elementów: kodu z bazą danych, serwisu z kolejką wiadomości, modułu z zewnętrznym API. Wyłapują błędy niewidoczne dla testów jednostkowych, które zastępują zależności atrapami (mockami). Przykład: zapytanie SQL działa na atrapie, a na prawdziwej bazie przekracza limit czasu, bo brakuje indeksu.
Testy API i kontraktowe
Wysyłają żądania do interfejsu programistycznego aplikacji i sprawdzają odpowiedzi: kody statusu, strukturę danych, reguły biznesowe. Testy kontraktowe pilnują dodatkowo, żeby zmiana w jednym serwisie nie złamała drugiego, który z niego korzysta. W systemach z mikroserwisami ten poziom testuję szerzej niż interfejs użytkownika, bo test API trwa ułamek sekundy, a sprawdza tę samą regułę biznesową co test w przeglądarce.
Testy end-to-end (E2E)
Przechodzą przez aplikację tak jak użytkownik, w prawdziwej przeglądarce: logowanie, koszyk, płatność. Dają pewność, że cały przepływ działa, ale są wolne i wrażliwe na zmiany w interfejsie. Narzędzia do takich testów porównałem w tekście Selenium czy Playwright.
Testy wizualne
Porównują zrzuty ekranu ze wzorcem, piksel po pikselu albo z ustaloną tolerancją. Łapią przesunięty przycisk i nachodzący na siebie tekst, które test funkcjonalny przepuści, bo element nadal da się kliknąć.
Testy wydajnościowe
Sprawdzają, jak system zachowuje się pod obciążeniem: czas odpowiedzi przy stu i przy tysiącu jednoczesnych użytkowników, moment, w którym pojawiają się pierwsze błędy. Opisałem je osobno przy JMeterze i przy k6 jako bramce jakości w Jenkinsie.
Testy dymne (smoke)
Krótki zestaw kilku testów uruchamiany zaraz po wdrożeniu: czy aplikacja wstaje, czy działa logowanie, czy odpowiada główne API. Po minucie wiem, czy wydanie trzeba wycofać.
Co to jest piramida testów?
Piramida testów opisuje proporcje: dużo szybkich testów jednostkowych u podstawy, mniej testów integracyjnych i API pośrodku, kilka testów E2E na szczycie. Odwrócona piramida, czyli setki testów w przeglądarce i garść jednostkowych, daje zestaw, który przechodzi godzinę i sypie się po każdej zmianie w interfejsie. W zestawach, które przejmowałem do migracji, naprawę zaczynałem od przeniesienia części sprawdzeń z przeglądarki na poziom API. Test logowania z błędnym hasłem nie potrzebuje przeglądarki, jeśli tę samą regułę da się sprawdzić jednym żądaniem.
W jakiej kolejności wdrażać testy w projekcie bez testów?
W projekcie bez żadnych testów zaczynam od szczytu piramidy, choć według samej piramidy należałoby zacząć od podstawy. Kod pisany bez testów ma zależności splątane tak, że test jednostkowy wymaga wcześniej refaktoryzacji, a refaktoryzacja bez testów to ryzyko. Kolejność wygląda u mnie tak:
- Testy dymne na środowisku testowym i produkcji. Pięć do dziesięciu testów krytycznych ścieżek, uruchamianych po każdym wdrożeniu. Pierwszy efekt widać po tygodniu.
- Testy API dla reguł biznesowych. Szybkie i stabilne, pokrywają logikę bez kruchości interfejsu.
- Wpięcie testów w CI/CD. Testy uruchamiane ręcznie, od święta, przestają działać po kilku tygodniach, bo aplikacja zmienia się szybciej niż one. Jak to zrobić, opisałem w tekście o testach automatycznych w CI/CD.
- Testy jednostkowe dla nowego kodu. Zasada dla zespołu: nowa funkcja i poprawka błędu przychodzą razem z testem. Stary kod pokrywam przy okazji zmian w nim.
- E2E dla przepływów, które przynoszą pieniądze. Rejestracja, zakup, płatność. Tylko tyle testów, ile zespół jest w stanie utrzymać.
- Testy wydajnościowe i wizualne na końcu, gdy reszta działa stabilnie.
Kto ma to wszystko pisać i utrzymywać, opisałem w tekście o roli testera automatyzującego.
Ile testów automatycznych potrzebuje projekt?
Tyle, ile zespół utrzyma bez odkładania pracy nad produktem. Liczbę testów traktuję jako wynik, a punktem wyjścia są ryzyka: które awarie kosztują firmę pieniądze albo klientów i które z nich już się zdarzały. Wolę zestaw 200 dobrze dobranych testów API i 20 testów E2E od 2000 testów w przeglądarce, z których co dziesiąty pada bez powodu: pierwszy przechodzi w kilka minut, a zespół ufa jego wynikom.
Jak pomagam w QA Sensei
Od 20 lat pracuję w IT, od siedmiu jako inżynier jakości. W Bilansie Jakości sprawdzam, jakie testy już macie, jak wygląda Wasza piramida i które poziomy zwrócą się szybciej przy obecnym budżecie. Wynik to lista kroków w kolejności, z szacunkiem pracy przy każdym. W jednym z projektów po przebudowie zestawu czas przebiegu testów w potoku spadł z ośmiu do dwóch minut. Pracuję zdalnie w całej Polsce, a we Wrocławiu i okolicach prowadzę też testy automatyczne na miejscu u klienta.