Gdy aplikacja działa poprawnie na komputerze twórcy, to jeszcze nie znaczy, że poradzi sobie z ruchem użytkowników, integracją z płatnościami albo zmianą przeglądarki. Najczęściej spotykane rodzaje testów oprogramowania różnią się zakresem, celem i momentem wykonania, dlatego pokażę, jak je rozumieć oraz kiedy naprawdę mają sens. Znajdziesz tu także praktyczne porównanie testów manualnych i automatycznych, przykład piramidy testów oraz wskazówki dotyczące wyboru odpowiedniej strategii.
Najważniejsze informacje o testowaniu aplikacji
- Cztery poziomy obejmują testy jednostkowe, integracyjne, systemowe i akceptacyjne.
- Testy funkcjonalne sprawdzają, co system robi, a niefunkcjonalne oceniają, jak dobrze to robi.
- Testy regresji upewniają się, że poprawka lub nowa funkcja nie zepsuła istniejących elementów.
- Automatyzacja najlepiej sprawdza się przy powtarzalnych scenariuszach, ale nie zastępuje testów eksploracyjnych.
- Piramida testów pomaga utrzymać dużą liczbę szybkich testów niskiego poziomu i mniejszą liczbę kosztownych testów end-to-end.
Jak porządkować testy oprogramowania
Jedna lista nazw szybko prowadzi do chaosu, bo ten sam test może być jednocześnie funkcjonalny, automatyczny, czarnoskrzynkowy i systemowy. Dlatego ja porządkuję testowanie według kilku niezależnych kryteriów. Najpierw pytam, co jest testowane, potem po co wykonujemy test, a na końcu sprawdzam, kto i w jaki sposób go uruchomi.
Najważniejszy podział dotyczy poziomu testowania. Opisuje on zasięg sprawdzenia, od pojedynczej funkcji w kodzie aż po kompletny produkt używany przez klienta. Drugi podział dotyczy jakości, czyli funkcji, wydajności, bezpieczeństwa czy użyteczności. Trzeci mówi o sposobie poznania systemu oraz o tym, czy test wykonuje człowiek, czy narzędzie.
| Kryterium | Przykładowe kategorie | Główne pytanie |
|---|---|---|
| Poziom | Jednostkowe, integracyjne, systemowe, akceptacyjne | Jak duży fragment rozwiązania sprawdzamy? |
| Cel | Funkcjonalne, wydajnościowe, bezpieczeństwa, użyteczności | Jaką cechę systemu oceniamy? |
| Dostęp do wnętrza systemu | Czarnoskrzynkowe, białoskrzynkowe, szaroskrzynkowe | Ile wiemy o kodzie i architekturze? |
| Sposób wykonania | Manualne, automatyczne | Kto wykonuje scenariusz? |
Poziomy testowania od kodu do pełnego produktu
Testy jednostkowe
Test jednostkowy sprawdza mały, możliwie niezależny fragment programu, na przykład funkcję obliczającą rabat albo moduł walidujący numer telefonu. Zwykle tworzy go programista, a jego wykonanie trwa bardzo krótko. Dzięki temu błąd można wykryć jeszcze zanim kod trafi do wspólnego repozytorium.
To najtańszy etap naprawy defektu, ale ma ograniczenie. Test jednostkowy może potwierdzić, że funkcja działa poprawnie w izolacji, lecz nie powie, czy aplikacja prawidłowo połączy ją z bazą danych, API lub interfejsem użytkownika.
Testy integracyjne
Testy integracyjne sprawdzają współpracę kilku komponentów. Przykładem jest rejestracja konta, podczas której formularz przekazuje dane do API, API zapisuje je w bazie, a system wysyła wiadomość e-mail. Każdy element może działać osobno, a mimo to cały przepływ może się załamać na styku.
W praktyce szczególnie dużo problemów pojawia się przy niezgodnych formatach danych, autoryzacji i obsłudze błędów. Dlatego nie ograniczałbym testów integracyjnych do samego sprawdzenia, czy usługa odpowiada kodem HTTP 200. Trzeba jeszcze ocenić, czy zwraca właściwe dane i poprawnie reaguje na awarie zależności.
Testy systemowe i end-to-end
Test systemowy obejmuje działanie aplikacji jako całości w środowisku zbliżonym do docelowego. Test end-to-end idzie jeszcze dalej i odtwarza pełną ścieżkę użytkownika, na przykład od wyszukania produktu do opłacenia zamówienia i otrzymania potwierdzenia.
Takie testy dają dużą pewność, że najważniejszy scenariusz biznesowy działa, ale są wolniejsze, droższe w utrzymaniu i bardziej podatne na niestabilność. Zmiana tekstu przycisku, opóźnienie zewnętrznego API albo problem z przeglądarką może spowodować fałszywe niepowodzenie. Z tego powodu nie budowałbym całej strategii wyłącznie na testach end-to-end.
Przeczytaj również: Testy alfa - Jak uniknąć drogich błędów w oprogramowaniu?
Testy akceptacyjne
Testy akceptacyjne odpowiadają na pytanie, czy rozwiązanie spełnia potrzeby biznesowe i może zostać przyjęte przez zamawiającego lub użytkowników. Mogą obejmować zarówno scenariusze wykonywane przez klienta, jak i automatyczne testy akceptacyjne zapisane językiem biznesowym.
Przykład jest prosty. System może prawidłowo obliczać cenę koszyka, ale nie spełniać zasady biznesowej, według której darmowa dostawa przysługuje dopiero od określonej wartości zamówienia. Test akceptacyjny ujawnia właśnie takie rozbieżności między techniczną poprawnością a oczekiwanym działaniem produktu.
Testy funkcjonalne i niefunkcjonalne odpowiadają na różne pytania
Testy funkcjonalne sprawdzają, co system powinien robić. Obejmują między innymi logowanie, wyszukiwanie, naliczanie opłat, filtrowanie wyników i obsługę ról użytkowników. Ich podstawą są wymagania, reguły biznesowe oraz scenariusze użycia.
Testy niefunkcjonalne oceniają, jak dobrze system działa. Ta grupa obejmuje cechy, które często decydują o tym, czy użytkownik zostanie z produktem na dłużej.
| Typ testu | Co sprawdza | Przykład |
|---|---|---|
| Wydajnościowe | Czas odpowiedzi i zachowanie pod obciążeniem | Jak aplikacja działa przy 10 000 równoczesnych użytkowników? |
| Bezpieczeństwa | Odporność na nieuprawniony dostęp i nadużycia | Czy użytkownik może zobaczyć dane innego konta? |
| Użyteczności | Łatwość wykonania zadania i zrozumiałość interfejsu | Czy nowa osoba potrafi złożyć zamówienie bez instrukcji? |
| Kompatybilności | Działanie w różnych środowiskach | Czy aplikacja działa w popularnych przeglądarkach i na telefonie? |
| Niezawodności | Stabilność i zdolność do pracy bez awarii | Czy system poprawnie wraca do działania po utracie połączenia? |
Nie traktuję testów niefunkcjonalnych jako dodatku na sam koniec projektu. Jeśli aplikacja ma obsługiwać płatności, duży ruch albo dane wrażliwe, wydajność i bezpieczeństwo powinny pojawić się w planie od początku. Późne wykrycie problemu z architekturą bywa znacznie droższe niż poprawienie pojedynczej funkcji.
Czarna, biała i szara skrzynka w praktyce
Testowanie czarnoskrzynkowe odbywa się bez analizowania wewnętrznej budowy programu. Tester podaje dane wejściowe i sprawdza rezultat, tak jak zrobiłby to użytkownik. Ta metoda dobrze pasuje do testów funkcjonalnych, akceptacyjnych i wielu testów API.
Testowanie białoskrzynkowe wykorzystuje wiedzę o kodzie, przepływach danych i architekturze. Najczęściej wiąże się z testami jednostkowymi, pokryciem instrukcji lub gałęzi decyzyjnych. Samo wysokie pokrycie kodu nie gwarantuje jakości, ponieważ można pokryć kod testami, które sprawdzają niewłaściwe założenia.
Pomiędzy tymi podejściami znajduje się testowanie szaroskrzynkowe. Tester zna część architektury, na przykład sposób działania cache, strukturę bazy albo zasady autoryzacji, ale ocenia system z perspektywy jego zewnętrznego zachowania. To przydatne połączenie, gdy trzeba przygotować realistyczne scenariusze bez zagłębiania się w każdą linię kodu.
Regresja, smoke i testy eksploracyjne
Po każdej zmianie warto sprawdzić dwa różne obszary. Test potwierdzający odpowiada na pytanie, czy konkretna poprawka usunęła zgłoszony błąd. Test regresji sprawdza, czy ta sama zmiana nie zepsuła innych funkcji.
Jeśli poprawiono naliczanie podatku, test potwierdzający obejmie właściwe wyliczenie dla danego przypadku. Regresja powinna dodatkowo sprawdzić koszyk, fakturę, zwroty i raporty finansowe. Te scenariusze często warto automatyzować, bo wracają przy kolejnych wdrożeniach.
Testy smoke to krótki zestaw kontroli, który szybko pokazuje, czy wersja nadaje się do dalszego testowania. Sprawdza się na przykład uruchomienie aplikacji, logowanie, dostęp do głównego widoku i wykonanie podstawowej operacji. Gdy smoke test kończy się niepowodzeniem, szczegółowe testowanie zwykle nie ma jeszcze sensu.
Testowanie eksploracyjne pozostawia testerowi więcej swobody. Zamiast odtwarzać wyłącznie gotowe przypadki, tester poznaje system, stawia hipotezy i reaguje na obserwacje. W mojej praktyce jest szczególnie cenne przy nowych funkcjach, nietypowych interfejsach i miejscach, w których dokumentacja nie nadąża za produktem.
Manualne czy automatyczne testy
Testy manualne wykonuje człowiek, który analizuje zachowanie aplikacji i może od razu zauważyć coś nieoczywistego, na przykład mylący komunikat albo nienaturalny przebieg procesu. Ich mocną stroną jest elastyczność, a słabą powtarzalność i koszt wykonywania tych samych czynności przy każdej wersji.
Automatyzacja pozwala uruchamiać scenariusze szybko i regularnie, zwłaszcza w procesie CI/CD. Najlepiej automatyzować testy częste, stabilne i jednoznaczne, takie jak walidacja API, obliczenia, reguły biznesowe czy kontrola najważniejszych ścieżek zakupowych.
| Testy manualne | Testy automatyczne |
|---|---|
| Dobrze radzą sobie z eksploracją i oceną użyteczności. | Dobrze radzą sobie z powtarzalnymi scenariuszami. |
| Łatwo dostosować je do nieoczekiwanej sytuacji. | Zapewniają szybki feedback po zmianie kodu. |
| Wymagają czasu przy każdej kolejnej wersji. | Wymagają inwestycji w kod, dane i utrzymanie. |
| Są przydatne przy nowych i niestabilnych funkcjach. | Najlepiej działają przy funkcjach o ustalonych wymaganiach. |
Automatyzowanie wszystkiego brzmi atrakcyjnie, ale często prowadzi do kruchego zestawu testów. Jeśli test wymaga wielu elementów interfejsu, zależy od czasu odpowiedzi zewnętrznej usługi i często kończy się przypadkowym błędem, jego utrzymanie może kosztować więcej niż ręczne sprawdzenie.
Jak zbudować rozsądną strategię testowania
Zaczynam od ryzyka, a nie od listy nazw. Pytam, które funkcje generują przychód, dotyczą danych osobowych, są trudne do odtworzenia po awarii albo mają największy wpływ na użytkowników. To tam powinny trafić najdokładniejsze testy.
Pomaga w tym piramida testów. Jej podstawa powinna składać się z licznych, szybkich testów jednostkowych. Wyżej umieszcza się mniejszą liczbę testów integracyjnych i systemowych, a na szczycie niewielki zestaw testów end-to-end obejmujących najważniejsze ścieżki biznesowe.
- Zdefiniuj krytyczne procesy, takie jak logowanie, płatność, wyszukiwanie lub eksport danych.
- Pokryj logikę jednostkami, aby szybko wykrywać błędy w regułach biznesowych.
- Sprawdź integracje z bazą, API, kolejkami i usługami zewnętrznymi.
- Dodaj testy systemowe dla pełnych przepływów, które naprawdę decydują o wartości produktu.
- Uruchamiaj regresję w pipeline, a wyniki analizuj zamiast ignorować niestabilne testy.
Nie przywiązuję się przesadnie do sztywnych proporcji. W aplikacji finansowej większy nacisk położę na bezpieczeństwo i spójność danych, w sklepie internetowym na zamówienia i płatności, a w aplikacji mobilnej na kompatybilność urządzeń oraz działanie przy słabym połączeniu. Dobra strategia jest dopasowana do ryzyka produktu, użytkowników i kosztu awarii.
Testowanie działa najlepiej, gdy wspiera decyzje
Najważniejszy wniosek jest prosty. Nie istnieje jeden najlepszy typ testu, który zastąpi pozostałe. Test jednostkowy daje szybki feedback, integracyjny sprawdza współpracę komponentów, systemowy ocenia cały produkt, a akceptacyjny konfrontuje go z potrzebą biznesową.
Do tego dochodzą testy funkcjonalne, niefunkcjonalne, regresyjne, eksploracyjne, manualne i automatyczne. Traktuję je jako elementy jednego systemu jakości, a nie konkurujące ze sobą opcje. Najlepszy zestaw to taki, który szybko wykrywa błędy, chroni najważniejsze procesy i nie kosztuje zespołu więcej, niż wynosi ryzyko pozostawienia problemu w produkcji.
