Testy niefunkcjonalne pokazują, czy system działa dobrze nie tylko „na papierze”, ale też pod presją: przy dużym ruchu, na różnych urządzeniach, po awarii albo w sytuacji próby obejścia zabezpieczeń. W praktyce to właśnie one często decydują o tym, czy produkt jest stabilny, wygodny i gotowy do realnego użycia, a nie tylko poprawny funkcjonalnie.
W tym artykule porządkuję najważniejsze metody, pokazuję, co warto mierzyć, i wyjaśniam, jak planować takie badania, żeby dawały wiarygodne wyniki. To temat, który szczególnie dobrze widać w aplikacjach webowych, mobilnych i usługach chmurowych, gdzie jedna słaba cecha jakości potrafi zepsuć cały odbiór produktu.
Najważniejsze rzeczy, które warto wiedzieć od razu
- Chodzi o sprawdzenie, jak dobrze system działa, a nie tylko czy wykonuje funkcje.
- Najczęściej bada się wydajność, niezawodność, bezpieczeństwo, użyteczność, kompatybilność i odzyskiwanie po awarii.
- Dobre scenariusze muszą mieć mierzalne kryteria, inaczej wynik jest mało przydatny.
- Największy błąd to odkładanie takich testów na koniec projektu.
- W praktyce najlepiej łączyć automatyzację z testami eksploracyjnymi i obserwacją metryk.
Czym są testy niefunkcjonalne i gdzie leży ich granica
W ujęciu ISTQB są to badania, które sprawdzają, czy komponent lub system spełnia wymagania niefunkcjonalne. Mówiąc prościej: funkcjonalne testy odpowiadają na pytanie „co system robi”, a testowanie niefunkcjonalne na pytanie „jak dobrze to robi”.
To rozróżnienie brzmi prosto, ale w projektach często się miesza. Zdarza się, że zespół uznaje za sukces sam fakt, że ekran się otwiera i formularz zapisuje dane, a dopiero później okazuje się, że przy większym ruchu wszystko zwalnia, logowanie rozjeżdża się na telefonach, a po restarcie usługi część danych nie wraca do stanu sprzed awarii. Właśnie dlatego te testy warto prowadzić wcześnie, a nie dopiero przed wydaniem.
ISTQB podkreśla też, że takie badania można wykonywać na każdym poziomie testów i najlepiej robić to jak najwcześniej. To jest dla mnie ważna wskazówka praktyczna: nie trzeba czekać na „gotowy produkt”, żeby sprawdzić wydajność fragmentu kodu, odporność na błędy czy zachowanie interfejsu na różnych urządzeniach. Kiedy to rozróżnienie jest jasne, łatwiej przejść do konkretu i zobaczyć, które cechy jakości realnie trzeba mierzyć.
Jakie obszary jakości sprawdza się najczęściej
Najwygodniej myśleć o tym przez pryzmat cech jakości z ISO/IEC 25010. To nie jest teoria dla teorii, tylko praktyczna mapa tego, co może zawieść mimo poprawnych funkcji. Ja zwykle zaczynam od kilku obszarów, które mają największy wpływ na biznes i doświadczenie użytkownika.
| Obszar | Co sprawdza | Przykładowy sygnał problemu |
|---|---|---|
| Wydajność i skalowalność | Czy system utrzymuje akceptowalny czas odpowiedzi i przepustowość przy rosnącym ruchu | Zbyt wolne ładowanie koszyka, kolejki w API, rosnące opóźnienia przy szczycie ruchu |
| Niezawodność | Czy system działa stabilnie przez dłuższy czas i po wystąpieniu błędów | Losowe crashe, błędy po kilku godzinach pracy, utrata stanu po awarii zależnej usługi |
| Bezpieczeństwo | Czy dane, uprawnienia i sesje są chronione przed nadużyciem | Nieautoryzowany dostęp, słabe sesje, brak ochrony przed nadużyciami w logowaniu |
| Użyteczność i dostępność | Czy użytkownik rozumie interfejs i może z niego korzystać bez zbędnych przeszkód | Nieczytelne formularze, zbyt małe elementy na mobile, problemy z obsługą klawiaturą |
| Kompatybilność | Czy rozwiązanie działa poprawnie w różnych środowiskach i konfiguracjach | Inny układ na Safari, błędy na starszym Androidzie, problemy po zmianie wersji API |
| Odzyskiwanie po awarii | Czy system wraca do pracy po błędzie lub restarcie | Utrata danych po restarcie, niespójny stan transakcji, brak sensownego mechanizmu fallback |
W praktyce nie trzeba od razu badać wszystkiego. Ważniejsze jest to, by wskazać cechy, które realnie wpływają na ryzyko projektu. Dla sklepu internetowego krytyczna będzie wydajność checkoutu i stabilność płatności, a dla systemu medycznego dużo ważniejsze mogą być bezpieczeństwo, dostępność i odtwarzalność po awarii. Ta mapa jakości prowadzi już prosto do metodyki, czyli do tego, jak takie scenariusze faktycznie uruchamiać.
Najpopularniejsze metody testowania w praktyce
W tym obszarze nie ma jednego uniwersalnego scenariusza. Metoda zależy od tego, co chcesz udowodnić, a nie od tego, jaką nazwę najlepiej wygląda w raporcie. Z mojego doświadczenia najlepiej działa podejście mieszane: część testów jest czysto automatyczna, część wymaga obserwacji człowieka, a część powinna być prowadzona na danych i środowisku zbliżonym do produkcyjnego.
Testy wydajnościowe
Tu chodzi o odpowiedź na pytanie, czy system utrzymuje jakość działania przy określonym obciążeniu. Najczęściej rozbijam to na kilka wariantów:
- Load test sprawdza zachowanie przy przewidywanym ruchu. To podstawowy test, który pokazuje, czy system znosi typowy dzień pracy.
- Stress test celowo przekracza zakładane limity. Dzięki temu widać, gdzie system zaczyna się łamać i jak się degraduje.
- Spike test bada nagły skok ruchu. To ważne np. przy promocjach, premierach produktów i kampaniach marketingowych.
- Soak test trwa długo i szuka problemów, które wychodzą dopiero po czasie, takich jak wycieki pamięci, rosnące kolejki albo stopniowa degradacja wydajności.
Warto tu używać metryk, które coś naprawdę mówią o doświadczeniu użytkownika: p95 czasu odpowiedzi, przepustowości, liczby błędów, zużycia CPU i pamięci. Średnia bywa zdradliwa, bo jeden bardzo wolny request potrafi ukryć się w ładnym wyniku zbiorczym. Dobrą praktyką jest też określenie warunków brzegowych, czyli granic wejścia i obciążenia, zanim uruchomisz scenariusz. To właśnie analiza wartości brzegowych pomaga ustawić sensowny stres test, zamiast strzelać w ciemno.
Testy bezpieczeństwa
Bezpieczeństwo rzadko kończy się na skanerze podatności. Taki skaner jest przydatny, ale nie zastąpi testów ról, sesji, autoryzacji, limitów, logowania zdarzeń i reakcji na błędną konfigurację. W praktyce sprawdzam przede wszystkim, czy system nie daje dostępu tam, gdzie nie powinien, i czy w razie nadużycia zachowuje się przewidywalnie.
W zależności od projektu sens mają też testy penetracyjne, ręczne sprawdzanie przepływów logowania oraz scenariusze z nieprawidłowymi tokenami, wygasłymi sesjami albo próbami eskalacji uprawnień. W systemach finansowych, medycznych i administracyjnych to nie jest dodatek, tylko warstwa ochrony produktu i reputacji.
Testy użyteczności, dostępności i kompatybilności
Tu liczy się realny kontakt użytkownika z produktem. Testy użyteczności mogą opierać się na heurystykach, czyli zestawie praktycznych reguł oceny interfejsu, albo na zadaniach wykonywanych przez użytkowników. Dla mnie najbardziej wartościowe są krótkie sesje task-based: użytkownik dostaje konkretne zadanie, a ja obserwuję, gdzie się zatrzymuje, co interpretuje błędnie i które elementy interfejsu wymuszają domyślanie się zamiast działania.
Do tego dochodzi dostępność, czyli np. obsługa klawiaturą, czytnikiem ekranu, odpowiedni kontrast i logiczna kolejność fokusów. Kompatybilność sprawdzam osobno na poziomie przeglądarek, urządzeń, systemów operacyjnych i rozdzielczości. To ważne, bo aplikacja może wyglądać poprawnie w Chrome na laptopie, a w praktyce rozpaść się na Safari w mobile. Ta różnica bywa bardziej kosztowna niż niejedna drobna usterka w funkcji biznesowej.
Przeczytaj również: Testy End-to-End (E2E) - Jak testować, by nie przepalić budżetu?
Testy odporności i odzyskiwania
Ten obszar często jest pomijany, a później to on decyduje o tym, czy system wraca do pracy po awarii. Sprawdzam tu np. restart usług, utratę połączenia z bazą, przełączenie na węzeł zapasowy, opóźnienia w usługach zewnętrznych oraz zachowanie aplikacji po błędzie pośredniego komponentu. Dobrze zaplanowane scenariusze pokazują, czy system się degraduje w kontrolowany sposób, czy po prostu się rozsypuje.
To właśnie tutaj widać, czy architektura naprawdę wspiera ciągłość działania, czy tylko dobrze wygląda na diagramie. Sama technika to jednak dopiero połowa pracy, bo bez dobrego planu wyniki bywają mylące.
Jak zaplanować badanie, żeby wynik dało się obronić
Najwięcej problemów nie zaczyna się w samym wykonaniu, tylko na etapie przygotowania. Ja zwykle układam plan wokół pięciu pytań, które porządkują całe podejście i zmniejszają ryzyko fałszywych wniosków.
- Co dokładnie chcę udowodnić? Zamień wymaganie ogólne na mierzalny próg. Zamiast „system ma działać szybko” lepiej zapisać np. „p95 odpowiedzi ma być poniżej 2 s przy 500 równoczesnych sesjach” albo inny próg adekwatny do projektu.
- Na jakim ruchu pracuję? Zbuduj profil obciążenia z realnych danych albo wiarygodnych założeń. Równy, sztuczny load często nie ma wiele wspólnego z prawdziwym użytkowaniem.
- Jakie środowisko odzwierciedlam? Test na komputerze deweloperskim prawie nigdy nie mówi prawdy o produkcji. Liczy się konfiguracja, sieć, baza, cache, zależności i monitoring.
- Jakie metryki zbieram? Minimum to czas odpowiedzi, błędy, przepustowość i zużycie zasobów. W bezpieczeństwie dochodzą wyniki skanów, a w użyteczności czas wykonania zadania i skuteczność użytkownika.
- Kiedy test uruchamiam? Lekkie sprawdzenia warto wpinać do pipeline’u, ale cięższe scenariusze lepiej odpalać cyklicznie lub przed wydaniem, bo pełny load test potrafi być kosztowny i czasochłonny.
W praktyce bardzo pomaga rozróżnienie między baseline a odchyleniem. Baseline to punkt odniesienia, czyli wynik „normalny”, a odchylenie pokazuje, co się zmienia po nowej wersji, konfiguracji albo wzroście ruchu. Bez tego łatwo uznać coś za poprawę tylko dlatego, że poprzedni test był wykonany w innych warunkach. Najwięcej projektów nie przegrywa na samych testach, tylko na błędach organizacyjnych, które wypaczają obraz jakości.
Błędy, które zaniżają wartość takich testów
Najczęstszy błąd to traktowanie testowania niefunkcjonalnego jak końcowego „dodatku” po zamknięciu funkcji. Wtedy wynik jest spóźniony, a poprawka kosztuje dużo więcej niż w przypadku wczesnego wykrycia problemu. To szczególnie groźne przy wydajności i bezpieczeństwie, bo defekt może nie być widoczny w spokojnym środowisku, ale ujawni się dopiero przy realnym ruchu lub próbie nadużycia.
- Brak mierzalnych kryteriów sprawia, że wyniki są dyskusją, a nie dowodem.
- Testy uruchamiane w zbyt „czystym” środowisku nie pokazują prawdziwych problemów produkcyjnych.
- Patrzenie wyłącznie na średni czas odpowiedzi ukrywa ogony opóźnień, które najbardziej bolą użytkownika.
- Zbyt mały zestaw danych testowych zaniża ryzyko i fałszuje wnioski.
- Ignorowanie zależności zewnętrznych, cache i limitów API daje zbyt optymistyczny obraz systemu.
- Jednorazowy test bez regresji nie mówi nic o tym, co stanie się po kolejnej zmianie.
- Brak właściciela dla znalezionych problemów powoduje, że raport ląduje w próżni.
Jeśli miałbym wskazać jeden nawyk, który najszybciej podnosi jakość, to byłoby to porównywanie wyników do poprzedniego baseline’u zamiast oceniania ich „na oko”. Taka dyscyplina szybko pokazuje, czy system faktycznie się poprawia, czy tylko chwilowo przechodzi przez test. Gdy te pułapki są pod kontrolą, można wpiąć badania jakości do codziennego procesu bez paraliżowania zespołu.
Jak wpiąć je w proces, żeby jakość rosła razem z produktem
Najlepiej działa podejście shift-left, czyli przesuwanie sprawdzania jakości jak najbliżej momentu, w którym powstaje zmiana. W praktyce oznacza to krótkie weryfikacje już na etapie refinementu, przeglądu wymagań i budowy scenariuszy testowych, a nie dopiero na końcu sprintu. Dzięki temu widać od razu, czy wymaganie jest mierzalne i czy da się je w ogóle sensownie zweryfikować.
W codziennej pracy rozdzielam testy na trzy poziomy:
- krótkie checki w pipeline, które szybko sygnalizują problemy po każdej zmianie,
- regularne testy cykliczne, np. nightly albo przed releasem, kiedy można pozwolić sobie na cięższe scenariusze,
- bardziej pogłębione sesje eksperckie, gdy trzeba zbadać zachowanie systemu w niestandardowych warunkach.
Do tego dochodzi observability, czyli połączenie metryk, logów i trace'ów, które pozwalają zrozumieć, co dzieje się wewnątrz systemu podczas testu. Bez tego widzisz tylko objaw, a nie przyczynę. W dobrze prowadzonym projekcie te badania nie są osobnym rytuałem QA, tylko częścią odpowiedzialności całego zespołu: produktu, developmentu, testów i operacji. Jeśli od początku ustawisz jasne progi jakości, sensowne środowisko i realistyczne scenariusze, dostaniesz z nich dużo więcej niż sam raport z testu.
