Testy niefunkcjonalne: czym są, rodzaje według ISO/IEC 25010 i przykłady wymagań

Testy niefunkcjonalne sprawdzają, jak dobrze zachowuje się system, a nie co robi: jak szybko odpowiada, ilu użytkowników wytrzyma, jak broni się przed atakiem, czy da się z niego wygodnie korzystać i jak wraca do działania po awarii. Sylabus ISTQB Certyfikowany Tester Poziom Podstawowy (wersja 4.0.1 z 2024 roku) opisuje je jako ocenę charakterystyk jakościowych innych niż funkcjonalne, a ich listę bierze z normy ISO/IEC 25010. Aplikacja, która liczy poprawnie, ale odpowiada po ośmiu sekundach, dla użytkownika po prostu nie działa.

W tym przewodniku dostajecie model jakości ISO/IEC 25010:2023 zestawiony z nazwami, których nadal używa sylabus ISTQB, przykład mierzalnego wymagania i testu dla każdej charakterystyki, gotowy skrypt k6 z progami, które zatrzymują potok CI, oraz listę błędów, które w testach niefunkcjonalnych kosztują najwięcej.

Czym są testy niefunkcjonalne według ISTQB?

Według sylabusa ISTQB CTFL v4.0.1 (sekcja 2.2.2) testowanie niefunkcjonalne ocenia atrybuty modułu albo systemu inne niż charakterystyki funkcjonalne, czyli to, „jak dobrze” system się zachowuje. Głównym celem jest sprawdzenie niefunkcjonalnych charakterystyk jakościowych. Sylabus dodaje trzy obserwacje, które warto mieć z tyłu głowy przy planowaniu.

• Wiele testów niefunkcjonalnych wyrasta z funkcjonalnych. Ten sam scenariusz logowania sprawdzacie raz pod kątem poprawności, a raz z warunkiem, że ma się zmieścić w zadanym czasie.
• Czasem warto zacząć wcześnie, na przykład w przeglądach wymagań i w testowaniu modułowym. Późne wykrycie defektów niefunkcjonalnych sylabus nazywa poważnym zagrożeniem dla powodzenia projektu.
• Bywa potrzebne specjalne środowisko, na przykład laboratorium użyteczności albo środowisko o mocy zbliżonej do produkcji.

Testy niefunkcjonalne wykonujecie na wszystkich poziomach testów, od modułowego po akceptacyjny, choć na każdym z innym akcentem. Szerszą mapę typów i poziomów znajdziecie w przeglądzie typów testów oprogramowania i w artykule o poziomach testowania.

Czym różnią się testy funkcjonalne i niefunkcjonalne?

Testy funkcjonalne i niefunkcjonalne pytają o dwie różne rzeczy. Funkcjonalne sprawdzają kompletność, poprawność i adekwatność funkcji, czyli „co” system robi. Niefunkcjonalne sprawdzają, „jak dobrze” to robi. Najłatwiej zobaczyć różnicę na jednym ekranie.

Źródło: sylabus ISTQB CTFL v4.0.1, sekcja 2.2.2, 2024; ISO/IEC 25010:2023; przykład Quality Island.

To samo rozróżnienie dotyczy wymagań. Wymaganie funkcjonalne mówi, co ma się wydarzyć, a wymaganie niefunkcjonalne nakłada na to warunek jakości. Dlatego pytanie o wymagania funkcjonalne i niefunkcjonalne zawsze sprowadza się do tego samego: czy da się je zmierzyć.

Jakie charakterystyki jakości opisuje ISO/IEC 25010:2023?

ISO/IEC 25010:2023 to aktualna wersja modelu jakości produktu z rodziny SQuaRE. Według zestawienia SonarSource z 2026 roku model ma dziewięć charakterystyk: przydatność funkcjonalną i osiem charakterystyk, które sylabus ISTQB zalicza do niefunkcjonalnych. W porównaniu z wersją z 2011 roku użyteczność przemianowano na zdolność do interakcji, przenaszalność na elastyczność, doszło bezpieczeństwo (safety), a w elastyczności pojawiła się skalowalność. Sylabus ISTQB idzie za tą zmianą tylko częściowo. Wersja 4.0 z 2023 roku wymieniała siedem charakterystyk niefunkcjonalnych w nazwach z normy z 2011 roku. Wersja 4.0.1 z 2024 roku, według własnej listy zmian, zostawiła stare nazwy (usability, portability), dopisała obok nowe (interaction capability, flexibility) i dodała bezpieczeństwo (safety), więc dziś na liście sylabusa jest osiem pozycji. W tabeli niżej pierwsza kolumna podaje polskie nazwy według normy 2023, a w nawiasie dawne nazwy, które nadal stoją w sylabusie, albo termin angielski.

Źródło: ISO/IEC 25010:2023 według zestawienia SonarSource, 2026; nazwy polskie: sylabus ISTQB CTFL v4.0, wersja PL 4.0.0.1, SJSI 2025; lista charakterystyk w sylabusie: CTFL v4.0.1, sekcja 2.2.2 i lista zmian wersji, ISTQB 2024; przykłady wymagań: Quality Island.

Jak zapisać mierzalne wymaganie niefunkcjonalne? Przykłady

Wymaganie niefunkcjonalne jest testowalne wtedy, gdy ma pięć elementów: charakterystykę, metrykę, próg, warunki pomiaru i sposób pomiaru. Brak któregokolwiek oznacza, że wynik testu będzie sporem o interpretację. Poniżej przykłady wymagań niefunkcjonalnych, które widzimy w dokumentacji klientów, i ich wersje po poprawce.

Źródło: progi Core Web Vitals: Google web.dev, 2024; OWASP ASVS 5.0.0; przykłady Quality Island.

Każdy taki próg powinien mieć właściciela po stronie biznesu, bo to biznes decyduje, ile kosztuje sekunda opóźnienia albo godzina niedostępności. Wymagania tego typu ćwiczymy na szkoleniu Analiza wymagań niefunkcjonalnych (NFR), a już spisane warto przepuścić przez przegląd, o którym piszemy w artykule o testowaniu statycznym.

Jak przetestować wymaganie wydajnościowe w praktyce?

Wymaganie z pierwszego wiersza tabeli zamienia się w test w kilkunastu liniach. Narzędzie k6 pozwala zapisać próg wprost w skrypcie, a według dokumentacji Grafana k6 test z niespełnionym progiem kończy się statusem błędu i niezerowym kodem wyjścia, więc potok CI sam zatrzyma wydanie.

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  scenarios: {
    rabat_w_koszyku: {
      executor: 'constant-arrival-rate',
      rate: 50,
      timeUnit: '1s',
      duration: '10m',
      preAllocatedVUs: 100,
      maxVUs: 300,
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<500', 'p(99)<1500'],
  },
};

export default function () {
  const res = http.post(
    'https://test.example.com/api/koszyk/rabat',
    JSON.stringify({ kod: 'JESIEN10' }),
    { headers: { 'Content-Type': 'application/json' } }
  );
  check(res, { 'status 200': (r) => r.status === 200 });
}

Wykonawca constant-arrival-rate utrzymuje stałą liczbę żądań na sekundę niezależnie od tego, jak szybko odpowiada serwer, więc mierzycie dokładnie to, co obiecuje wymaganie: 50 żądań na sekundę. Próg p(95)<500 to 95. percentyl czasu odpowiedzi, a rate<0.01 to mniej niż 1% błędów HTTP. Średnia czasu odpowiedzi to ulubiona metryka osób, które nie chcą wiedzieć, co przeżywa najwolniejsze 5% klientów.

Core Web Vitals mierzą wydajność widzianą w przeglądarce, test k6 mierzy serwer. Potrzebujecie obu, bo szybkie API nie uratuje strony, która blokuje wątek główny trzema megabajtami skryptów. Szczegóły progów i pomiaru opisaliśmy w tekście jak szybko powinna ładować się strona, a rodzaje testów wydajnościowych w przewodniku po testach wydajnościowych.

Jak testować zabezpieczenia, zdolność do interakcji i niezawodność?

Wydajność najłatwiej zmierzyć liczbą, dlatego zespoły często na niej poprzestają. Pozostałe charakterystyki wymagają innych technik i często innych ludzi. Poniżej skrót tego, co sprawdza się w projektach, które prowadziliśmy.

Testy zabezpieczeń zasługują na osobny akapit, bo tu najczęściej widzimy fałszywe poczucie spokoju po jednym automatycznym skanie. Skaner znajdzie nagłówki i znane wzorce, ale nie znajdzie błędu w logice uprawnień, gdzie klient A widzi fakturę klienta B po zmianie numeru w adresie. Jak to wygląda z perspektywy budżetu, pokazuje artykuł na portalu Strefa QA o tym, ile kosztuje luka bezpieczeństwa, której nikt nie szukał, a zakres testów opisujemy w tekście o testach bezpieczeństwa i testach penetracyjnych.

Kiedy planować testy niefunkcjonalne?

Testy niefunkcjonalne przygotowujecie od początku projektu, a wykonujecie wtedy, gdy wynik coś znaczy. Rozkład w czasie wygląda zwykle tak:

Źródło: sylabus ISTQB CTFL v4.0.1, sekcja 2.2.2; praktyka Quality Island, 2026.

Jakie błędy w testach niefunkcjonalnych kosztują najwięcej?

Najdroższe błędy w testach niefunkcjonalnych są nudne i powtarzalne. Widzimy je u klientów z bankowości, e-commerce i branży medycznej w bardzo podobnej postaci.

• Test na samym końcu. Test wydajności tydzień przed wdrożeniem zostawia dwie opcje: przesunąć termin albo wdrożyć ze znanym ryzykiem.
• Próg bez warunków. „Poniżej 2 sekund” bez liczby użytkowników, rodzaju danych i percentyla nic nie znaczy.
• Średnia zamiast percentyla. Średnia 300 ms potrafi ukryć 8 sekund dla co dwudziestego klienta.
• Środowisko niepodobne do produkcji. Baza z tysiącem rekordów zamiast dziesięciu milionów daje wynik, który pęka pierwszego dnia.
• Tylko wydajność. Zabezpieczenia, niezawodność i zdolność do interakcji zostają bez testu, bo trudniej je zmierzyć.
• Brak powtarzalności. Jednorazowy test przed premierą nie wyłapie regresji wydajności w kolejnych wydaniach.

Te wyniki nie wzięły się z jednego testu przed premierą, tylko z testów powtarzanych przy każdym wydaniu. Ile kosztuje taki błąd w liczbach i kiedy test wydajności jest obowiązkowy, opisaliśmy w tekście dlaczego testy wydajnościowe są tak ważne.

Od czego zacząć w Waszym projekcie?

Jeśli w Waszym projekcie testy niefunkcjonalne dziś nie istnieją albo są jednorazowym zrywem, zacznijcie od trzech kroków. Po pierwsze, wybierzcie z tabeli ISO/IEC 25010 trzy charakterystyki najważniejsze dla Waszego biznesu i dla każdej spiszcie jedno mierzalne wymaganie. Po drugie, zamieńcie wymaganie wydajnościowe w skrypt z progiem i wepnijcie go do potoku CI na małym ruchu. Po trzecie, raz na kwartał zróbcie pełny test na środowisku zbliżonym do produkcji i porównajcie wynik z poprzednim.

Jeśli wolicie zlecić to zespołowi, który robił to już wiele razy, prowadzimy testy wydajności, testy bezpieczeństwa, testy dostępności i testy użyteczności. Dla zespołów, które chcą to robić same, mamy szkolenia Testowanie wydajnościowe JMeter oraz Certyfikowany Tester Poziom Podstawowy v4.0, gdzie model ISO/IEC 25010 jest częścią programu.

Powiązane na blogu Quality Island

• Testy wydajnościowe: co to jest, rodzaje, metryki i narzędzia
• Testy bezpieczeństwa i testy penetracyjne: co sprawdzają i jak je zlecić
• Testowanie dostępności: jak, kiedy i jakimi narzędziami
• Typy testów oprogramowania: funkcjonalne, niefunkcjonalne, strukturalne i regresja
• Testowanie statyczne: przeglądy, analiza statyczna i checklista wymagań

Pełna lista źródeł

• ISTQB, Certified Tester Foundation Level Syllabus v4.0.1, 2024. Sekcja 2.2.2: testowanie funkcjonalne i niefunkcjonalne, lista charakterystyk według ISO/IEC 25010.
• SJSI, Sylabus ISTQB Certyfikowany Tester Poziom Podstawowy w. 4.0, wersja polska 4.0.0.1, 2025. Polskie nazwy charakterystyk: wydajność działania, zabezpieczenia, utrzymywalność, bezpieczeństwo.
• ISO/IEC, ISO/IEC 25010:2023 Product quality model, 2023. Model jakości produktu, dziewięć charakterystyk.
• SonarSource, Understanding the ISO/IEC 25010: framework for software quality, 2026. Lista charakterystyk i podcharakterystyk wersji 2023 oraz zmian wobec 2011.
• Google web.dev, Web Vitals, 2024. Progi LCP, INP i CLS dla 75. percentyla.
• Grafana Labs, k6 documentation: Thresholds, 2026. Składnia progów i zakończenie testu z niezerowym kodem wyjścia.
• OWASP, Application Security Verification Standard 5.0.0, 2025. Lista wymagań zabezpieczeń do testów.
• Dane własne Quality Island, 2026: case studies Argos i Autono, liczby potwierdzone przez klientów.