Typy testów — testowanie funkcjonalne i niefunkcjonalne

Ten wpis jest częścią serii ISTQB Foundation Level. Jeśli nie czytałeś poprzedniego wpisu, zajrzyj najpierw do Części 4 — Poziomy testów.

Typy a poziomy — kluczowe rozróżnienie

Zanim przejdziemy dalej, ustalmy jedno krytyczne rozróżnienie, które sprawia kłopoty wielu kandydatom do certyfikatu ISTQB.

Poziomy testów opisują gdzie odbywa się testowanie — komponentów, integracyjne, systemowe lub akceptacyjne. Definiują zakres i część systemu poddaną testowaniu.

Typy testów opisują jaką cechę się testuje. Funkcjonalną? Wydajnościową? Bezpieczeństwa? Użyteczności?

Kluczowa obserwacja: każdy typ testów można zastosować na każdym poziomie testów. Możesz przeprowadzić test wydajnościowy pojedynczego komponentu (poziom komponentów), interakcji między dwoma serwisami (poziom integracyjny) lub całego systemu (poziom systemowy). Typ i poziom to niezależne wymiary.

To sekcja 2.3 ISTQB — jasne zrozumienie tego rozróżnienia jest warte przynajmniej jednego pytania egzaminacyjnego.

Testowanie funkcjonalne — ISTQB 2.3.1

Testowanie funkcjonalne weryfikuje co system robi — że oprogramowanie funkcjonuje zgodnie ze specyfikacją zawartą w wymaganiach.

Test funkcjonalny pyta: „Czy ta funkcja działa?”

Czy formularz logowania akceptuje prawidłowe dane uwierzytelniające i odrzuca nieprawidłowe?
Czy koszyk zakupów oblicza poprawny łączny koszt po zastosowaniu kodu rabatowego?
Czy endpoint API zwraca oczekiwaną strukturę danych dla danego wejścia?

Podstawą testów dla testowania funkcjonalnego są wymagania funkcjonalne: przypadki użycia, historyjki użytkownika, specyfikacje funkcjonalne, reguły biznesowe.

Testowanie funkcjonalne można przeprowadzać na wszystkich poziomach testów:

Poziom komponentów: czy ta funkcja zwraca prawidłową wartość?
Poziom integracyjny: czy te dwa serwisy wymieniają między sobą prawidłowe dane?
Poziom systemowy: czy ten przepływ end-to-end daje prawidłowy wynik?
Poziom akceptacyjny: czy ten przepływ spełnia wymaganie biznesowe?

Techniki testowania czarnoskrzynkowego — podział na klasy równoważności, analiza wartości brzegowych, tablice decyzyjne, testowanie przejść między stanami — są głównymi narzędziami testowania funkcjonalnego. Omówimy je szczegółowo w kolejnych wpisach.

Testowanie niefunkcjonalne — ISTQB 2.3.2

Testowanie niefunkcjonalne weryfikuje jak dobrze system działa — cechy jakościowe wykraczające poza samą funkcjonalność. Nawet system, który robi dokładnie to, co mówią wymagania, może zawieść użytkowników, jeśli robi to wolno, niepewnie lub w sposób niemożliwy do używania.

Standard ISO/IEC 25010 definiuje charakterystyki jakości, którymi zajmuje się testowanie niefunkcjonalne. Główne, z którymi spotykasz się w praktyce:

:::warning[Słowo o testowaniu niefunkcjonalnym w praktyce] Większość zespołów testuje tylko funkcjonalność. Awarie niefunkcjonalne powodują większość incydentów na produkcji. Wolne zapytanie do bazy danych, które działa świetnie ze 100 rekordami testowymi, ale pada pod ciężarem 10 milionów rekordów produkcyjnych. Nagłówek bezpieczeństwa przypadkowo usunięty podczas refaktoringu. Strona, która jest technicznie funkcjonalna, ale wymaga 14 kliknięć do wykonania zadania, które użytkownik wykonuje 50 razy dziennie. Testowanie niefunkcjonalne nie jest opcjonalne — to co stoi między działającym demo a niezawodnym produktem. :::

Testowanie wydajnościowe

Testowanie wydajnościowe weryfikuje, jak szybki, skalowalny i stabilny jest system pod różnym obciążeniem.

Istnieje kilka odrębnych podtypów, każdy z innym celem:

Podtyp	Co testuje	Typowe pytanie
Testy obciążeniowe (load)	Zachowanie pod oczekiwanym obciążeniem	Czy system obsługuje 1 000 równoczesnych użytkowników?
Testy wytrzymałościowe (stress)	Zachowanie powyżej oczekiwanego obciążenia	W którym miejscu system się poddaje? Jak się poddaje?
Testy skokowe (spike)	Zachowanie przy nagłym wzroście obciążenia	Co się dzieje, gdy ruch wzrasta 10× w ciągu 10 sekund?
Testy długotrwałe (endurance/soak)	Zachowanie pod stałym obciążeniem w czasie	Czy system degraduje po 12 godzinach ciągłego użytkowania? (wycieki pamięci, wyczerpanie puli połączeń)

Narzędzia: k6, Apache JMeter, Gatling, Locust

Dobra suite testów wydajnościowych definiuje wyraźne kryteria akceptacji (np. „95. percentyl czasu odpowiedzi < 500 ms przy 500 równoczesnych użytkownikach”) zamiast tylko mierzyć i liczyć na to, że liczby będą wyglądać dobrze.

Testowanie bezpieczeństwa

Testowanie bezpieczeństwa weryfikuje, że system chroni dane i zasoby przed nieautoryzowanym dostępem i manipulacją.

OWASP Top 10 to de facto lista referencyjna podatności bezpieczeństwa aplikacji webowych — SQL injection, zepsute uwierzytelnianie, cross-site scripting (XSS), niebezpieczna deserializacja i inne. Jeśli testujesz aplikację webową i nie zweryfikowałeś jej względem OWASP Top 10, twoje testowanie bezpieczeństwa jest niekompletne.

Podejścia do testowania bezpieczeństwa:

SAST (Static Application Security Testing): analizuje kod źródłowy bez uruchamiania aplikacji. Szybki, wykrywa problemy wcześnie, integruje się z IDE i CI. Narzędzia: Snyk Code, SonarQube, Semgrep.
DAST (Dynamic Application Security Testing): atakuje działającą aplikację z zewnątrz, tak jak zrobiłby to prawdziwy atakujący. Narzędzia: OWASP ZAP, Burp Suite.
Testy penetracyjne (pentest): doświadczony specjalista ds. bezpieczeństwa (lub zespół) próbuje skompromitować system technikami używanymi przez prawdziwych atakujących. Dokładniejszy niż automatyczne skanowanie, ale wolniejszy i droższy.
Skanowanie zależności: sprawdza biblioteki zewnętrzne pod kątem znanych podatności. Narzędzia: Snyk, Dependabot, OWASP Dependency-Check.

Testowanie użyteczności

Testowanie użyteczności weryfikuje, że system jest łatwy do nauki, efektywny w użyciu i satysfakcjonujący dla docelowych użytkowników.

Metody:

Protokół głośnego myślenia (think-aloud): użytkownicy opowiadają swoje myśli podczas wykonywania zadań, ujawniając punkty dezorientacji i tarcia.
Testowanie ukończenia zadań (task completion): użytkownicy próbują wykonać konkretne zadania; mierzy się wskaźnik sukcesu i czas wykonania.
Testowanie A/B: dwa warianty interfejsu są pokazywane różnym grupom użytkowników; metryki decydują, który wypada lepiej.

Narzędzia: Maze (niemodorowane zdalne testy użyteczności), Hotjar (mapy ciepła, nagrania sesji), UserTesting (sesje moderowane).

Testowanie niezawodności

Testowanie niezawodności weryfikuje, że system działa bez awarii przez określony czas w określonych warunkach.

Kluczowe metryki:

MTBF (Mean Time Between Failures — Średni czas między awariami): średni czas, przez który system działa między awariami.
MTTR (Mean Time To Recovery — Średni czas do odtworzenia): średni czas przywrócenia usługi po awarii.
Dostępność: zazwyczaj wyrażana procentowo (np. 99,9% = ~8,7 godziny przestoju rocznie).

Chaos engineering doprowadza testowanie niezawodności do logicznego ekstremum: celowe wprowadzanie awarii do działającego systemu (zabicie poda, nasycenie łącza sieciowego, uszkodzenie dysku) w celu weryfikacji, że system degraduje w sposób kontrolowany i automatycznie się odtwarza. Narzędzia: Chaos Monkey (Netflix), LitmusChaos, AWS Fault Injection Simulator.

Testowanie regresji — ISTQB 2.3.3

Za każdym razem, gdy zmieniasz oprogramowanie — naprawiasz błąd, dodajesz funkcję, refaktorujesz kod, aktualizujesz zależność — ryzykujesz wprowadzenie nowych defektów lub ponowne pojawienie się defektów, które były wcześniej naprawione. To właśnie nazywamy regresją.

Testowanie regresji to praktyka ponownego uruchamiania istniejących testów po zmianach w celu potwierdzenia, że wcześniej działająca funkcjonalność nadal działa.

Regresja oparta na ryzyku vs. pełna regresja

Uruchamianie całej suity testów po każdej zmianie jest często niepraktyczne. Dwa podejścia zarządzają tym kompromisem:

Pełna regresja: uruchom wszystko. Maksymalna pewność. Często zbyt wolna dla częstych cykli CI/CD.

Regresja oparta na ryzyku: wybieraj testy na podstawie ryzyka i wpływu zmiany. Jeśli zmieniłeś moduł płatności, uruchom testy płatności plus wszystko, czego moduł płatności dotyka. Wymaga dobrej identyfikowalności testów (wiedzy, które testy pokrywają jaką funkcjonalność).

Testowanie regresji w CI/CD

W nowoczesnych pipeline’ach testowanie regresji odbywa się ciągle:

Testy jednostkowe i szybkie testy integracyjne przy każdym commit (sekundy)
Szersza suite integracyjna przy każdym PR (minuty)
Pełna regresja przy scaleniu do main (minuty–godziny)

Utrzymanie suit regresyjnych

Suite regresyjne rosną z czasem i wymagają aktywnego utrzymania. Test, który zawsze zalicza, nie jest bezwartościowy — jest siatką bezpieczeństwa — ale testy niestabilne (flaky), wolne lub testujące funkcjonalność, która już nie istnieje, powinny być usunięte lub naprawione. Rozdęta suite regresyjna staje się wąskim gardłem.

Testy dymne (Smoke Testing)

Testy dymne to szybkie, szerokie sprawdzenie weryfikujące, czy najbardziej krytyczna funkcjonalność buildu lub wdrożenia w ogóle działa.

Nazwa ma industrialne korzenie: jeśli włączysz nowy obwód elektryczny i zacznie dymić, wiesz, że coś jest fundamentalnie nie tak, zanim w ogóle spróbujesz go użyć. W oprogramowaniu test dymny odpowiada na pytanie: „Czy ten build w ogóle warto dalej testować?”

Charakterystyki:

Pokrywa ~5–15% pełnej suity testów
Trwa minuty, nie godziny
Skupia się na krytycznych ścieżkach: czy użytkownicy mogą się zalogować? Czy strona główna się ładuje? Czy podstawowe API odpowiada?
Uruchamiany natychmiast po wdrożeniu na dowolne środowisko

Jeśli testy dymne nie przechodzą, build jest natychmiast odrzucany, bez marnowania czasu na uruchamianie pełnej suity wobec wadliwego wdrożenia.

Testy poczytalności (Sanity Testing)

Testy poczytalności (sanity testing) to wąsko skupione sprawdzenie przeprowadzane po drobnej zmianie lub poprawce błędu w celu weryfikacji, że konkretna zmiana działa zgodnie z zamierzeniem i nie wprowadziła oczywistych uszkodzeń w powiązanej funkcjonalności.

Różnice względem pokrewnych pojęć:

	Testy dymne	Testy poczytalności	Testowanie regresji
Zakres	Szeroki, krytyczne ścieżki	Wąski, konkretny obszar	Szeroki, cała istniejąca funkcjonalność
Wyzwalacz	Nowy build / wdrożenie	Drobna poprawka lub zmiana	Jakakolwiek zmiana
Cel	Czy build jest opłacalny?	Czy ta poprawka zadziałała?	Czy coś się zepsuło?
Formalność	Często skryptowane	Często manualne / eksploracyjne	Skryptowane
Czas	Minuty	Minuty do godziny	Godziny

Testy poczytalności są często przeprowadzane przez testerów bez szczegółowego skryptu testowego — korzystają ze swojej wiedzy o systemie, aby szybko ocenić, czy zmiana osiągnęła swój cel.

Mapowanie typów testów na pipeline CI/CD

Różne typy testów należą do różnych punktów w pipeline dostarczania. Oto praktyczne mapowanie:

┌──────────────────────────────────────────────────────────────────────┐
│  Etap               │  Typy testów                                   │
├──────────────────────────────────────────────────────────────────────┤
│  Pre-commit         │  Testy jednostkowe, SAST (linting + analiza)   │
│  Pull Request       │  Jednostkowe, integracyjne, kontraktowe, SAST  │
│  Scalenie do main   │  Testy dymne, regresja, DAST (podstawowy)      │
│  Pre-release        │  Pełna regresja, wydajnościowe, pentest         │
│  Post-wdrożenie     │  Testy dymne, monitoring syntetyczny, chaos     │
│  Produkcja          │  Monitoring syntetyczny, obserwowalność         │
└──────────────────────────────────────────────────────────────────────┘

Zasada przewodnia: szybsze testy wcześniej, wolniejsze testy później. Chcesz wykrywać awarie jak najwcześniej w pipeline’ie, bo awarie wykryte wcześniej są tańsze do naprawienia i szybsze do rozwiązania.

Podsumowanie

Typy testów i poziomy testów tworzą dwuwymiarową przestrzeń do organizowania wysiłku testowego:

Testowanie funkcjonalne weryfikuje poprawność — czy robi to, co mówią wymagania?
Testowanie niefunkcjonalne weryfikuje jakość — czy robi to wystarczająco szybko, wystarczająco bezpiecznie, wystarczająco niezawodnie?
Testowanie regresji zachowuje poprawność w czasie — czy nasze zmiany zepsuły coś, co działało?
Testy dymne kontrolują przepustkę pipeline’u — czy ten build w ogóle warto testować?
Testy poczytalności weryfikują ukierunkowane poprawki — czy ta konkretna zmiana osiągnęła swój cel?

Przed kolejną retrospektywą sprintu zapytaj: „Których typów testów niefunkcjonalnych systematycznie NIE przeprowadzamy?” Testowanie wydajnościowe, bezpieczeństwa i niezawodności są często pierwszą ofiarą napiętych harmonogramów projektowych — i pierwszą przyczyną incydentów produkcyjnych po wydaniu.

:::tip[Wskazówka egzaminacyjna ISTQB] Pamiętaj: typy testów i poziomy testów są ortogonalne. Na egzaminie często pojawia się scenariusz z pytaniem o typ testów, poziom testów lub oba. „Test wydajnościowy pojedynczej funkcji” to testowanie niefunkcjonalne na poziomie komponentów. „Przejście UAT przez przepływ kasy” to testowanie funkcjonalne na poziomie akceptacyjnym. Ćwicz jednoczesne stosowanie obu wymiarów. :::

Następny wpis: Część 6 — Testowanie statyczne i przeglądy