Poziomy testowania oprogramowania: pięć poziomów ISTQB na jednym przykładzie

Poziomy testowania oprogramowania, w skrócie poziomy testów, to etapy, na których sprawdzacie system w coraz większych kawałkach: od pojedynczej funkcji, przez współpracę modułów i cały system, po odbiór przez biznes. Każdy poziom ma inny cel, innego właściciela i łapie inny rodzaj błędu. Sylabus ISTQB Foundation Level w wersji 4.0 opisuje dziś pięć poziomów testów, nie cztery, i ta zmiana ma praktyczne skutki dla tego, jak planujecie testy integracji.

W tym przewodniku pokazujemy wszystkie poziomy na jednym przykładzie: kodzie rabatowym w sklepie internetowym. Zobaczycie, jaki błąd wychodzi na którym poziomie, jak wygląda test jednostkowy, test API i test end to end tej samej funkcji oraz jak rozłożyć wysiłek między poziomy, żeby regresja nie trwała tydzień.

Czym są poziomy testowania oprogramowania?

Poziom testów to grupa czynności testowych, które dotyczą jednego etapu składania systemu w całość. Sylabus ISTQB rozróżnia poziomy po pięciu cechach: przedmiocie testów, celach, podstawie testów (z czego wyprowadzacie przypadki testowe), typowych defektach i awariach oraz podejściu i odpowiedzialności. Dzięki temu dwa zespoły nie testują dwa razy tego samego, a jednocześnie nikt nie zostawia dziury między „to sprawdził programista” a „to sprawdzi klient”.

Najprostszy test, czy poziomy w Waszym projekcie działają: weźcie ostatni błąd z produkcji i zapytajcie, na którym poziomie powinien był wyjść. Jeśli odpowiedź brzmi „na jednostkowym” albo „na integracji modułów”, a wyszedł u użytkownika, macie lukę w niższych poziomach, której nie załata żadna liczba testerów klikających na końcu.

Powód jest ekonomiczny. Raport NIST z 2002 roku pokazuje przykładowy rozkład kosztu naprawy defektu: jeśli błąd znaleziony przy wymaganiach kosztuje 1 jednostkę, to przy kodowaniu i testach jednostkowych kosztuje 5, przy testach integracyjnych i systemowych 10, w testach beta 15, a po wydaniu 30. NIST zaznacza, że to przykład, a nie stała przyrody, ale kierunek potwierdza każdy, kto szukał przyczyny awarii w piątek wieczorem.

Jakie są poziomy testów według ISTQB 4.0?

Według sylabusa ISTQB Certified Tester Foundation Level 4.0 (aktualne wydanie 4.0.1 z 2024 roku) poziomów jest pięć. Dawny jeden poziom „testy integracyjne” został rozdzielony na dwa: integrację komponentów i integrację systemów. Jeśli uczyliście się z materiałów sprzed 2023 roku albo z grafik pokazujących cztery poziomy, to nadal ten sam model, tylko z precyzyjniej nazwaną integracją.

Dlaczego ten podział ma znaczenie w praktyce? Bo integracja modułów w jednym repozytorium i integracja z bankiem, kurierem albo systemem ERP to dwa różne światy. Pierwsza działa na zaślepkach i uruchamia się w kilka sekund w potoku CI. Druga wymaga środowiska podobnego do produkcyjnego, danych testowych po stronie partnera i często umówionego okna czasowego. Wrzucenie obu do jednego worka kończy się tym, że testy integracji systemów odbywają się dopiero na produkcji, a tego raczej nikt nie planował.

Grafika powyżej pokazuje poziomy testów w klasycznym ujęciu, z czterema etapami. Zwróćcie uwagę na dopisek przy testach integracyjnych: „wewnętrzne, zewnętrzne”. To dokładnie te dwa poziomy, które ISTQB 4.0 nazywa osobno: integracja komponentów i integracja systemów.

Czym różnią się poziomy testów od rodzajów testów?

Poziom mówi, co testujecie i na którym etapie składania systemu. Rodzaj (typ) testu mówi, jaką cechę sprawdzacie: funkcję, wydajność, bezpieczeństwo, użyteczność. Te dwa wymiary się krzyżują. Test wydajności możecie zrobić na poziomie komponentu (czy funkcja liczy rabat w 2 milisekundy) i na poziomie systemu (czy koszyk wytrzymuje tysiąc użytkowników naraz). Testy regresyjne też nie są poziomem, tylko testami związanymi ze zmianą, które powtarzacie na każdym poziomie po modyfikacji kodu.

Jeśli szukacie przeglądu typów, czyli funkcjonalnych, niefunkcjonalnych, strukturalnych i regresji, opisujemy je osobno w artykule rodzaje testów oprogramowania: funkcjonalne, niefunkcjonalne, strukturalne i regresja. Tutaj trzymamy się poziomów. Mylenie poziomu z rodzajem testu to jak mylenie piętra z pokojem: na każdym piętrze może być kuchnia, ale nikt nie mówi, że mieszka na kuchni.

Testy jednostkowe (modułowe): co sprawdzają?

Testy jednostkowe, nazywane też modułowymi albo testami komponentów (unit testy), sprawdzają najmniejszy fragment kodu w izolacji: funkcję, metodę, klasę. Zależności, takie jak baza danych czy zewnętrzne API, zastępujecie zaślepkami, dzięki czemu test trwa milisekundy i daje ten sam wynik przy każdym uruchomieniu. Według sylabusa ISTQB zwykle piszą je programiści w swoim środowisku, często z użyciem frameworka testów jednostkowych.

Dobry test jednostkowy sprawdza zachowanie, a nie implementację. Test, który pęka przy każdej zmianie nazwy prywatnej metody, uczy zespół ignorować czerwone wyniki. Test, który sprawdza „dla koszyka 200 zł z kodem WIOSNA10 cena wynosi 180 zł”, przetrwa każdy refaktor, dopóki reguła biznesowa się nie zmieni. Narzędzia: JUnit 5 dla Javy, pytest dla Pythona, NUnit i xUnit dla C#, Jest i Vitest dla JavaScriptu.

Czy tester musi umieć pisać testy jednostkowe? Nie zawsze, ale tester, który czyta je ze zrozumieniem, umie wskazać brakujące warunki brzegowe jeszcze przed code review. Właśnie z tego powodu prowadzimy osobne szkolenie testowanie komponentowe i testy jednostkowe dla testerów.

Testy integracyjne: integracja modułów czy systemów?

Testy integracyjne sprawdzają punkty styku. Na poziomie integracji komponentów pytacie, czy moduł koszyka i moduł cen rozumieją się nawzajem: czy przekazują kwotę w tym samym formacie, czy obsługują pusty kod rabatowy, czy błąd jednego modułu nie wywraca drugiego. ISTQB zwraca uwagę, że ten poziom mocno zależy od strategii integracji: od dołu, od góry albo wszystko naraz (big bang). Na poziomie integracji systemów pytacie o to samo, ale między Waszym systemem a światem zewnętrznym: bramką płatności, kurierem, systemem księgowym.

Testy jednostkowe a integracyjne: różnica nie leży w narzędziu, tylko w tym, co zastępujecie zaślepką. W teście jednostkowym zaślepką jest wszystko poza testowaną jednostką. W teście integracji komponentów prawdziwe są co najmniej dwa moduły i ich interfejs. Do testów API na tym poziomie sprawdzają się REST Assured i Postman. Szerzej piszemy o tym w artykule testy integracyjne: co to jest, rodzaje i przykłady, a praktykę ćwiczycie na szkoleniu REST Assured: testy integracyjne API dla testerów.

Testy systemowe: co sprawdzić, gdy całość już działa?

Testy systemowe oceniają zintegrowany system jako całość: pełne przepływy end to end oraz cechy niefunkcjonalne, takie jak wydajność, bezpieczeństwo i użyteczność. Sylabus ISTQB podkreśla, że część cech, na przykład użyteczność, lepiej sprawdzać na kompletnym systemie w reprezentatywnym środowisku, a same testy systemowe może prowadzić niezależny zespół, który opiera się na specyfikacji systemu.

To poziom, na którym najczęściej pracują testerzy manualni i automatyzujący. Tu sprawdzacie, czy klient może dodać produkt, wpisać kod, zapłacić i dostać potwierdzenie, a także czy ta sama ścieżka działa w trzech przeglądarkach i na telefonie. Więcej o samym poziomie piszemy w tekście testy systemowe: czym są i jak je przeprowadzić, a jeśli potrzebujecie wsparcia z zewnątrz, zakres i ceny pokazuje strona testów funkcjonalnych aplikacji.

Testy akceptacyjne: kto decyduje, że system jest gotowy?

Testy akceptacyjne odpowiadają na pytanie biznesowe: czy system spełnia potrzeby użytkownika i można go wdrożyć. ISTQB wymienia ich główne formy: testy akceptacyjne użytkownika (UAT), operacyjne, kontraktowe, regulacyjne oraz testy alfa i beta. Najlepiej, gdy wykonują je docelowi użytkownicy, a nie zespół, który system zbudował.

Najczęstszy problem na tym poziomie nie jest techniczny. To brak mierzalnych kryteriów akceptacji, przez co odbiór zamienia się w spór o interpretację. W Quality Island prowadziliśmy procedury odbiorcze dla ChaosGears z branży medycznej i z naszego doświadczenia wynika jedno: kryteria spisane przed startem prac skracają odbiór bardziej niż jakakolwiek automatyzacja. Rozwinięcie tematu znajdziecie w artykule testy akceptacyjne (UAT): rodzaje i kryteria akceptacji.

Jeden rabat, pięć poziomów: gdzie wychodzi który błąd?

Weźmy jedną funkcję: kod WIOSNA10 daje 10 procent rabatu na koszyk od 200 zł. Prosta reguła, a na każdym poziomie może pójść źle w inny sposób. Poniżej po kolei, z fragmentami testów, które te błędy łapią.

Poziom komponentu. Programista pisze warunek > 200 zamiast >= 200. Koszyk za dokładnie 200 zł nie dostaje rabatu. Test jednostkowy z wartościami granicznymi łapie to w milisekundę, zanim kod trafi do przeglądu:

// Java 21, JUnit 5
import static org.junit.jupiter.api.Assertions.assertEquals;

import java.math.BigDecimal;
import java.math.RoundingMode;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;

final class DiscountCalculator {
    static BigDecimal finalPrice(BigDecimal cartTotal, String code) {
        if (cartTotal.signum() < 0) {
            throw new IllegalArgumentException("Kwota koszyka nie może być ujemna");
        }
        boolean eligible = "WIOSNA10".equals(code)
                && cartTotal.compareTo(new BigDecimal("200.00")) >= 0;
        BigDecimal result = eligible ? cartTotal.multiply(new BigDecimal("0.90")) : cartTotal;
        return result.setScale(2, RoundingMode.HALF_UP);
    }
}

class DiscountCalculatorTest {
    @ParameterizedTest
    @CsvSource({"199.99, 199.99", "200.00, 180.00", "350.00, 315.00"})
    void appliesDiscountFromThreshold(String total, String expected) {
        assertEquals(new BigDecimal(expected),
                DiscountCalculator.finalPrice(new BigDecimal(total), "WIOSNA10"));
    }
}

Poziom integracji komponentów. Moduł cen zwraca kwotę jako BigDecimal, a moduł koszyka zapisuje ją jako liczbę zmiennoprzecinkową. Przy niektórych kwotach klient widzi 179,99 zł zamiast 180,00 zł. Każdy moduł osobno przechodzi swoje testy, błąd siedzi w interfejsie. Łapie go test API, który wywołuje oba moduły naraz:

// Java 21, REST Assured, przykładowy endpoint wyceny koszyka
import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;

import io.restassured.http.ContentType;
import org.junit.jupiter.api.Test;

class CartQuoteApiTest {
    @Test
    void quoteAppliesDiscountCode() {
        given()
            .contentType(ContentType.JSON)
            .body("""
                {"items": [{"sku": "KUBEK-01", "qty": 2, "price": "100.00"}], "code": "WIOSNA10"}
                """)
        .when()
            .post("/api/cart/quote")
        .then()
            .statusCode(200)
            .body("total", equalTo("180.00"));
    }
}

Poziom systemu. Logika i API działają, ale po wpisaniu kodu interfejs nie odświeża sumy, dopóki użytkownik nie przeładuje strony. Tego nie zobaczy ani test jednostkowy, ani test API. Łapie to test end to end, na przykład w Playwright:

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

test('kod WIOSNA10 obniża sumę koszyka bez przeładowania strony', async ({ page }) => {
  await page.goto('/koszyk');
  await page.getByLabel('Kod rabatowy').fill('WIOSNA10');
  await page.getByRole('button', { name: 'Zastosuj' }).click();
  await expect(page.getByTestId('cart-total')).toHaveText('180,00 zł');
});

Poziom integracji systemów. Sklep pokazuje 180 zł, ale do bramki płatności i do systemu księgowego trafia kwota sprzed rabatu. Klient płaci 180 zł, faktura opiewa na 200 zł. Tu potrzebujecie środowiska z prawdziwym (testowym) kontem bramki i wglądu w dokumenty po stronie systemu finansowego.

Poziom akceptacji. Wszystko działa zgodnie ze specyfikacją, ale dział sprzedaży podczas UAT zauważa, że rabat nalicza się także na produkty już przecenione, a tego nikt nie chciał. To nie jest błąd kodu, tylko luka w wymaganiu. Tylko odbiorca może ją wskazać, bo tylko on zna intencję biznesową.

Jak poziomy testów łączą się z piramidą testów?

Piramida testów to model proporcji: dużo szybkich testów na dole, mało wolnych testów na górze. Martin Fowler w tekście „The Practical Test Pyramid” z 2018 roku formułuje to wprost: piszcie wiele małych, szybkich testów jednostkowych, trochę testów o średniej szczegółowości i bardzo mało testów wysokopoziomowych, przechodzących przez całą aplikację. Według książki „Software Engineering at Google” (2020) zespoły Google celują orientacyjnie w proporcję 80 procent testów jednostkowych, 15 procent integracyjnych i 5 procent end to end.

Te liczby to wskazówka, nie norma do audytu. Ważniejszy jest kierunek: odwrócona piramida, czyli setki testów przez interfejs i garść jednostkowych, daje długie i niestabilne przebiegi. Blog Google Testing już w 2015 roku nazwał to wprost w tekście „Just Say No to More End-to-End Tests”: test end to end mówi, że coś się zepsuło, ale rzadko mówi gdzie. U naszych klientów widzimy ten sam wzór. W projekcie dla Argos z branży e-commerce uporządkowanie automatyzacji i procesów QA skróciło regresję przed wydaniem z 5 dni do 10 godzin, co opisujemy w case study jak skrócić testy regresyjne z 5 dni do 10 godzin. Pełne omówienie modelu i proporcji znajdziecie w artykule o piramidzie testów i technikach projektowania testów.

Kiedy automatyzować poziomy testów?

Im niższy poziom, tym szybszy i tańszy zwrot z automatyzacji. Im wyższy, tym bardziej opłaca się wybierać tylko najważniejsze ścieżki. Poniżej podejście, które stosujemy przy wdrożeniach automatyzacji; w Quality Island napisaliśmy ponad 450 000 testów automatycznych i ten podział sprawdza się niezależnie od branży.

• Testy komponentów: automatyzujcie niemal w całości, uruchamiajcie przy każdym commicie. To Wasza najszybsza siatka bezpieczeństwa.
• Integracja komponentów: automatyzujcie kontrakty API i krytyczne interfejsy między modułami, w potoku CI na zaślepkach usług zewnętrznych.
• Testy systemowe: automatyzujcie stabilne, powtarzalne ścieżki regresji (logowanie, zakup, płatność), resztę zostawcie testom eksploracyjnym.
• Integracja systemów: automatyzujcie kilka testów dymnych na środowisku z prawdziwymi integracjami, uruchamianych po każdym wdrożeniu.
• Testy akceptacyjne: automatyzujcie ostrożnie i tylko krytyczne scenariusze, najlepiej zapisane razem z biznesem, bo wymagania na tym poziomie zmieniają się najczęściej.

Jeśli chcecie zbudować taki podział od zera albo naprawić odwróconą piramidę, pomagamy w ramach usługi automatyzacji testów. Zespoły, które wolą zrobić to samodzielnie, szkolimy z automatyzacji testów z narzędziem Playwright, a podstawy całego modelu poziomów porządkuje szkolenie Certyfikowany Tester Foundation Level 4.0. Typowe pułapki zespołów, które próbują przeskoczyć niższe poziomy, opisuje też Strefa QA w tekście o najczęstszych antywzorcach w testowaniu oprogramowania.

Jak uporządkować poziomy testów w Waszym zespole?

Zacznijcie od danych, nie od narzędzi. Weźcie 20 ostatnich błędów z produkcji i przy każdym zapiszcie, na którym poziomie powinien był wyjść. Ten prosty arkusz zwykle pokazuje jedną dominującą lukę, najczęściej integrację komponentów albo integrację systemów, i od niej warto zacząć.

1. Nazwijcie właściciela każdego poziomu. Kto pisze testy jednostkowe, kto odpowiada za kontrakty API, kto za środowisko integracji systemów, kto podpisuje odbiór.
2. Zapiszcie kryteria wejścia i wyjścia. Na przykład: do testów systemowych wchodzi tylko build z zielonymi testami jednostkowymi i integracyjnymi.
3. Policzcie czas regresji. Jeśli pełny przebieg trwa dłużej niż jeden dzień roboczy, problemem prawie na pewno jest kształt piramidy, nie liczba testerów.
4. Ustalcie kryteria akceptacji przed startem prac. Razem z biznesem, w języku mierzalnym, zgodnie z podejściem shift left.
5. Wpiszcie to wszystko do planu testów. Poziomy, właściciele i kryteria to szkielet każdego planu testów.

Chcecie porozmawiać o tym na żywo z ludźmi, którzy robią to w największych zespołach w Polsce? Poziomy testów i automatyzacja wracają co roku na scenie Testing Ground Conference, największej konferencji z obszaru QA w Polsce.

Powiązane na blogu Quality Island

• Typy testów oprogramowania: funkcjonalne, niefunkcjonalne, strukturalne i regresja
• Testy integracyjne: co to jest, rodzaje, przykłady
• Testy akceptacyjne (UAT): co to jest, rodzaje, kryteria akceptacji
• Testy end to end (E2E): kiedy je uruchamiać i ile ich potrzeba
• Sylabus ISTQB Certyfikowany Tester: wersja 4.0 a 3.1

Pełna lista źródeł

• ISTQB, Certified Tester Foundation Level Syllabus v4.0.1, 2024. Stąd pięć poziomów testów, ich definicje, formy testów akceptacyjnych i informacja o rozdzieleniu poziomu integracji.
• NIST, The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002, tabela 5-1. Stąd przykładowy względny koszt naprawy defektu: 1x, 5x, 10x, 15x, 30x.
• Titus Winters, Tom Manshreck, Hyrum Wright, Software Engineering at Google, rozdział 11: Testing Overview, 2020. Stąd proporcja 80/15/5 i historia zespołu Google Web Server.
• Martin Fowler, Ham Vocke, The Practical Test Pyramid, 2018.
• Google Testing Blog, Just Say No to More End-to-End Tests, 2015.
• Dane własne Quality Island, 2026: ponad 450 000 napisanych testów automatycznych, case study Argos z liczbami potwierdzonymi przez klienta, procedury odbiorcze dla ChaosGears.