Test Policy CEPS HUB

Verze: 1.0 (návrh) · Stav: ke schválení Quality boardem Vlastník: Head of Quality (HoQ) · Schvalovatelé: CIO, COO, Head of Quality, Head of Operations, Head of SecOps, Head of DevOps/SRE Účinnost: od schválení Quality boardem Klasifikace: Interní Cyklus přezkoumání: Ročně (do 31. 1.) nebo při významné změně regulace / organizace

Vztah k ostatním dokumentům:

Test Policy (tento dokument) definuje PROČ testujeme — mandát, principy, hranice, schvalovací autoritu

Master testovací strategie v2.2 definuje JAK testujeme procesně (úrovně, typy, tooling, KPI)

QA přístup CEPS HUB (master) rozšiřuje strategii o 10 quality gates napříč SDLC

Koncepce testování rozpadá strategii do metodologie (40 typů testů, techniques, automation, perf/security/a11y/crypto)

Test Plan (per release) říká CO se v konkrétním releasu testuje

0. TL;DR

Mandát: Testování v CEPS HUB je závazná funkce přes celý SDLC, ne fáze. Vlastníkem testovací politiky je Head of Quality, schvaluje Quality Board, vynucuje se gates a evidencí podle Master strategie a QA přístupu.

Pět vět které platí pro každého:

Bez schválené kategorizace projektu (A/B/C) se nezačíná žádná initiative.
Bez Test Plánu schváleného před vstupem do TEST se nedeployuje do PREPROD.
Bez QA Gate Record G7+G8 s passem se nedeployuje do PROD.
Žádný agent ani automatický systém nemá schvalovací pravomoc nad gate, waiverem ani Go-Live.
Compliance povinnosti (NIS2, ZKB 264/2025, GDPR, ENTSO-E) jsou non-negotiable a vynucené gates G7/G8/G10.

1. Účel této politiky

Tato Test Policy:

Stanovuje mandát testování v rámci CEPS HUB jako kontinuální funkce přes celý SDLC.
Definuje principy, které jsou závazné pro všechny role, projekty a externí dodavatele.
Vymezuje scope — co spadá pod tuto politiku a co ne.
Přiřazuje autoritu — kdo schvaluje testovací artefakty, výjimky, Go-Live.
Mapuje regulační rámec na konkrétní testovací povinnosti.
Definuje hranice mezi testováním, bezpečnostními audity, provozním monitoringem a auditní funkcí.

Tato politika nedefinuje konkrétní procesy ani toolchain — to dělá Master testovací strategie v2.2 a Koncepce testování.

2. Závazné principy

Sedm principů. Každá role je odpovědná za jejich dodržení v rámci své RACI působnosti (viz Master strategie §12, QA přístup §6).

2.1 Quality is everyone's responsibility

QA není „testovací oddělení". Product Owner, Business Analyst, Developer, DevOps, SecOps, SRE — všichni mají měřitelnou QA odpovědnost odvozenou z této politiky a vynucenou DoR / DoD / DoX checklisty.

V praxi: Vývojář, který commituje kód bez unit testů, porušuje politiku. Product Owner, který přijímá story bez Given/When/Then AC, porušuje politiku.

2.2 Shift-left

Kvalita začíná v Discovery, ne v testovací fázi. Testovatelnost požadavků, riziková analýza a NFR scope se řeší dříve, než se napíše první řádek kódu.

Důvod: Bug nalezený v Refinementu je 100× levnější než v PROD. Pro kategorii A znamená bug v PROD navíc potenciální NÚKIB reporting do 24 hodin.

V praxi: Discovery Gate (G1) a DoR Gate (G2) jsou závazné pro vstup do roadmapy a sprintu (viz QA přístup §4).

2.3 Shift-right

Kvalita končí v PROD, ne v Release Gate. SLO governance, synthetic monitoring, escaped-defect learning loop a Definition of Released (DoX) jsou součástí kvalitativního závazku.

V praxi: Po každém releasu T+5 dní se píše PIR (Post-Implementation Review). Escaped defects se převádí do test gap backlogu. Annual review flag se nastavuje pokud nález je systémový.

2.4 Risk-based prioritization

Risk Score = Impact × Probability. Testovací úsilí, hloubka pokrytí a počet vyžadovaných gates jsou úměrné riziku, ne velikosti komponenty ani ambici vývojáře.

V praxi: Risk Score 16+ vyžaduje schválení CIO/COO. Risk-weighted coverage je KPI pro kategorii A (cíl > 90 %).

2.5 Fail fast, fail safe

Rychlá zpětná vazba: < 10 min smoke, < 30 min CI gate, < 4h MTTR P1.

Žádný silent failure — pokud test ignoruje výsledek, je to porušení politiky. Skip / quarantine je povolený, ale jen s evidencí, expirací a ownership.

2.6 Evidence-driven

Každý gate má QA Gate Record s immutable evidence. Bez záznamu gate neexistuje. Release bez Release Evidence Pack je nevydaný, i kdyby fyzicky běžel v produkci.

V praxi: Evidence retention dle §9 (Compliance overlay). Audit-ready dostupnost do 24h pro kategorii A.

2.7 Human-in-the-loop pro kritickou infrastrukturu

Agenti, AI systémy a automatizace analyzují, navrhují, exekuují. Schvalování (merge, deploy PROD, waiver, gate override) zůstává na člověku.

Toto pravidlo je absolutní a nesmí být obejito žádnou změnou tooling layeru, agentic layeru ani externími dodavateli.

3. Scope politiky

3.1 Co spadá pod tuto politiku

Aktivity:

Funkční testování (unit, component, integration, system, E2E, UAT)
Non-functional testování (performance, security, accessibility, reliability, compatibility)
Compliance testování (NIS2, ZKB 264/2025, GDPR, ENTSO-E network codes, zák. 99/2019 accessibility)
Crypto/PKI testování (TLS, cert lifecycle, HSM, mTLS, encryption at-rest / in-transit)
DR / chaos / resilience testování
Continuous monitoring jako součást shift-right governance
Test data management a anonymizace
Test environment management

Artefakty:

Test Policy (tento dokument), Master Strategy, Test Plans, Test Cases, Test Reports
QA Gate Records, Release Evidence Pack, PIR, Risk register, Waiver register
Automation kód v Gitu (Playwright, pytest, Pact, k6, ZAP konfigurace)
Compliance evidence (audit logy, SBOM, pentest reports, DR drill protokoly)

Subjekty:

Všichni zaměstnanci CEPS pracující na CEPS HUB
Externí dodavatelé vývoje, QA, security auditu, infrastrukturních služeb
Subdodavatelé výše uvedených

3.2 Co nespadá pod tuto politiku

Bezpečnostní audity dle ZKB ISMS — vlastní politika ISMS (Head of SecOps).
Provozní monitoring PROD systémů — vlastní Operations Policy (Head of Operations).
Vnitřní audit IT — vlastní rámec interního auditu (CIO / Audit committee).
Pracovněprávní hodnocení QA pracovníků — vlastní HR procesy.
Test sandboxes ENTSO-E spravované externí stranou — koordinace, ne přímé řízení.

3.3 Vztah k jiným politikám

Politika	Vztah
ISMS Policy (ZKB)	Test Policy odkazuje na ISMS pro řízení rizik a klasifikaci dat. Pentest a SoD test jsou společné body.
Information Security Policy	Test Policy implementuje security-by-design přes G4-G8. SAST/SCA/DAST/Pentest scope je společný.
Data Protection Policy (GDPR)	Anonymizace TEST/PREPROD je společný bod; DPO sign-off povinný před G7.
Change Management Policy (CAB)	G8 Release Gate je vstupem do CAB schvalování.
Incident Management Policy	G10 Learning Gate čerpá z incident logu. Escaped defect → test gap backlog → policy update.
Vendor / Procurement Policy	Tato politika definuje QA závazky pro externí dodavatele (§7).

4. Kategorizace projektů

Kategorizace je vstupní bod každé initiative. Bez schválené kategorie se neotevírá Discovery Gate.

4.1 Kritéria kategorizace

Kritérium	Kategorie A (kritická)	Kategorie B (důležitá)	Kategorie C (standardní)
Regulatorní dopad	NIS2 essential entity (přímo), ZKB kritická IS, ENTSO-E network codes	NIS2 important entity nepřímo, GDPR vysoké riziko	Žádný přímý regulatorní dopad
Provozní dopad výpadku	Ohrožení dodávky / přenosu / dispečinku	Zhoršení reportingu, plánování, podpůrných procesů	Lokální nebo nepodstatný
Finanční dopad / hodina výpadku	> 1 mil. Kč	100k – 1 mil. Kč	< 100k Kč
Bezpečnostní klasifikace dat	Citlivé infrastrukturní + provozní	PII / interní	Veřejné / interní bez citlivosti
Audit horizon	NÚKIB, NCKB, externí audit ročně	Interní audit ročně	Žádný formální audit povinný

Pravidlo: Stačí splnit jedno kritérium A pro klasifikaci A.

4.2 Důsledky kategorizace

Aspekt	Kategorie A	Kategorie B	Kategorie C
Code review reviewers	2	1	1
Code coverage minimum	80 %	70 %	60 %
Quality gates závazné	G1-G10	G1-G10 (G3 lite)	G2, G4, G6, G7, G9
Pentest	Ročně + při významné změně	Při významné změně	Není povinný
DR drill	Pololetně	Ročně	Není povinný
UAT	Vždy	Vždy	Doporučené
Performance baseline	Povinné	Pokud relevantní	Není povinné
Accessibility (WCAG 2.1 AA)	Povinné pro public/employee UI	Povinné pro public UI	Doporučené
Crypto/PKI testy	Povinné per release + měsíčně	Per release	Per release pokud relevantní
Go-Live autorita	CIO + CAB + HoQ + PO	HoQ + PO	QA Lead
Evidence retence	5 let WORM	3 roky	1 rok
Audit response time	< 24h	< 5 prac. dní	best effort
Waiver expirace default	30 dní	90 dní	180 dní
Lead time commit→PROD cíl	< 15 dní	< 10 dní	< 5 dní
Escaped defects cíl per release	< 3	< 5	< 10

4.3 Změna kategorie

Změna kategorie initiative / systému vyžaduje:

Doporučení HoQ + Head of Operations + Head of SecOps,
Schválení Quality Boardem,
Aktualizaci Test Plánu, Risk registru a Evidence retention,
Notifikaci DPO (pokud změna dotýká PII zpracování).

Downgrade (A → B → C) je výjimečný a vždy vyžaduje formální zdůvodnění.

5. Regulační rámec

Tato politika integruje povinnosti z následujících regulací. Konkrétní mapování na gates a evidence je v QA přístupu §9 (Compliance overlay).

5.1 NIS2 (směrnice EU 2022/2555)

CEPS jako essential entity v energetickém sektoru.
Povinnosti relevantní pro testování: audit logging, incident reporting drill (NÚKIB do 24h early warning), supply chain (SBOM), continuity testing.
Vynucení: Gates G6, G7, G8, G9, G10 + ročně NÚKIB drill.

5.2 ZKB (zákon č. 264/2025 Sb. + vyhláška)

Pentest 1× ročně + při významné změně (kategorie A).
ISMS audit ročně.
Segregation of Duties test každý release (kategorie A).
Backup integrity testy měsíčně.
Crypto/TLS testy měsíčně + per release.
Vynucení: G7, G8, G10.

Anonymizace TEST/PREPROD dat — DPO sign-off povinný před každým refresh.
DSAR (Data Subject Access Request) scénáře v test plánu.
Audit přístupů k PII — retence 24 měsíců.
Right to be forgotten — test case v každém releasu dotýkajícím se subject dat.
Vynucení: G3, G6, G7, G10.

5.4 ENTSO-E network codes

TP (Transparency Platform) sandbox testy při změně rozhraní.
ECP/EDX mTLS — cert validity + rotation evidence.
CIM compliance — schema validation report.
Vynucení: G3, G7, G8.

5.5 Accessibility (zák. 99/2019 Sb.)

WCAG 2.1 AA povinné pro public a employee UI.
axe-core report + manuální checklist per release UI.
Retence evidence 3 roky.
Vynucení: G7, G8.

5.6 Další interní povinnosti

ISO 27001 (ISMS) — souběžně s ZKB.
ISO 9001 quality management — testovací evidence je vstupem.
Sectoral best practices (ENTSO-E common grid model, ENTSO-E cybersecurity reference).

6. Role, odpovědnosti a schvalovací autorita

Detailní RACI per gate je v QA přístupu §6.2. Tato politika definuje klíčové vlastníky a schvalovací autoritu.

6.1 Klíčové role

Role	Klíčová odpovědnost dle této politiky
CIO	Konečný schvalovatel Go-Live kategorie A, vlastník IT strategie, schvaluje Test Policy
COO	Schvalovatel Go-Live kategorie A z provozní strany, eskalační autorita
Head of Quality (HoQ)	Vlastník této politiky. Schvaluje strategii, gate templates, KPI, audit response
Head of Operations	Vlastník provozní stability, schvaluje G8/G9 pro kategorii A z provozní strany
Head of SecOps	Vlastník security politiky, schvaluje pentest scope, SAST/SCA/DAST thresholds
Head of DevOps / SRE	Vlastník pipeline a SLO, schvaluje G5/G9, error budget governance
DPO	Schvaluje anonymizační pipeline, audit přístupu k PII, DSAR test scénáře
QA Lead	Operativní vlastník Test Plánu, gate ownership G6/G7/G9/G10, peer review
QA Architect	Vlastník Test Strategy per epic, traceability, NFR budgety, G3
PO (Product Owner)	Vlastník DoR, AC, UAT akceptace, business sign-off
PM (Project Manager)	Schvaluje gate scheduling, eskalace, koordinace s CAB
ARCH	Schvaluje test strategy review, NFR scope, integration testability
Dev Lead	Schvaluje G4 (MR Gate), coverage minimum per kategorie
AI Engineer (AIE)	Vlastník agentního runtime, model registry, eval harness

6.2 Quality Board

Složení:

CIO (předseda)
Head of Quality
Head of Operations
Head of SecOps
Head of DevOps / SRE
DPO
1× Architect
1× rotující QA Lead z aktivního pilotu

Pravomoci:

Schvaluje Test Policy a Master strategii.
Schvaluje výjimky Risk Score 21-25 (extrémní).
Rozhoduje o downgrade / upgrade kategorie systému.
Schvaluje pilotní projekty pro QA přístup a Quality Studio.
Vyhodnocuje annual review této politiky (do 31. 1.).

Cadence: Měsíčně + ad-hoc do 24h pro Risk Score 21-25.

6.3 Schvalovací matice

Rozhodnutí	Schvalovatel
Změna této Test Policy	Quality Board (CIO + HoQ povinně)
Změna Master strategie	HoQ + CIO + Quality Board (info)
Změna gate pravidel (QA přístup)	QA Lead + SecOps + SRE peer review, info HoQ
Test Plan per release (A)	QA Lead + PO + ARCH
Test Plan per release (B, C)	QA Lead + PO
Go-Live kategorie A	CIO + CAB + HoQ + PO
Go-Live kategorie B	HoQ + PO
Go-Live kategorie C	QA Lead
Waiver Risk 1-4	QA Lead
Waiver Risk 5-9	QA Lead + PM
Waiver Risk 10-15	QA Lead + PM + HoQ
Waiver Risk 16-20	+ CIO / COO
Waiver Risk 21-25	+ Quality Board
Pentest finding Critical	Head of SecOps + HoQ (block release do remediation)
Změna agent system promptu	AIE + QA Lead peer review
Změna toolchainu (přidání/odebrání)	ARCH + SecOps review, schvaluje HoQ
Anonymizační pipeline změna	DPO + QA Lead

6.4 Eskalace

Eskalační cesta při blokujícím sporu:

Tým (QA Lead + Dev Lead + SecOps)
        │  (24h)
        ▼
HoQ + Head of příslušné domény
        │  (24h pro A, 5 dní jinak)
        ▼
CIO / COO
        │  (24h)
        ▼
Quality Board

Eskalace je povinná, pokud:

Gate fail s rizikem zpoždění releasu kategorie A o > 5 prac. dní,
Risk Score 16+ bez existujícího precedentu,
Detekce Critical security finding bez dohodnutého remediation plánu,
Spor mezi rolemi o autoritu nad gate / waiverem.

7. Externí dodavatelé

7.1 Závazek dodavatele

Každý externí dodavatel vývoje, QA nebo testování pro CEPS HUB musí smluvně přijmout:

Dodržení této Test Policy a Master strategie v rozsahu sjednaného díla.
Definition of Ready / Done / Released checklisty.
Povinnost dodat Release Evidence Pack ve struktuře definované Master strategií / QA přístupem.
Povinnost účasti v PIR (Post-Implementation Review) T+5 dní po releasu.
Compliance povinnosti (NIS2 supply chain, GDPR jako processor pokud relevantní).
Audit-ready evidence do 24h od žádosti CEPS.
Závazek odolnosti vůči substitucím (žádný subdodavatel bez schválení).

7.2 Co dodavatel NESMÍ

Nahrávat CEPS produkční data do veřejných LLM API ani cloud služeb bez schválení DPO.
Použít CEPS HUB testovací artefakty pro účely mimo CEPS HUB engagement.
Schvalovat Go-Live ani waiver kategorie A (vždy CEPS interní role).
Měnit gate pravidla, RACI, evidence retention bez schválení HoQ.

7.3 Kontrola dodavatele

Quarterly audit compliance s touto politikou (HoQ + SecOps).
Spot-check Release Evidence Pack u dodavatelských releasů.
Right to audit + right to interview u všech dodavatelů kategorie A systémů.

8. Vynucení politiky

8.1 Mechanismy vynucení

Tato politika je vynucena technicky a procesně:

Vrstva	Mechanismus
Tooling	Quality Studio gate enforcement (Gate Builder), CI/CD pipeline thresholds, automated SAST/SCA/DAST blocks
Process	DoR/DoD/DoX checklisty v Jira, QA Gate Record povinný v Confluence, RACI vynucené ve workflow
Audit	Quarterly compliance check, audit log retention, WORM storage, immutable Release Evidence Pack
Organizační	KPI dashboards (Quality Studio Reporting Center), weekly QA report, annual review této politiky

8.2 Důsledky porušení

Porušení	Důsledek
Merge bez code review / SAST	Block merge automaticky, eskalace Dev Lead
Deploy do PROD bez G8 QA Gate Record	Block deploy automaticky, eskalace HoQ + CIO
Vědomé obcházení gates	Disciplinární řízení dle interního řádu CEPS, retro audit posledních releasů
Dodavatel nedodá Evidence Pack	Block fakturace dokud nedodá; opakované porušení = výpověď smlouvy
Skip / quarantine test bez evidence	Test deaktivován v reportu jako audit finding, ticket pro QA Lead
Plaintext secret v Gitu	Hard block, rotace credentials, security incident, retro audit

8.3 Pravidlo „nepojede bez evidence"

Žádný release bez Release Evidence Pack v WORM storage neexistuje.

To znamená:

Pokud Evidence Pack chybí, release je formálně nevydaný, i kdyby fyzicky běžel v PROD.
Provozní fix bez evidence se eviduje jako incident (porušení Change Management) a vyžaduje retro evidence do 24h.
Audit dotaz „dokažte release X" musí mít odpověď do 24h pro kategorii A.

9. Hranice — co tato politika NEMÁ regulovat

Aby politika zůstala fokusovaná, explicitně nedefinuje:

Konkrétní toolchain (žije v Master strategii §6.1 a QA přístupu §7.1).
Konkrétní test design techniques (žije v Koncepci testování §3).
Konkrétní automation framework patterns (žije v Koncepci testování §6).
Konkrétní KPI hodnoty (žije v Master strategii §19 a QA přístupu §8).
Strukturu Test Plánu per release (žije v Master strategii §17 + šablona).
Implementaci Quality Studia (žije v QA přístupu §2.2 + samostatná SAD).
Architekturu agentního runtime (žije v Agentic QA System v0.2 + QA přístupu §2.3).

Důvod: Politika je strategický dokument s dlouhým cyklem změny (annual). Konkrétní toolchain se může měnit kvartálně. Oddělení udržuje politiku stabilní.

10. Životní cyklus politiky

10.1 Annual review

Datum: Do 31. 1. každého roku.
Vlastník: HoQ.
Vstupy: Quality Board KPI report, audit findings, regulatorní změny, incident learning.
Výstup: Updated Test Policy verze nebo formální potvrzení beze změny.

10.2 Ad-hoc update

Vyžadovaný při:

Změně regulace dotýkající se scope (např. nová verze NIS2 transposition zákona).
Změně organizace (změna role HoQ / CIO / COO).
Audit finding s mandate na změnu politiky.
Quality Board rozhodnutí o downgrade / upgrade scope.

10.3 Changelog (template)

Verze	Datum	Autor	Změna	Schvalovatel
1.0	YYYY-MM-DD	HoQ	Initial release	Quality Board
...

10.4 Distribuce

Primární kanál: Confluence space CEPS-QA (publish do confluence.qawave.ai pro veřejnou dostupnost).
Notifikace: n8n routing na #ceps-qa Slack/Teams při každém update.
Onboarding: Povinná část onboardingu pro role uvedené v §6.1.

11. Schválení

Test Policy CEPS HUB v1.0 — Quality Board approval
═══════════════════════════════════════════════════════════════
CIO:                          _________________________  Datum: __________
COO:                          _________________________  Datum: __________
Head of Quality:              _________________________  Datum: __________
Head of Operations:           _________________________  Datum: __________
Head of SecOps:               _________________________  Datum: __________
Head of DevOps / SRE:         _________________________  Datum: __________
DPO:                          _________________________  Datum: __________
QA Lead:                      _________________________  Datum: __________

Příloha A — Glosář

Pojem	Definice
Test Policy	Strategický dokument definující PROČ a hranice testování. Tento dokument.
Master testovací strategie	Dokument definující JAK testujeme procesně (úrovně, typy, tooling, RACI, KPI).
Test Plan	Per-release dokument definující CO se v releasu testuje.
Quality Gate	Formální rozhodovací bod v SDLC s vstup/výstup kritérii.
QA Gate Record	Immutable záznam o průchodu gate v Jira/Confluence.
Release Evidence Pack	Auto-generovaný balíček s kompletní evidencí pro release (PDF/HTML).
Definition of Ready (DoR)	Checklist pro vstup story do sprintu.
Definition of Done (DoD)	Checklist pro označení story jako Done.
Definition of Released (DoX)	Checklist pro označení release jako úspěšně vydaný (shift-right).
Kategorie projektu (A/B/C)	Klasifikace dle rizika, regulace a dopadu.
Risk Score	Impact × Probability, 1-25.
Waiver	Schválené akceptování rizika s expirací a triggerem re-evaluace.
Escaped defect	Bug zachycený v PROD, který měl být zachycen v dřívější fázi.
Shift-left / Shift-right	Posun QA aktivit směrem k Discovery / směrem do PROD.
Human-in-the-loop	Pravidlo, že agent navrhuje a člověk rozhoduje.
WORM storage	Write Once Read Many — immutable storage pro audit evidence.

Příloha B — Reference

Master testovací strategie CEPS HUB v2.2 (04-master-strategie.md)
QA přístup CEPS HUB (master) (00-QA-pristup-master.md)
Koncepce testování CEPS HUB (02-testing-koncepce.md)
Executive summary (01-executive-summary.md)
NIS2 — Směrnice EU 2022/2555
ZKB — zákon č. 264/2025 Sb., vyhláška o kybernetické bezpečnosti
GDPR — nařízení EU 2016/679
ENTSO-E network codes (Transparency Platform, ECP/EDX, CIM)
Zákon č. 99/2019 Sb. (accessibility)
ISO 27001:2022 (ISMS)
TMMi (Test Maturity Model integration) — cíl L3 do konce 2026, L4 do konce 2027

Konec Test Policy CEPS HUB v1.0.