Raport z testów: co powinien zawierać, szablon i przykład dla zarządu

Raport z testów to dokument albo widok w narzędziu, który podsumowuje i przekazuje informacje o testach w trakcie testowania i po jego zakończeniu. Sylabus ISTQB Certyfikowany Tester v4.0 rozróżnia dwa rodzaje: raport o postępie testów, wydawany regularnie, oraz sumaryczny raport z testów, wydawany raz, na koniec poziomu, cyklu albo projektu. Dobry raport kończy się jednym zdaniem, które decydent może powtórzyć na zarządzie: wydajemy, wydajemy warunkowo albo nie wydajemy.

Poniżej dostajecie wszystko, czego brakuje w większości poradników: przykładowy raport z testów wypełniony danymi, szablon do skopiowania i do pobrania w formacie DOCX, tabelę metryk z sylabusa, zasady decyzji o wydaniu oraz porównanie narzędzi, które generują raport automatycznie z potoku CI.

Czym jest raport z testów i jakie są jego dwa rodzaje?

Według sylabusa ISTQB CTFL v4.0 (sekcja 5.3.2) raporty o postępie testów wspierają bieżący nadzór nad testami i muszą dawać dość informacji, żeby zmienić harmonogram, zasoby albo plan testów, gdy coś idzie inaczej. Sumaryczny raport z testów podsumowuje konkretny etap, na przykład poziom testów, cykl testowy albo iterację, i może zasilać kolejne testowanie.

Źródło: sylabus ISTQB CTFL v4.0.1, sekcje 5.3.2 i 5.3.3, 2024 (polska wersja SJSI 4.0.0.1, 2025).

Sylabus wymienia też kanały, którymi przekazujecie status testów: rozmowę, tablice i dashboardy w CI/CD, kanały elektroniczne, dokumentację online i formalne raporty. Zespół, który siedzi w jednym pokoju, może żyć z rozmowy i tablicy. Zespół rozproszony albo dostawca pracujący dla klienta potrzebuje formy pisemnej, bo bez niej każda rozmowa o jakości zaczyna się od pytania „a skąd to wiecie?”.

Co powinien zawierać sumaryczny raport z testów?

Sumaryczny raport z testów ma według sylabusa ISTQB siedem typowych elementów. Każdy odpowiada na inne pytanie decydenta, więc brak któregokolwiek zostawia lukę, którą odbiorca wypełni domysłem.

Źródło: sylabus ISTQB CTFL v4.0.1, sekcja 5.3.2, 2024; przykładowe zdania: Quality Island.

Zwróćcie uwagę na drugi wiersz: ocena dotyczy zarówno produktu, jak i samego testowania. Raport, który mówi tylko o defektach, a milczy o tym, czego nie przetestowano, daje decydentowi fałszywe poczucie bezpieczeństwa. Skąd biorą się kryteria wyjścia, wyjaśniamy w poradniku jak napisać plan testów, bo raport i plan muszą mówić tym samym językiem.

Jak wygląda przykładowy raport z testów dla zarządu?

Poniżej przykładowy raport z testów, a dokładniej jego pierwsza strona, którą czyta zarząd. Dane są przykładowe, ale struktura pochodzi z raportów, które przygotowujemy w projektach testowych. Reszta raportu to załączniki dla zespołu technicznego.

Źródło: przykład Quality Island z fikcyjnymi danymi.

Kolumna „kto zaakceptował” jest najważniejsza w całej tabeli. Nie wszystkie defekty trzeba usuwać przed wydaniem, ale każdy nieusunięty musi mieć właściciela decyzji. Defekt bez właściciela decyzji ma niezwykłą zdolność do przypominania sobie o nas w piątek o 17:30. Jak opisać defekt, żeby decyzja była łatwa, pokazujemy w poradniku jak poprawnie zgłosić błąd.

Szablon raportu z testów do pobrania i skopiowania

Szablon ma osiem sekcji, w kolejności z sylabusa ISTQB, z dodaną metryczką na początku i załącznikami na końcu. Wersję edytowalną w Wordzie pobierzecie tutaj: szablon raportu z testów, DOCX. Wersję tekstową możecie skopiować do Confluence, wiki albo pliku Markdown w repozytorium.

# Sumaryczny raport z testów: [produkt] [wersja]

Zakres: [poziom testów / cykl / iteracja]   Okres: [od] do [do]
Autor: [imię, rola]   Odbiorcy: [PO, PM, sponsor, zespół]

## 1. Podsumowanie dla decydenta (maks. 5 zdań)
Rekomendacja: WYDANIE | WYDANIE WARUNKOWE | BRAK ZGODY
Powód, stan kryteriów wyjścia, otwarte defekty krytyczne i wysokie,
największe ryzyko rezydualne, warunek wydania.

## 2. Ocena względem planu testów
| Kryterium wyjścia | Cel | Wynik | Spełnione |

## 3. Odstępstwa od planu testów
Harmonogram, czas, nakład pracy, czego nie przetestowano i dlaczego.

## 4. Utrudnienia i sposoby obejścia
| Utrudnienie | Wpływ | Obejście |

## 5. Metryki
Postęp testów, defekty według priorytetu, pokrycie wymagań,
jakość produktu (np. p95 czasu odpowiedzi), ryzyko rezydualne.

## 6. Niezłagodzone ryzyka i nieusunięte defekty
| ID | Opis | Priorytet | Decyzja | Kto zaakceptował |

## 7. Zdobyte doświadczenia
Co zmieniamy w następnym cyklu.

## 8. Załączniki
Raport z narzędzia (Allure, Playwright HTML), eksport defektów,
raporty o postępie testów.

Jeśli Wasza organizacja potrzebuje formalnych wzorców, punktem odniesienia jest norma ISO/IEC/IEEE 29119-3, na którą powołuje się sylabus. Zawiera szablony i przykłady raportu o statusie testów i raportu z ukończenia testów. W praktyce większość zespołów zwinnych bierze z niej strukturę, a formę upraszcza do jednej strony plus załączniki.

Jakie metryki umieścić w raporcie z testów?

Sylabus ISTQB (sekcja 5.3.1) dzieli metryki testowe na siedem kategorii. Do raportu nie bierzecie wszystkich, tylko te, które odpowiadają na pytania Waszych odbiorców.

Źródło: sylabus ISTQB CTFL v4.0.1, sekcja 5.3.1, 2024.

Najmocniejsza metryka dla zarządu to zwykle taka, która łączy testy z czasem albo pieniędzmi. W projekcie dla Argos, sklepu internetowego, raport po automatyzacji pokazywał skrócenie regresji przed wydaniem z 5 dni do 10 godzin i spadek błędów krytycznych na produkcji o 46%, a to są liczby, które rozumie każdy członek zarządu. Jak przekładać wyniki QA na język finansów, opisujemy w artykule o KPI dla zarządu i rozmowie z CFO, a szerzej o metrykach w tekście jak mierzyć jakość oprogramowania.

Jak raport wspiera decyzję o wydaniu?

Raport nie podejmuje decyzji o wydaniu, ale powinien ją ułatwić tak bardzo, żeby stała się formalnością. Najprościej osiągnąć to tabelą decyzyjną uzgodnioną z biznesem jeszcze w planie testów.

Źródło: praktyka Quality Island, 2026, na podstawie kryteriów wyjścia z sekcji 5.1.3 sylabusa ISTQB CTFL v4.0.1.

Zespół testowy rekomenduje, biznes decyduje i przejmuje ryzyko. Ten podział ról chroni obie strony, a raport jest jego pisemnym śladem.

Jaki system raportowania testów wybrać: Allure, Playwright, CI?

System raportowania testów zbiera wyniki automatów i zamienia je w czytelny widok. Dobór zależy od tego, czym testujecie i gdzie zespół patrzy na wyniki. Poniżej narzędzia, które najczęściej spotykamy u klientów.

Źródło: Allure Report, Playwright, GitHub Docs, 2026; praktyka Quality Island.

Przykładowa konfiguracja Playwright, która generuje raport HTML dla ludzi i JUnit XML dla potoku:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [
    ['list'],
    ['html', { open: 'never' }],
    ['junit', { outputFile: 'wyniki/junit.xml' }],
  ],
});

A tak raport trafia do podsumowania przebiegu w GitHub Actions i jako artefakt do pobrania:

      - name: Testy E2E
        run: npx playwright test

      - name: Podsumowanie wyników
        if: always()
        run: |
          echo "### Wyniki testów E2E, commit ${GITHUB_SHA::7}" >> "$GITHUB_STEP_SUMMARY"
          head -n 3 wyniki/junit.xml | grep -o 'tests="[0-9]*"\|failures="[0-9]*"\|skipped="[0-9]*"' >> "$GITHUB_STEP_SUMMARY"

      - name: Raport HTML jako artefakt
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: raport-playwright
          path: playwright-report/

Narzędzie daje raport o postępie testów, ale nie zastąpi sumarycznego raportu z testów. Allure nie wie, który defekt Product Owner zaakceptował i dlaczego. Ten kontekst dopisuje człowiek. O tym, jak dashboardy potrafią wprowadzać w błąd, piszemy na portalu Strefa QA w tekście dlaczego Twój dashboard jakości kłamie. Konfigurację raportowania w Playwright i w potoku ćwiczymy na szkoleniu Automatyzacja testów z narzędziem Playwright, a w Jenkinsie na szkoleniu CI/CD dla testerów: Jenkins.

Czym różni się raport z testów penetracyjnych i z audytu?

Raport z testów penetracyjnych i raport z audytu dostępności mają inną strukturę niż raport z testów funkcjonalnych, bo odbiorca szuka w nich czegoś innego. Raport z testów penetracyjnych zawiera zwykle zakres i metodykę, listę podatności z oceną ważności, opis odtworzenia, dowody i zalecenia naprawcze, a na końcu wynik ponownego testu po poprawkach. Raport z audytu dostępności odnosi każde znalezisko do konkretnego kryterium sukcesu WCAG. Przykład takiego dokumentu możecie obejrzeć na stronie przykładowy raport z audytu WCAG, a zakres testów bezpieczeństwa opisujemy na stronie usługi testy bezpieczeństwa.

Jakie błędy odbierają raportowi wartość?

Te same błędy widzimy w raportach od lat, niezależnie od branży i wielkości zespołu.

• Jeden raport dla wszystkich. Logi z konsoli na pierwszej stronie dla zarządu sprawiają, że zarząd nie czyta dalej.
• Brak rekomendacji. Raport bez zdania „wydajemy, warunkowo albo nie” przerzuca analizę na osobę, która ma najmniej danych.
• Przemilczany zakres nieprzetestowany. 100% zaliczonych testów przy pominiętym module płatności to raport, nie jakość.
• Defekty bez decyzji. Lista otwartych błędów bez właściciela akceptacji wraca jako spór po wdrożeniu.
• Metryki bez kontekstu. „37 defektów” nic nie mówi bez priorytetów, trendu i porównania z poprzednim wydaniem.
• Raport pisany od zera. Bez szablonu każdy raport wygląda inaczej i nikt nie porówna dwóch wydań.

Z naszego doświadczenia najprostsza poprawa to szablon plus jedna strona podsumowania. Jeśli chcecie uporządkować raportowanie i całą dokumentację testową, robimy to w ramach usługi dokumentacja testowa, a gdy potrzebujecie osoby, która poprowadzi testy i raportowanie za Was, w modelu zarządzania testami QA. Pełny rozdział 5 sylabusa, z metrykami i raportami, omawiamy na szkoleniu Certyfikowany Tester Poziom Podstawowy v4.0.

Powiązane na blogu Quality Island

• KPI dla zarządu: jak przełożyć wyniki QA na język, który rozumie CFO
• Jak napisać plan testów: kompletny przewodnik po dokumencie, który ratuje budżet
• Jak poprawnie zgłosić błąd: praktyczny przewodnik
• Jak mierzyć jakość oprogramowania: od opinii do twardych metryk
• Środowisko testowe: jak je zbudować i utrzymać

Pełna lista źródeł

• ISTQB, Certified Tester Foundation Level Syllabus v4.0.1, 2024. Sekcje 5.3.1 do 5.3.3: metryki, raport o postępie testów, sumaryczny raport z testów, kanały komunikacji.
• SJSI, Sylabus ISTQB Certyfikowany Tester Poziom Podstawowy w. 4.0, wersja polska 4.0.0.1, 2025. Polskie nazwy: raport o postępie testów, sumaryczny raport z testów.
• ISO/IEC/IEEE, ISO/IEC/IEEE 29119-3 Test documentation, 2021. Wzorce raportu o statusie testów i raportu z ukończenia testów.
• John Micco, Google Testing Blog, Flaky Tests at Google and How We Mitigate Them, 2016. Około 84% przejść z zaliczonego na niezaliczony z udziałem testu niestabilnego, niemal 16% testów z niestabilnością.
• Qameta Software, Allure Report, 2026. Licencja Apache 2, integracje z ponad 50 narzędziami, historia, trendy, testy niestabilne.
• Microsoft, Playwright, Reporters, 2026. Wbudowane reportery i polecenie show-report.
• GitHub Docs, Workflow commands: adding a job summary, 2026. GITHUB_STEP_SUMMARY i limit 1 MiB na krok.
• Dane własne Quality Island, 2026: case study Argos (regresja z 5 dni do 10 godzin, spadek błędów krytycznych na produkcji o 46%, liczby potwierdzone przez klienta), szablon raportu z testów.