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

Typy testów oprogramowania to kategorie testowania wyróżnione według celu: testy funkcjonalne sprawdzają, co robi system, testy niefunkcjonalne, jak dobrze to robi, testy strukturalne, czy pokryto logikę kodu, a testy regresji i potwierdzające, czy zmiana niczego nie zepsuła. Typ testów mówi, co sprawdzamy. Poziom testów mówi, kiedy. To dwa różne wymiary i większość nieporozumień w zespołach bierze się z ich pomieszania.

Ten przewodnik jest dla testerów, liderów QA i decydentów technicznych. Dostajecie cztery tabele, przykład jednej funkcji sklepu przetestowanej pięcioma typami testów oraz mapę, który typ pojawia się na którym etapie projektu. Rodzaje testów oprogramowania porządkujemy tu według słownika ISTQB i normy ISO/IEC 25010:2023, a nie według tego, jak akurat nazywa je zespół.

Czym są typy testów oprogramowania?

Słownik ISTQB definiuje typ testów jako grupę czynności testowych ukierunkowanych na konkretne cechy oprogramowania, wynikające z konkretnych celów. Jeden typ pyta „czy to działa zgodnie z wymaganiami”, drugi „czy to wytrzyma realny ruch”, trzeci „czy ktoś nie złamie zabezpieczeń”. Typy nie konkurują ze sobą. W dojrzałym procesie QA współistnieją i dopiero razem tworzą siatkę bezpieczeństwa wokół produktu.

Poziom testów to osobna oś: jednostkowy, integracyjny, systemowy i akceptacyjny. Opisujemy ją w tekście Poziomy testowania oprogramowania. Ten sam typ można uruchomić na różnych poziomach. Test wydajnościowy pojedynczej funkcji to poziom jednostkowy, test wydajnościowy całej aplikacji pod ruchem to poziom systemowy. Testy funkcjonalne też występują na każdym poziomie, od testu jednej metody po test akceptacyjny całego procesu zakupowego.

Dlaczego zespoły mylą typy testów?

Z naszego doświadczenia w audytach QA wynika pięć powtarzalnych powodów. Każdy ma realny koszt i każdy da się naprawić bez nowych narzędzi:

Uporządkowanie typów testów to jeden z najtańszych kroków poprawy jakości: nie wymaga zakupu narzędzi, tylko wspólnego języka. Pierwsze miejsce, w którym ten język warto zapisać, to plan testów.

Testy funkcjonalne: co robi system

Testy funkcjonalne weryfikują, czy system realizuje funkcje opisane w wymaganiach, historyjkach użytkownika i przypadkach użycia. Słownik ISTQB opisuje testowanie funkcjonalne jako testowanie, które ocenia, czy komponent lub system spełnia wymagania funkcjonalne. Testy funkcjonalne wykonuje się ręcznie albo automatycznie, na każdym poziomie testów.

Przykłady funkcji, które sprawdzają testy funkcjonalne: generowanie potwierdzenia zakupu, wystawianie faktury, naliczanie rabatu w koszyku, logowanie i odzyskiwanie hasła. W praktyce dokumentacja bywa niekompletna albo nieaktualna, więc najważniejsze zadanie testera to zrozumienie wymagań, nie odhaczanie kroków. Wiedzę warto czerpać z rozmów z analitykami, programistami i klientami.

Dobre testy funkcjonalne nie kończą się na ścieżce, w której wszystko idzie idealnie. Najwięcej błędów chowa się w przypadkach brzegowych: puste pola, błędne dane, nietypowe kombinacje opcji, przerwany proces. Do ich projektowania służą techniki czarnej skrzynki, takie jak podział na klasy równoważności i analiza wartości brzegowych, opisane w tekście o piramidzie testów i technikach projektowania. Jeśli potrzebujecie, żeby ktoś z zewnątrz przeprowadził testy funkcjonalne Waszej aplikacji, zobaczcie zakres usługi testy funkcjonalne aplikacji webowych i mobilnych. O specyfice telefonów piszemy osobno w artykule Testowanie aplikacji mobilnych: rodzaje i typy testów.

Testy niefunkcjonalne: jak działa system

Testy niefunkcjonalne nie sprawdzają, co system robi, tylko jak działa: wydajność, bezpieczeństwo, użyteczność, zgodność i niezawodność. ISTQB opisuje testowanie niefunkcjonalne jako testowanie cech niefunkcjonalnych. Wbrew częstemu przekonaniu wykonuje się je na wszystkich poziomach, nie dopiero pod koniec projektu. Pełny przewodnik z metodami znajdziecie w artykule Testy niefunkcjonalne: czym są i jak je przeprowadzić, tutaj skupiamy się na tym, jak odróżnić je od reszty.

Testy niefunkcjonalne potrzebują liczb, inaczej kończą się zdaniem „działa szybko”. Według Google web.dev dobre doświadczenie użytkownika oznacza Largest Contentful Paint do 2,5 sekundy, Interaction to Next Paint do 200 milisekund i Cumulative Layout Shift do 0,1, mierzone na 75. percentylu odsłon. Takie progi wpisane w kryteria akceptacji zamieniają ogólnik w test, który da się zaliczyć albo oblać.

Dwa rodzaje testów niefunkcjonalnych najczęściej decydują o losie produktu na produkcji: wydajnościowe i bezpieczeństwa. Szczegóły opisujemy w tekstach Testy wydajnościowe oraz Testy bezpieczeństwa i testy penetracyjne. Jeśli wolicie zlecić je zespołowi z zewnątrz, zobaczcie testy wydajnościowe aplikacji i testy bezpieczeństwa w ofercie Quality Island.

Testy funkcjonalne kontra niefunkcjonalne

Testy funkcjonalne mówią, co robi system, testy niefunkcjonalne, jak działa. Testy funkcjonalne opierają się na wymaganiach biznesowych i zwykle startują pierwsze. Niefunkcjonalne opierają się na mierzalnych parametrach i niemal zawsze wymagają dedykowanych narzędzi. W wierszu „przykłady” wpisujemy wyłącznie typy testów, bez poziomów, żeby nie powtarzać błędu, przed którym ostrzegamy wyżej:

Ostatni wiersz jest celowo identyczny po obu stronach. Poziom nie rozstrzyga, czy test jest funkcjonalny. Rozstrzyga to pytanie, na które odpowiada. Testy funkcjonalne i niefunkcjonalne występują obok siebie, nie zamiennie, a test akceptacyjny może zawierać jedne i drugie.

Testy strukturalne: testowanie białej skrzynki

Testy strukturalne, nazywane testami białej skrzynki, projektuje się na podstawie wewnętrznej struktury kodu. Dane wejściowe dobiera się tak, żeby przejść przez zaimplementowane ścieżki, pętle i warunki, a dokładność mierzy się pokryciem kodu w procentach. ISTQB opisuje testowanie białoskrzynkowe jako testowanie oparte na analizie wewnętrznej struktury komponentu lub systemu.

To podejście wymaga znajomości kodu, dlatego prowadzą je zwykle programiści albo testerzy techniczni, najczęściej na poziomie jednostkowym i integracyjnym. Testy białoskrzynkowe mają jedno ograniczenie, które warto znać: sprawdzają to, co zaimplementowano, a nie to, czego brakuje. Funkcji, której nikt nie napisał, nie pokryje żaden procent pokrycia. 100 procent pokrycia kodu, który robi nie to, co trzeba, to wciąż 100 procent. Tylko radość krótsza. Dlatego testy strukturalne uzupełniają testy funkcjonalne, ale ich nie zastępują.

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

Test potwierdzający (retest) sprawdza, czy konkretny naprawiony błąd zniknął: powtarzacie dokładnie ten test, który wcześniej zakończył się niepowodzeniem. Test regresji sprawdza szerzej, czy zmiana nie zepsuła obszarów, które wcześniej działały. Definicje: test potwierdzający i testowanie regresji w słowniku ISTQB.

Oba pojawiają się po naprawie błędu i razem domykają cykl jakości. Regresja jest najlepszym kandydatem do automatyzacji, bo powtarzacie ją po każdej zmianie. U naszych klientów to od niej zaczynamy prawie każdy projekt automatyzacji. W projekcie dla Argos, e-commerce, automatyzacja testów i uporządkowanie procesów QA skróciły regresję przed wydaniem z 5 dni do 10 godzin. Rodzaje regresji i sposoby jej skracania opisujemy w tekście Testy regresyjne, a wybór narzędzi do automatyzacji w przeglądzie narzędzi do testowania oprogramowania.

Jeden koszyk, pięć typów testów: przykład

Teoria najlepiej siada na jednym przykładzie. Weźmy funkcję, którą zna każdy sklep internetowy: kod rabatowy w koszyku. Ta sama funkcja dostaje pięć różnych typów testów, a każdy łapie inną klasę błędów:

Liczby w przykładzie są ilustracyjne, a nie wynikiem konkretnego projektu. Pokazują jednak sedno: żaden pojedynczy typ testów nie złapałby wszystkich pięciu błędów. Więcej o testowaniu sklepów, od koszyka po płatności, piszemy w artykule Testowanie e commerce.

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

Typy testów pojawiają się na różnych etapach projektu. Im wcześniej wykryjecie błąd, tym mniej pracy kosztuje jego poprawka, bo zmienia się mniej kodu, dokumentacji i danych. To prawidłowość, którą każdy zespół zna, i którą większość ignoruje pod presją terminu.

Pełny obraz etapów akceptacji znajdziecie w tekście Testy akceptacyjne (UAT). Jeśli chcecie dobrać właściwe typy testów do swojego produktu i ułożyć je w spójny proces, pomagamy w tym w ramach strategii jakości oprogramowania. Podstawy klasyfikacji testów są też częścią szkolenia ISTQB Foundation Level, przez które przeszło wielu z ponad 2 500 specjalistów przeszkolonych przez Quality Island. A o tym, jak liderzy jakości przekładają typy testów na decyzje budżetowe, piszemy na portalu Strefa QA w tekście o kosztach utrzymania oprogramowania.

Powiązane na blogu Quality Island

• Poziomy testowania oprogramowania: od testów jednostkowych po akceptacyjne
• Testy niefunkcjonalne: czym są i jak je przeprowadzić
• Testy regresyjne: co to jest, rodzaje i jak skrócić regresję
• Smoke test: co to jest i czym różni się od sanity testu
• Piramida testów: warstwy, proporcje i techniki projektowania testów

Pełna lista źródeł

• ISTQB, Glossary, wersja online 2026: hasła test type, functional testing, non-functional testing, white-box testing, confirmation testing, regression testing.
• ISTQB, Certified Tester Foundation Level v4.0, 2023. Podział na typy i poziomy testów.
• arc42, Update on ISO 25010, version 2023, 2023. Nowa cecha safety oraz zmiany nazw cech modelu jakości.
• Google, Web Vitals, web.dev, stan na 2026. Progi LCP 2,5 s, INP 200 ms, CLS 0,1 na 75. percentylu.
• OWASP, OWASP Top 10, edycja 2021 i kolejne. Punkt odniesienia dla testów bezpieczeństwa aplikacji webowych.
• Dokumentacja narzędzi wydajnościowych: Apache JMeter, Grafana k6, Locust, stan na 2026.
• Dane własne Quality Island, 2026: case study Argos (e-commerce) z liczbami potwierdzonymi przez klienta, ponad 2 500 przeszkolonych specjalistów.