1. Účel a distribuce reportu
Test Report nesmí být pouze statickým výpisem chybových logů. Je to dokument, který překládá surová testovací data do byznysového a projektového kontextu, což je klíčové například při sestavování pravidelných výstupů pro Provozní monitoring NeL.
- Zodpovědnost: Test Manager / QA Lead.
- Vstupní data: Výsledky automatizovaných CI/CD pipeline, manuální exekuce a výkonnostní metriky.
- Cílové publikum (Distribuční list): Projektoví manažeři, Product Owners a techničtí leadeři (vývoj, DevOps, architektura).
2. Standardizovaná struktura Test Reportu
Každý oficiální Test Report musí striktně dodržovat následující hierarchii kapitol:
A. Hlavička dokumentu a Metadata
Základní identifikace testovacího cyklu pro účely zpětné dohledatelnosti a auditu.
- Název projektu: (např. Provozní monitoring – Release 2.4)
- Verze testovaného softwaru (Build ID): Přesná identifikace nasazené verze a prostředí (např. Staging-Env-v2.4.0-rc1).
- Datum a čas exekuce: Časový rámec, ve kterém testy probíhaly.
B. Manažerské shrnutí (Executive Summary)
Nejdůležitější část pro netechnický management. Musí obsahovat jasné doporučení bez složitého IT žargonu.
- Status kvality: Doporučeno k nasazení (GO) / Nasazení s výhradami (CONDITIONAL GO) / Zamítnuto (NO-GO).
- Stručné zhodnocení: Krátký odstavec shrnující stav testování.
- Příklad: „Všechny kritické E2E scénáře proběhly úspěšně. Výkonnostní testy splnily SLA. Evidujeme 3 minoritní defekty v UI, které neblokují hlavní byznys flow. Verze je připravena k nasazení.“
C. Analýza výsledků testů a Vizualizace (Grafy)
Tvrdá data agregovaná z testovacích nástrojů. Pro zajištění absolutní důvěryhodnosti dat se grafy netvoří manuálně v Excelu, ale vkládají se jako exporty přímo z centrálních analytických nástrojů (např. Grafana).
Povinné vizualizace v reportu:
- Test Execution Status (Pie Chart / Donut Chart): Zobrazuje celkový poměr testů: Passed, Failed, Blocked, Skipped.
- Analytický pohled: Vysoké procento Skipped nebo Blocked okamžitě indikuje nestabilitu testovacího prostředí.
- Defect Density & Severity (Bar Chart): Rozložení nalezených chyb podle jejich závažnosti (Blocker, Critical, Major, Minor).
- Analytický pohled: Definuje fundamentální zdraví dodávky.
- Defect Burn-down / Trend Chart (Line Chart): Vývoj počtu otevřených vs. vyřešených chyb v čase.
- Analytický pohled: Křivka musí před koncem releasu konvergovat k nule.
D. Seznam defektů a strategie jejich řešení (Defect Log)
Filtr těch nejdůležitějších chyb. Ukazuje přidanou hodnotu QA týmu a definuje „technologický dluh“, se kterým systém případně spouštíme do produkce.
1. Vyřešené kritické chyby (Resolved Blockers)
Záznam katastrofických chyb, které testování odhalilo a které byly ještě před nasazením úspěšně odstraněny.
- Příklad zápisu:
BUG-892Databáze padala do deadlocku při paralelním zápisu 500 uživatelů. Řešení: Úprava architektury indexů a přepsání logiky connection poolu. Oprava plně validována zátěžovým testem.
2. Známé chyby a náhradní řešení (Known Issues & Workarounds)
Seznam otevřených chyb (Minor/Major), které jsme pro tento release vědomě akceptovali. Je to kritický podklad pro oddělení zákaznické podpory (Support).
| ID Defektu | Popis problému (Bug Description) | Dopad na byznys (Impact) | Náhradní řešení pro Support (Workaround) | Plánovaná oprava (Target Fix) |
|---|---|---|---|---|
| BUG-904 | Při generování reportu nad 5 let spadne systém na Timeout. | Nízký. Běžný uživatel reportuje data max. za 1 rok. Týká se < 1 % případů. | Uživatel si musí report vygenerovat po menších částech (např. 2 roky) a spojit data lokálně. | Zaplánováno do vývoje pro minor release (v2.4.1). |
| BUG-905 | Na platformě Apple (Safari) se rozpadá CSS grid u výběru data. | Střední. 15 % uživatelů používá Safari. Funkčnost to neblokuje, pouze UI vrstvu. | Support instruován komunikovat chybu jako vizuální a doporučit prohlížeč Chrome. | Frontend tým pracuje na opravě, priorita High pro nejbližší Hotfix. |
E. Identifikovaná rizika a úzká hrdla (Risk Analysis)
Překlad technických limitů a chyb do řeči projektových rizik.
- Příklad zápisu: „Během výkonnostního testování jsme narazili na limit IOPS u databáze. Existuje reálné riziko zpomalení odezvy při produkční špičce nad očekávaný standard. Doporučujeme pro prvních 48 hodin po nasazení aktivovat výjimečný monitoring na databázové vrstvě.“
F. Plán dalších kroků (Action Plan)
Konkrétní úkoly pro navazující fáze vývoje, QA a infrastruktury.
- Infrastruktura: Provedení teardown dočasných Docker kontejnerů a K8s namespaceů pro uvolnění výpočetních kapacit.
- Rozšíření testů: Implementace nového E2E scénáře do Playwright repozitáře pro pokrytí regresní chyby
BUG-912, aby se v budoucnu neopakovala.
3. Diagram procesu: Tvorba a schvalování Test Reportu
Následující diagram vizualizuje životní cyklus tvorby dokumentu od agregace systémových dat až po finální projektové rozhodnutí.
