Typy testów oprogramowania: funkcjonalne, niefunkcjonalne, strukturalne i regresja

Czas czytania: około 12 minut

Testowanie oprogramowania to nie jeden zestaw czynności, lecz cała mapa różnych podejść. Każde z nich odpowiada na inne pytanie o jakość produktu. Jedno sprawdza, co system robi. Drugie, jak działa pod obciążeniem. Trzecie pilnuje, czy ostatnia poprawka nie zepsuła tego, co dotąd działało bez zarzutu. Problem w tym, że wiele zespołów myli te kategorie albo sięga po nie w złej kolejności. Skutek jest zawsze podobny: testy pochłaniają czas i budżet, a krytyczne błędy i tak docierają do użytkownika.

Ten przewodnik jest dla testerów, liderów QA, product managerów i decydentów technicznych. Pokażemy, czym różnią się główne typy testów, kiedy je stosować, w jakiej kolejności, które warto automatyzować jako pierwsze oraz jak złożyć je w spójny proces dopasowany do ryzyka i budżetu. Zamiast suchej klasyfikacji dostajecie praktyczne narzędzie do podejmowania decyzji.

Czym są typy testów oprogramowania?

Typy testów to różne sposoby sprawdzania jakości, z których każdy ma inny cel i inną perspektywę: jeden pyta „czy to działa zgodnie z wymaganiami”, drugi „czy to wytrzyma realny ruch”, a jeszcze inny „czy ktoś nie złamie zabezpieczeń”.

Słownik ISTQB definiuje typ testów jako grupę czynności testowych ukierunkowanych na konkretne cechy oprogramowania, wynikające z konkretnych celów. Najważniejsze, by nie traktować ich jak konkurujących ze sobą opcji. W dojrzałym procesie QA różne typy współistnieją i uzupełniają się na wielu poziomach. Dopiero wtedy tworzą realną siatkę bezpieczeństwa wokół produktu.

Warto rozróżnić dwa pojęcia, które bywają mylone. Poziom testów mówi o tym, kiedy w cyklu wytwórczym testujemy: jednostkowo, integracyjnie, systemowo czy akceptacyjnie, o czym piszemy w tekście Poziomy testowania oprogramowania. Typ testów mówi o tym, co i pod jakim kątem sprawdzamy. Ten sam typ testów, na przykład wydajnościowy, można uruchomić na różnych poziomach: raz jako test jednostkowy pojedynczej funkcji, raz jako test systemowy całej aplikacji.

Dlaczego zespoły mylą typy testów?

Zespoły mylą typy testów z pięciu powtarzalnych powodów: mylenie poziomu testów z typem, traktowanie testów niefunkcjonalnych jako dodatku na końcu, brak rozróżnienia regresji od retestu, testowanie wszystkiego ręcznie oraz brak powiązania testów z ryzykiem biznesowym.

Te pomyłki mają realną cenę: im później wykryty błąd, tym droższa naprawa. Błąd znaleziony na etapie wymagań kosztuje grosze, ten sam błąd u klienta kosztuje wielokrotnie więcej. Uporządkowanie typów testów to najtańszy sposób na ograniczenie tego kosztu.

Testy funkcjonalne: co robi system

Testy funkcjonalne weryfikują, czy system realizuje funkcje, które realizować powinien, na podstawie specyfikacji, wymagań biznesowych, historyjek użytkownika i przypadków użycia; obejmują testy jednostkowe, integracyjne, systemowe i akceptacyjne, a wykonuje się je ręcznie lub automatycznie.

W realnym świecie dokumentacja bywa niekompletna, nieaktualna albo jej po prostu nie ma. Najważniejsze zadanie testera to dogłębne zrozumienie wymagań, nie mechaniczne odhaczanie kroków, a wiedzę warto czerpać też z rozmów z analitykami, developerami i klientami, nie tylko z dokumentów. Przykłady funkcji sprawdzanych testami funkcjonalnymi: generowanie potwierdzenia zakupu, wystawianie faktury, naliczanie rabatu w koszyku, logowanie i odzyskiwanie hasła.

Dobry test funkcjonalny nie kończy się na ścieżce, w której wszystko idzie idealnie. Najwięcej błędów chowa się w przypadkach brzegowych: pustych polach, błędnych danych, nietypowych kombinacjach opcji, przerwanym procesie. Definicja ISTQB opisuje testy funkcjonalne jako testowanie wykonywane w celu oceny, czy komponent lub system spełnia wymagania funkcjonalne. Solidny punkt wyjścia do zaplanowania ich zakresu daje plan testów.

Testy niefunkcjonalne: jak działa system

Testy niefunkcjonalne nie sprawdzają, co system robi, lecz jak działa: wydajność, bezpieczeństwo, użyteczność, niezawodność, skalowalność i przenośność; wbrew częstemu przekonaniu wykonuje się je na wszystkich poziomach testów, nie dopiero pod koniec projektu.

Dwa najważniejsze rodzaje testów niefunkcjonalnych to wydajnościowe i bezpieczeństwa, bo najczęściej decydują o losie produktu na produkcji. Pełny rozkład rodzajów testów wydajnościowych (obciążeniowe, przeciążeniowe, wytrzymałościowe, skoków, skalowalności) opisujemy w tekście Testy wydajnościowe, a testy bezpieczeństwa i penetracyjne w tekście Testy bezpieczeństwa i testy penetracyjne. Definicja ISTQB określa je jako testowanie cech niefunkcjonalnych oprogramowania, takich jak niezawodność i użyteczność.

Testy funkcjonalne kontra niefunkcjonalne

Testy funkcjonalne mówią, co robi system, testy niefunkcjonalne, jak działa system; funkcjonalne opierają się na wymaganiach biznesowych i wykonuje się je zwykle najpierw, niefunkcjonalne na parametrach takich jak szybkość czy skalowalność i niemal zawsze wymagają dedykowanych narzędzi.

Testy funkcjonalne i niefunkcjonalne odpowiadają na różne pytania, dlatego w dojrzałym procesie QA występują obok siebie, nie zamiennie.

Testy strukturalne: testowanie białej skrzynki

Testy strukturalne, znane jako testy białej skrzynki, testują program w oparciu o jego wewnętrzną strukturę: dane wejściowe dobiera się tak, aby przejść przez każdą zaimplementowaną ścieżkę, pętlę i warunek, a dokładność mierzy się pokryciem kodu wyrażanym procentowo.

Definicja ISTQB opisuje testy strukturalne jako testowanie oparte na analizie wewnętrznej struktury komponentu lub systemu. To podejście wymaga znajomości kodu, dlatego prowadzą je zwykle developerzy albo testerzy techniczni, najczęściej na poziomie jednostkowym i integracyjnym. Testy białej skrzynki nie wykażą braku funkcji, której w systemie po prostu nie ma: sprawdzają dokładnie to, co zostało zaimplementowane, nie to, czego brakuje, więc nigdy nie zastępują testów funkcjonalnych opartych na wymaganiach, tylko je uzupełniają.

Testy regresji i testy potwierdzające: czym się różnią?

Test potwierdzający (retest) sprawdza, czy konkretny naprawiony błąd faktycznie zniknął, powtarzając dokładnie ten sam test, który wcześniej zakończył się niepowodzeniem; test regresji sprawdza szerzej, czy ostatnie poprawki nie naruszyły obszarów, które wcześniej działały prawidłowo.

Oba pojawiają się zwykle po naprawie błędu i razem domykają cykl jakości po zmianach w kodzie, a ich rozróżnienie to jeden z najczęstszych problemów w zespołach. Regresja jest idealnym kandydatem do automatyzacji, bo powtarza się wielokrotnie po każdej zmianie; pełny rozkład rodzajów regresji, momentów uruchomienia i sposobu jej skrócenia z dni do godzin opisujemy w tekście Testy regresyjne. Test potwierdzający i testowanie regresji w słowniku ISTQB. Najprościej zapamiętać różnicę tak: retest dotyczy jednego naprawionego błędu, a regresja chroni cały system przed skutkami ubocznymi zmiany.

Jak typy testów układają się w cyklu wytwórczym?

Typy testów pojawiają się na różnych etapach cyklu wytwórczego: projektowanie scenariuszy przy wymaganiach, testy strukturalne i jednostkowe przy rozwoju, testy funkcjonalne i pierwsze niefunkcjonalne przy integracji, pełny zestaw na poziomie systemowym, akceptacja i regresja przed wdrożeniem, a regresja i retesty przy każdym kolejnym utrzymaniu.

Im wcześniej w tym cyklu wykryjecie błąd, tym taniej go naprawicie: to jedna z najlepiej udokumentowanych prawidłowości w inżynierii oprogramowania i jednocześnie najczęściej ignorowana w praktyce. Pełny obraz poziomów testów, które przecinają wszystkie te typy, dajemy w tekście Poziomy testowania oprogramowania, a rozkład testów między warstwami automatyzacji w tekście Piramida testów. Jeśli chcecie dobrać właściwe typy testów do swojego produktu i ułożyć je w spójny proces, pomożemy w ramach strategii jakości oprogramowania. Wiedzę dla liderów jakości publikujemy na portalu Strefa QA.

Najczęstsze pytania o typy testów oprogramowania

Czym są typy testów oprogramowania?

Typy testów oprogramowania to różne podejścia do sprawdzania jakości, z których każde odpowiada na inne pytanie o produkt. Wynikają z celu testowania: funkcjonalne, niefunkcjonalne, strukturalne oraz regresji i potwierdzające. W dojrzałym procesie QA te kategorie się uzupełniają, a nie wykluczają.

Jaka jest różnica między testami funkcjonalnymi a niefunkcjonalnymi?

Testy funkcjonalne sprawdzają, co robi system, czyli czy realizuje wymagane funkcje, takie jak naliczanie rabatu czy wystawianie faktury. Testy niefunkcjonalne weryfikują, jak działa system: wydajność, bezpieczeństwo i użyteczność. Funkcjonalne można prowadzić ręcznie lub automatycznie, niefunkcjonalne niemal zawsze wymagają dedykowanych narzędzi.

Czym są testy strukturalne?

Testy strukturalne, znane jako testy białej skrzynki, testują program w oparciu o jego wewnętrzną strukturę. Dane wejściowe dobiera się tak, aby przejść przez każdą zaimplementowaną ścieżkę, pętlę i warunek. Mierzą dokładność testowania pokryciem kodu wyrażanym procentowo. Nie wykażą braku funkcji, której w systemie po prostu nie ma.

Czym są testy regresji?

Testy regresji sprawdzają, czy ostatnie poprawki nie naruszyły obszarów, które wcześniej działały prawidłowo. Wykonuje się je na każdym poziomie testów, najlepiej po każdej aktualizacji systemu. Ponieważ powtarzają się wielokrotnie, są idealnym kandydatem do automatyzacji.

Czym są testy potwierdzające?

Testy potwierdzające, nazywane też retestami, wykonuje się po naprawie wcześniej wykrytego błędu. Powtarzacie dokładnie ten test, który wcześniej zakończył się statusem „failed”, żeby sprawdzić, czy defekt nadal występuje. To wąski test skupiony na jednym konkretnym problemie, w odróżnieniu od szerokiej regresji.

Czy testy wydajnościowe i bezpieczeństwa to testy niefunkcjonalne?

Tak, oba należą do testów niefunkcjonalnych i są ich najważniejszymi rodzajami. Testy wydajnościowe oceniają, jak system zachowuje się pod obciążeniem, a testy bezpieczeństwa weryfikują odporność na ataki i dostęp osób nieuprawnionych. Warto wykonywać je wcześnie i regularnie, nie dopiero na końcu projektu.

Które typy testów warto automatyzować w pierwszej kolejności?

Najlepszym kandydatem są testy regresji, bo powtarzacie je po każdej zmianie i tam automatyzacja zwraca się najszybciej. W dalszej kolejności smoke testy, krytyczne ścieżki i testy API, które są stabilne i tanie w utrzymaniu. Scenariusze niestabilne i często zmieniane lepiej zostawić manualnie.

Jak połączyć różne typy testów w jedną strategię QA?

Zacznijcie od testów funkcjonalnych, żeby potwierdzić, że system robi to, co powinien. Dołóżcie testy strukturalne tam, gdzie liczy się pokrycie kluczowej logiki. Testy niefunkcjonalne, zwłaszcza wydajność i bezpieczeństwo, wprowadźcie wcześnie, nie na końcu. Zbudujcie zestaw regresji do automatyzacji i domykajcie cykl retestami po każdej naprawie.

Powiązane na blogu Quality Island

• Poziomy testowania oprogramowania: od testów jednostkowych po akceptacyjne
• Testy regresyjne: co to jest, rodzaje, kiedy je uruchamiać i jak skrócić regresję
• Testy wydajnościowe: co to jest, rodzaje, metryki, narzędzia
• Testy bezpieczeństwa i testy penetracyjne: co sprawdzają, rodzaje i jak je zlecić
• Piramida testów: co to jest, warstwy, proporcje i techniki projektowania testów
• Testy akceptacyjne (UAT): co to jest, rodzaje, kryteria akceptacji i jak je przeprowadzić

Pełna lista źródeł

• ISTQB Glossary, hasła test type, functional testing, non-functional testing, white-box testing, confirmation testing, regression testing
• Google, Core Web Vitals
• OWASP, Top 10
• Dane własne Quality Island z projektu dla Argos, e-commerce, liczby potwierdzone przez klienta; ponad 450 000 napisanych testów automatycznych, ponad 152 zrealizowane projekty