Testy systemowe: przykładowy plan, 8 scenariuszy E2E i progi

Testy systemowe, czyli test systemu jako całości, to poziom testowania, na którym sprawdzacie kompletny, zintegrowany produkt wobec jego specyfikacji: wszystkie moduły, bazę danych, integracje i wymagania niefunkcjonalne naraz, w środowisku możliwie podobnym do produkcji. Moduły mogą przejść swoje testy na zielono, a system i tak potrafi zawieść, bo najdroższe błędy rodzą się na styku elementów, których nikt wcześniej nie uruchomił razem. Poniżej: definicja według ISTQB, tabela różnic wobec testów integracyjnych i akceptacyjnych oraz przykładowy plan testów systemowych dla sklepu internetowego z kryteriami wejścia i wyjścia, ośmioma scenariuszami end to end, środowiskiem i decyzją, co automatyzować.

Czym są testy systemowe i co sprawdza test systemu?

Test systemu sprawdza zachowanie i możliwości całego produktu, a nie pojedynczej funkcji czy połączenia między modułami. Według sylabusa ISTQB Certyfikowany Tester Poziom Podstawowy w wersji 4.0.1 z 2024 roku testy systemowe skupiają się na ogólnym zachowaniu i możliwościach całego systemu, często obejmują funkcjonalne testy zadań end to end oraz testy niefunkcjonalne charakterystyk jakości, a podstawą testów jest specyfikacja systemu i wymagania. Sylabus, który cytujemy jako źródło definicji, podkreśla dwie rzeczy: część charakterystyk, na przykład użyteczność, lepiej testować na kompletnym systemie w reprezentatywnym środowisku, a same testy systemowe może prowadzić niezależny zespół testowy.

Ten sam sylabus wyróżnia pięć poziomów testów: modułowe, integracji modułów, systemowe, integracji systemów i akceptacyjne. Testy systemowe siedzą w środku: po nich sprawdzacie jeszcze, jak Wasz system rozmawia z systemami zewnętrznymi, i dopiero potem oddajecie produkt do akceptacji. Całą drabinę rozkładamy w przewodniku po poziomach testowania oprogramowania, więc tutaj jej nie powtarzamy.

Testy systemowe a integracyjne i akceptacyjne: czym się różnią?

Testy systemowe różnią się od sąsiadów punktem odniesienia: integracja sprawdza styki, test systemu sprawdza całość wobec specyfikacji, a akceptacja sprawdza całość wobec potrzeb biznesu. Najprościej zapamiętać to tak: testy systemowe pytają, czy zbudowaliście produkt poprawnie, a testy akceptacyjne, czy zbudowaliście właściwy produkt. Te dwa pytania często mają różne odpowiedzi. System może idealnie realizować specyfikację, w której ktoś zapomniał o zwrotach, i wtedy test systemu przejdzie, a odbiór biznesowy nie.

Z testami integracyjnymi granica przebiega na skali. Integracja weryfikuje, czy koszyk poprawnie przekazuje dane do modułu płatności. Test systemu weryfikuje, czy klient, który wrzucił do koszyka trzy produkty, użył kodu rabatowego i zapłacił BLIK-iem, dostaje fakturę, potwierdzenie mailem i zmniejszony stan magazynu. Ten poziom opisujemy w tekście o testach integracyjnych, a odbiór biznesowy w tekście o testach akceptacyjnych. Czy testy systemowe to po prostu testy end to end? Nie: scenariusze E2E są rdzeniem części funkcjonalnej, ale test systemu obejmuje też wydajność, bezpieczeństwo, kompatybilność i użyteczność. Ile scenariuszy E2E potrzebujecie, liczymy w artykule o testach end to end.

Co wchodzi do testów systemowych, a co z nich wychodzi?

Do testów systemowych wchodzi zamrożona wersja produktu, jej specyfikacja i wyniki niższych poziomów, a wychodzi raport wobec kryteriów wyjścia, lista defektów i decyzja o gotowości do akceptacji. Jeśli nie potraficie wymienić wejść i wyjść, nie macie jeszcze procesu testów systemowych, tylko okres, w którym ktoś klika po aplikacji.

Sylabus ISTQB w wersji 4.0.1 z 2024 roku nazywa to produktami pracy testowej: plan testów, przypadki i procedury testowe, dane testowe, wyniki, raporty o defektach i raport z ukończenia testów. Jak spiąć je w jeden dokument, pokazujemy w tekście o tym, jak napisać plan testów.

Co obejmuje test systemu: funkcje i charakterystyki jakości

Test systemu obejmuje wymagania funkcjonalne i niefunkcjonalne, a najwygodniejszą mapą tych drugich jest model jakości produktu z normy ISO/IEC 25010. Według opisu modelu na portalu iso25000.com norma w wersji z 2023 roku wyróżnia dziewięć charakterystyk. Sylabus ISTQB v4.0.1 odnotowuje zmianę nazw: „użyteczność” na „zdolność interakcji”, „przenośność” na „elastyczność”, plus nowa charakterystyka „bezpieczeństwo użytkowania” (safety). Nie każda wymaga osobnej kampanii testów, ale każdą warto świadomie odhaczyć albo świadomie pominąć w planie.

Pozostałe trzy, utrzymywalność, elastyczność i bezpieczeństwo użytkowania, rzadziej trafiają do testów systemowych sklepu, ale w systemach medycznych bezpieczeństwo użytkowania bywa ważniejsze od wszystkiego innego. Więcej w artykule o testach niefunkcjonalnych, a różnicę między typami a poziomami testów wyjaśniamy w tekście o typach testów oprogramowania.

Jak wygląda przykładowy plan testów systemowych dla sklepu?

Plan testów systemowych to krótki dokument, który mówi, co testujecie, na czym, od kiedy wolno zacząć i kiedy skończyć. Weźmy średni sklep internetowy: katalog, koszyk, konto klienta, trzy metody płatności, integracja z ERP i kurierem. Poniżej plan do przeczytania w pięć minut na spotkaniu z zespołem.

Zakres

W zakresie: rejestracja i logowanie, wyszukiwarka i filtry, koszyk z kodami rabatowymi, checkout z płatnością kartą, BLIK-iem i przelewem, zwroty, powiadomienia mailowe, panel administracyjny zamówień, wydajność ścieżki zakupowej, podstawy bezpieczeństwa i dostępności. Poza zakresem: integracja z marketplace’ami (testy integracji systemów) i moduł rekomendacji z osobnym cyklem wydań.

Kryteria wejścia i wyjścia

Dwa progi wydajności w kryteriach wyjścia nie są przypadkiem. Według dokumentacji web.dev zespołu Chrome z 2024 roku INP do 200 milisekund oznacza dobrą responsywność strony, a powyżej 500 milisekund słabą, mierzoną na 75. percentylu wizyt. INP mierzy jednak reakcję przeglądarki na kliknięcie, nie wytrzymałość serwera. Checkout, który świetnie reaguje przy jednym użytkowniku, może przy ruchu z Black Friday odpowiadać po kilku sekundach, a INP tego nie pokaże. Dlatego stawiacie drugi próg, po stronie serwera: 95. percentyl czasu odpowiedzi API dodania do koszyka, utworzenia zamówienia i autoryzacji płatności przy liczbie równoczesnych użytkowników ze szczytu sezonu. Liczbę milisekund ustalacie z biznesem przed testami, nie po pierwszym raporcie.

Scenariusze end to end według ryzyka

Priorytet scenariusza nie wynika z tego, co łatwo przetestować, tylko z tego, co kosztuje najwięcej, gdy przestanie działać.

Skąd E2E-01 na samej górze? Według zestawienia Baymard Institute aktualizowanego we wrześniu 2025 roku średni odsetek porzuconych koszyków wynosi 70,22 procent, a 18 procent porzucających z innego powodu niż przeglądanie zrobiło to, bo sklep wymagał konta. Zakup bez konta to ścieżka, od której zależy przychód, więc test systemu przechodzi ją jako pierwszą. Więcej scenariuszy dla sklepów zebraliśmy w tekście o testowaniu e-commerce.

Jak przygotować środowisko i dane testowe do testu systemu?

Środowisko do testów systemowych ma zachowywać się jak produkcja w czterech wymiarach: wersje komponentów, konfiguracja, skala danych i usługi zewnętrzne. Większość fałszywych zielonych wyników nie bierze się ze złych testów, tylko ze środowiska, które mówi prawdę o innym systemie niż ten, który trafi do klientów.

• Wersje, konfiguracja, topologia. Ta sama wersja bazy, serwera aplikacji i cache co na produkcji, z włączonym cache i limitami zapytań. Jeśli produkcja ma trzy instancje za load balancerem, środowisko testowe ma przynajmniej dwie, bo błędy sesji przypiętej do instancji nie wyjdą na jednym kontenerze.
• Usługi zewnętrzne. Sandboxy bramki płatności, kuriera i ERP zamiast zaślepek. Zaślepka zostaje tylko tam, gdzie dostawca sandboxa nie udostępnia, i trafia do znanych ograniczeń.
• Dane o realistycznej skali, zanonimizowane albo syntetyczne. Katalog, zamówienia i konta mają rząd wielkości produkcji, ale kopia produkcji z danymi osobowymi nie trafia na środowisko testowe bez anonimizacji. Bezpieczniejsze są dane syntetyczne z zachowanymi rozkładami: znaki diakrytyczne, kody pocztowe, adresy z numerem lokalu i bez.
• Konta i role. Gość, klient, klient B2B z fakturą na firmę, pracownik obsługi, administrator. Każdy scenariusz ma przypisane konto, żeby dało się go powtórzyć.
• Reset między przebiegami. Skrypt przywracający dane do stanu bazowego przed każdą kampanią i przebiegiem automatów. Bez niego E2E-04 o ostatniej sztuce działa tylko raz.

Dane testowe dzielcie na trzy warstwy: stałe referencyjne (katalog, stawki VAT, kraje dostawy), scenariuszowe tworzone przed testem (koszyk, kod rabatowy o znanej wartości) i wynikowe, które test sam generuje i sprząta. Dzięki temu testy biegną równolegle bez psucia sobie wyników. O budowie środowiska piszemy w artykule o środowisku testowym.

Jak przeprowadzić test systemu krok po kroku?

Test systemu przeprowadzacie w siedmiu krokach: od analizy podstawy testów po raport, na podstawie którego ktoś podejmie decyzję o wydaniu. Kolejność ma znaczenie, bo każdy krok usuwa jedną klasę fałszywych alarmów z kolejnego.

1. Analiza podstawy testów. Specyfikacja, historyjki, wymagania niefunkcjonalne, lista zmian. Wymaganie bez sposobu weryfikacji wraca do autora z pytaniem „jak poznamy, że to działa?”.
2. Analiza ryzyka i priorytety. Wpływ i prawdopodobieństwo awarii dla każdego obszaru; z tego kolejność scenariuszy jak w tabeli wyżej.
3. Projekt scenariuszy. Ścieżki szczęśliwe, alternatywne i negatywne, wartości brzegowe, do tego testy niefunkcjonalne z mierzalnymi progami.
4. Środowisko i dane. Konfiguracja według listy z poprzedniej sekcji, załadowane dane, sprawdzony reset. Kryteria wejścia odhaczone na piśmie.
5. Wykonanie. Najpierw smoke, potem scenariusze krytyczne, potem reszta. Wydajność w osobnym oknie, żeby nie fałszowała wyników funkcjonalnych.
6. Raportowanie defektów. Kroki odtworzenia, oczekiwany i faktyczny wynik, środowisko, logi, priorytet. Defekt, którego programista nie odtworzy w 10 minut, wróci z etykietą „nie da się odtworzyć”.
7. Retesty, regresja i raport końcowy. Potwierdzenie poprawek, regresja obszarów dotkniętych zmianą, raport z odniesieniem do każdego kryterium wyjścia.

Regresja to miejsce, w którym testy systemowe puchną: każde wydanie dokłada scenariusze, żaden nie znika, po roku kampania ręczna trwa tydzień. Tu zaczyna się automatyzacja.

Co automatyzować na poziomie testów systemowych?

Na poziomie systemowym automatyzujecie stabilne scenariusze krytyczne, kontrolę komunikatów do systemów zewnętrznych i pomiary niefunkcjonalne, a ręcznie zostawiacie eksplorację, ocenę użyteczności i ścieżki zmieniające się co sprint. Automat na poziomie systemu jest drogi w utrzymaniu, więc ma pilnować tego, co kosztuje najwięcej, gdy pęknie, a nie tego, co najłatwiej zaklikać. Kolumna „Automatyzacja” w tabeli scenariuszy pokazuje tę decyzję: współbieżność (E2E-04) przez API, komunikaty do ERP na poziomie kontraktu, eksploracja nowych funkcji wcale. Niżej szkielet automatu dla E2E-01 w Playwright, pisany przeciwko aplikacji demonstracyjnej. Test przechodzi przez interfejs jak klient, a na końcu sięga do API, bo zielony ekran podziękowania bez opłaconego zamówienia w bazie to dokładnie ten defekt, którego szukacie.

import { test, expect } from '@playwright/test';

test('E2E-01 gość kupuje bez konta i płaci BLIK-iem', async ({ page, request }) => {
  await page.goto('/produkt/kubek-termiczny');
  await page.getByRole('button', { name: 'Dodaj do koszyka' }).click();
  await page.getByRole('link', { name: 'Przejdź do kasy' }).click();

  await page.getByLabel('Adres e-mail').fill('gosc@example.com');
  await page.getByRole('radio', { name: 'BLIK' }).check();
  await page.getByLabel('Kod BLIK').fill('777123'); // kod testowy sandboxa bramki
  await page.getByRole('button', { name: 'Zamawiam i płacę' }).click();

  await expect(page.getByRole('heading', { name: 'Dziękujemy za zamówienie' })).toBeVisible();
  const numer = await page.getByTestId('numer-zamowienia').innerText();

  // kontrola po stronie serwera, nie tylko ekranu
  const odp = await request.get(`/api/orders/${numer}`);
  expect(odp.ok()).toBeTruthy();
  const zamowienie = await odp.json();
  expect(zamowienie.status).toBe('PAID');
  expect(zamowienie.invoiceNumber).toMatch(/^FV\//);
});

Dwie zasady utrzymują taki zestaw przy życiu: selektory oparte na rolach i etykietach, nie na klasach CSS, oraz ponowienia tylko jako sygnał ostrzegawczy: według dokumentacji Playwright test zaliczony dopiero przy ponowieniu dostaje status „flaky” i taki wynik ma trafiać do raportu jako problem do naprawy, nie znikać w zieleni. Kiedy automatyzacja się opłaca, a kiedy lepiej zostać przy testach ręcznych, porównujemy w tekście o testowaniu manualnym i automatycznym.

Regresja u Argos skróciła się z 5 dni do 10 godzin nie przez dopisanie testów, tylko dlatego, że checkout i płatności były sprawdzane przy każdym wydaniu na środowisku zachowującym się jak produkcja. U Autono, z branży automotive i wynajmu aut, system pozostał stabilny przy obciążeniu większym o 120 procent w sezonie wakacyjnym (liczba potwierdzona przez klienta, 2026). Jak to zrobić u siebie, opisujemy w artykule o tym, jak skrócić testy regresyjne z 5 dni do 10 godzin.

Jakie błędy najczęściej psują testy systemowe?

Testy systemowe najczęściej psuje nie brak testów, tylko środowisko i dane, które nie przypominają produkcji. Pięć pułapek wraca regularnie w projektach, które przejmujemy po innych zespołach, niezależnie od branży i wielkości organizacji.

Jeśli Wasz staging ma jedną dziesiątą mocy produkcji, testy wydajności na nim przypominają sprawdzanie, czy autobus zmieści pasażerów, na podstawie przejażdżki hulajnogą. Skala problemu nie jest teoretyczna: według raportu CISQ z 2022 roku koszt złej jakości oprogramowania w USA wyniósł co najmniej 2,41 biliona dolarów rocznie.

Kiedy warto zlecić testy systemowe niezależnemu zespołowi?

Testy systemowe warto zlecić niezależnemu zespołowi, gdy wymaga tego prawo albo umowa, gdy Wasz zespół nie ma kompetencji w części niefunkcjonalnej, albo gdy autorzy kodu są jedynymi testerami. Sylabus ISTQB v4.0.1 z 2024 roku zauważa, że pewien stopień niezależności czyni testera skuteczniejszym, bo autor i tester mają inne skrzywienia poznawcze. W bankowości i medycynie bywa to wymóg formalny, o czym pisze Strefa QA w tekście o tym, kiedy testy niezależne od producenta są wymogiem prawnym.

U naszych klientów najczęściej sprawdza się model mieszany: Wasz zespół zna domenę i prowadzi testy funkcjonalne, a zewnętrzny wnosi wydajność, bezpieczeństwo i świeże spojrzenie na scenariusze end to end. Taki zakres realizujemy w ramach usługi testów oprogramowania, a gdy umowa albo regulator wymaga rozdzielenia ról, jako testy niezależne od producenta oprogramowania. Osobno można zamówić testy end to end albo testy wydajności. Za nami ponad 450 000 napisanych testów automatycznych, więc wiemy, które scenariusze automatyzować od razu, a które po ustabilizowaniu interfejsu.

Jeśli wolicie zbudować te kompetencje w zespole, plan testów, kryteria wejścia i wyjścia oraz raportowanie do decydentów ćwiczymy na szkoleniu z zarządzania testami oprogramowania, wspólny język poziomów i technik daje szkolenie ISTQB Certyfikowany Tester Foundation Level 4.0, a projektowanie scenariuszy kompleksowy kurs testera manualnego. Przeszkoliliśmy ponad 2 500 specjalistów, a praktyków z polskich firm spotkacie na Testing Ground Conference.

Powiązane na blogu Quality Island

• Poziomy testowania oprogramowania: pięć poziomów ISTQB na jednym przykładzie
• Testy integracyjne: co to jest, rodzaje, przykłady i jak je wykonywać
• Testy akceptacyjne (UAT): co to jest, rodzaje i kryteria akceptacji
• Testy end to end (E2E): co to jest i ile ich naprawdę potrzebujecie
• Testowanie manualne i automatyczne: różnice i kiedy wybrać każde podejście

Pełna lista źródeł

• ISTQB, Certified Tester Foundation Level Syllabus v4.0.1, 2024. Definicja testów systemowych, pięć poziomów (rozdział 2.2.1), produkty pracy testowej, ISO/IEC 25010:2023, niezależność testowania.
• ISTQB, Glossary: system testing, wersja online, 2026.
• iso25000.com, ISO/IEC 25010, model jakości produktu, wersja z 2023 roku, dziewięć charakterystyk.
• Baymard Institute, Cart Abandonment Rate Statistics, aktualizacja z 22.09.2025. 70,22 procent porzuconych koszyków, 18 procent z powodu wymaganego konta.
• web.dev (Google Chrome), Interaction to Next Paint (INP), 2024. Progi 200 ms i 500 ms na 75. percentylu.
• Playwright, Test retries, dokumentacja, 2026. Status „flaky” po ponowieniu.
• CISQ, The Cost of Poor Quality Software in the US: A 2022 Report, 2022. Co najmniej 2,41 biliona dolarów rocznie.
• NIST, The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002. 59,5 miliarda dolarów rocznie, około 60 procent po stronie użytkowników.
• Quality Island, 2026: ponad 450 000 testów automatycznych, ponad 2 500 przeszkolonych specjalistów, case studies Argos i Autono potwierdzone przez klientów.