Master testovací strategie CEPS HUB v2.2

Verze: 2.2 · Stav: ke schválení Quality boardem Vlastník: Head of Quality (HoQ) · Schvalovatelé: CIO, COO, HoQ, Head of Operations, Head of SecOps, Head of DevOps/SRE Účinnost: od schválení Quality boardem Klasifikace: Interní Cyklus přezkoumání: Ročně + ad-hoc při změně Test Policy

Vztah k ostatním dokumentům:

• Test Policy (03-test-policy.md) definuje PROČ testujeme — mandát, principy, hranice, schvalovací autorita
• Master strategie (tento dokument) definuje JAK testujeme procesně — úrovně, typy, tooling, prostředí, RACI, KPI
• QA přístup CEPS HUB (master) (00-QA-pristup-master.md) rozšiřuje tuto strategii o 10 quality gates napříč SDLC a třívrstvý operační model
• Koncepce testování (02-testing-koncepce.md) rozpadá strategii do metodologie — 40 typů testů, techniques, automation framework, perf/security/a11y/crypto
• Test Plan (per release) říká CO se v konkrétním releasu testuje (šablona v §17.4)

0. TL;DR

Co tato strategie definuje:

1. Cíle testování a měřitelné KPI (escaped defects, DRE, MTTR, lead time, coverage).
2. Kategorizace projektů A/B/C s důsledky na úsilí, gate, schvalování.
3. Testovací úrovně (Unit → Component → Integration → System → UAT → E2E → Operational).
4. Typy testů (přehled 40 typů, detail v Koncepci testování §1).
5. Toolchain registry (autoritativní seznam s rolemi adapter).
6. Prostředí (DEV / TEST / PREPROD / PROD) s pravidly přístupu, dat, refresh.
7. Test data management (synthetic, anonymizace, fixtures, retention).
8. 7-gate CI/CD model (rozšířený v QA přístupu na 10 gates).
9. Test design approach (risk-based, BDD, EP/BVA, exploratory).
10. Automation strategy (pyramida, framework patterns, flaky management).
11. RACI napříč rolemi a fázemi.
12. Defect management (severity/priority, lifecycle, RCA).
13. Reporting & evidence (Allure, ReportPortal, Grafana, Release Evidence Pack).
14. Compliance overlay (NIS2, ZKB, GDPR, ENTSO-E, accessibility).
15. Release model (sprint → release branch → CAB → Go-Live → PIR).
16. TMMi maturity model (cíl L3 v 2026, L4 v 2027).

Co tato strategie NEDEFINUJE:

• Konkrétní quality gates v Discovery / DoR / Learning — to dělá QA přístup.
• Konkrétní metodologii per typ testu (PageObject patterns, charter sessions, k6 profily) — to dělá Koncepce testování.
• PROČ testujeme a schvalovací autoritu — to dělá Test Policy.

1. Účel a scope

1.1 Účel

Master strategie je procesní rámec pro testování v CEPS HUB. Stanovuje:

• Jak plánujeme testovací úsilí (kategorizace, úrovně, typy).
• Jak organizujeme toolchain (registry, adapter pattern, governance).
• Jak řídíme prostředí a data.
• Jak měříme úspěch (KPI, evidence).
• Jak vynucujeme kvalitu (gates v CI/CD).
• Jak rozšiřujeme model do agentic / Quality Studio (vazba na QA přístup).

1.2 Scope

Tato strategie pokrývá veškerý vývoj a údržbu CEPS HUB systémů — interní vývoj, externí dodávky, akvizice / outsourcing. Platí pro:

• Aplikační vývoj (BE/FE, mobile, integrace, BPM, reporting).
• Konfigurační změny kritické infrastruktury.
• Integrační projekty (ENTSO-E, externí stakeholders, interní systémy).
• Migrace dat a platformové upgrade.
• AI/ML komponenty (model evaluace pre-deployment).

1.3 Co tato strategie pokrývá nepřímo

• Bezpečnostní audity — koordinace, ne přímé řízení (ISMS / SecOps vlastní procesy).
• Provozní monitoring — vstupní data pro shift-right governance.
• Internal audit — strategie poskytuje evidence, audit ji konzumuje.

1.4 Závaznost

Strategie je závazná pro všechny CEPS zaměstnance a externí dodavatele zapojené do CEPS HUB. Výjimky vyžadují waiver dle Test Policy §6.3 a Master strategie §20.

2. Cíle testování

2.1 Strategické cíle 2026-2027

2.2 Operativní cíle

• Shift-left: 100 % story v kategorii A má DoR score ≥ 80 % před vstupem do sprintu.
• Shift-right: 100 % releasů má PIR do T+5 dní.
• Reliability: MTTR P1 < 4h, MTTR P2 < 24h.
• Predictability: Change Failure Rate < 10 %.
• Velocity bez kompromisu: Deployment frequency ≥ 1×/týden (kategorie B/C), ≥ 1×/Q (A).

2.3 Co cíle nemají dělat

• Nesmí motivovat k podvádění — gaming KPI (např. reklasifikace bugu na "feature request") je porušení politiky.
• Nesmí jít proti bezpečnosti — rychlost není legitimní důvod pro skip security testu.
• Nesmí ignorovat kontext — KPI cíle se liší per kategorie. Kategorie C nemá smysl tlačit na cíle kategorie A.

3. Kategorizace projektů (A/B/C)

Kategorizace je převzata z Test Policy §4, kde je autoritativní definice. Master strategie definuje procesní důsledky.

3.1 Procesní matrix

3.2 Smíšené projekty

Pokud projekt obsahuje moduly různých kategorií, nejvyšší kategorie vyhrává pro:

• Pipeline gates (SAST, SCA, signed artifact).
• Evidence retention.
• Go-Live autoritu.

Nižší kategorie modulů může mít light approach pro vlastní testování (méně reviewerů, nižší coverage), ale release jako celek se chová podle nejvyšší kategorie.

4. Testovací úrovně a typy

4.1 Úrovně testování

                                                ┌─────────────────┐
                                          ┌────►│  Operational    │  PROD smoke, synthetic
                                          │     └─────────────────┘
                              ┌─────────────────┐
                          ┌──►│  UAT / Business │  PREPROD, business akceptace
                          │   └─────────────────┘
                 ┌─────────────────┐
             ┌──►│  System / E2E   │  TEST/PREPROD, kritické flows
             │   └─────────────────┘
   ┌─────────────────┐
  ┌►│  Integration    │  CI, service-to-service
  │ └─────────────────┘
┌─────────────────┐
│  Component      │  CI, izolovaná komponenta s mocky
└─────────────────┘
┌─────────────────┐
│  Unit           │  Build, izolovaná logika
└─────────────────┘

4.2 Typy testů — přehled

Plná taxonomie 40 typů je v Koncepci testování §1. Master strategie eviduje rodiny:

4.3 Pyramida & vážení (cílový poměr)

                  ╱──────╲          Exploratory + UAT (5-8 %)
                 ╱  Manual ╲
                ╱───────────╲
               ╱   E2E auto  ╲       E2E (8-12 %)
              ╱  (Playwright) ╲
             ╱─────────────────╲
            ╱  Integration + API ╲   Integration + Contract (20-25 %)
           ╱  (Pact, Schemathesis)╲
          ╱───────────────────────╲
         ╱  Component + WireMock   ╲ Component (15-20 %)
        ╱                           ╲
       ╱─────────────────────────────╲
      ╱       Unit tests               ╲ Unit (40-55 %)
     ╱                                  ╲
    ╱───────────────────────────────────╲

Transverzální vrstvy (běží paralelně, mimo pyramidu):

• Performance (PREPROD, periodicky)
• Security (CI + PREPROD + ročně pentest)
• Accessibility (per UI release)
• Crypto/PKI (per release A + měsíčně)
• DR / Resilience (kvartálně + pololetně)
• Synthetic monitoring (PROD continuous)

4.4 Risk-based prioritization

Risk Score = Impact × Probability    (každé 1-5, score 1-25)

Impact:
  1 = lokální dopad, žádná regulace
  2 = team-level impact, snadné workaround
  3 = service-level impact, business workaround
  4 = systémový dopad, NIS2 important entity zóna
  5 = kritický dopad, NIS2 essential entity, NÚKIB 24h reporting

Probability:
  1 = velmi vzácně (raz/rok)
  2 = občas (raz/Q)
  3 = pravidelně (raz/měs)
  4 = často (raz/týden)
  5 = velmi často (denně+)

Důsledky pro testovací úsilí:

5. Toolchain registry

5.1 Autoritativní seznam (Tool Registry)

Tato sekce je autoritativní zdroj toolchainu. Quality Studio (viz QA přístup §2.2 a §7.1) ji čte a obohacuje o adapter status, verze, health.

5.2 Pravidla pro tooling

• Žádný nový nástroj bez ARCH + SecOps review. Schvaluje HoQ.
• Adapter pattern — výměna toolu (např. Playwright → Cypress) musí být lokalizovaná do 1 adapteru v Quality Studio, ne do 50 testů.
• Test cases žijí v Xray. Quality Studio Xray konzumuje, neobsahuje.
• API kolekce verzované v Gitu (vedle aplikačního kódu).
• JUnit XML → Xray + ReportPortal přes CI/CD vždy.
• SBOM se generuje při každém buildu a ukládá v artifact registry s retencí 3 roky.
• Tools registry update — quarterly review HoQ + SecOps + DevOps.

5.3 Banned / deprecated

• Žádné public LLM API (OpenAI/Anthropic/Google) pro produkční / interní citlivá data bez explicitního schválení DPO + HoQ + SecOps. Default = vLLM lokálně.
• Žádný plaintext secret v Gitu / CI variables. Vault + scoped tokens jen.
• Žádné latest ani ^x.y.z semver tagy v produkční konfiguraci. Pinned versions only.

6. Prostředí

6.1 Environment model

6.2 Pravidla pro prostředí

• Konfigurace odpovídá produkci. PREPROD musí mít identický stack (verze, count, HA), data se liší jen anonymizací.
• Anonymizace TEST/PREPROD je povinná před každým refresh. DPO sign-off + Git tag scriptu, retence 3 roky.
• Žádný PROD secret v non-PROD. Cert chain je vlastní per prostředí; HSM keys nikdy migrovány do non-PROD.
• Refresh DEV daily, TEST weekly, PREPROD per release — automatizovaný pipeline, audit log refresh akce.
• Isolation: Sítě prostředí izolované; integrace s externími systémy přes mock (TEST) nebo sandbox (PREPROD pro ENTSO-E).
• PROD je read-only pro QA. Agenti i lidé. Žádný write přístup z testovacích nástrojů.

6.3 Externí sandboxes

7. Test data management

7.1 Strategie dat

7.2 Anonymizace

Detail metodologie v Koncepci testování §5. Master strategie definuje:

• Anonymizační pipeline je verzovaná v Gitu, schvaluje DPO + QA Lead.
• Sign-off před každým refresh povinný (DPO).
• Retence sign-offs 3 roky.
• Periodický audit anonymizace (kvartálně, externí pokud kategorie A).

7.3 Lifecycle

Discovery
  └─► fixtures + synthetic plán (Test Strategy per epic, G3)
        │
        ▼
Refinement (DoR)
  └─► test data potřeby v AC
        │
        ▼
Development
  └─► fixtures v Gitu, synthetic generation
        │
        ▼
TEST refresh
  └─► anonymized PROD subset (DPO sign-off, Git tag)
        │
        ▼
PREPROD refresh per release
  └─► anonymized PROD full + UAT data set
        │
        ▼
Post-release
  └─► retention dle compliance (3-5 let WORM)

8. CI/CD pipeline a 7 gates

Master strategie v2.2 definuje 7 gates v CI/CD pipeline. QA přístup je rozšiřuje na 10 gates přidáním Discovery, DoR a Learning gates.

8.1 7 gates v CI/CD (master baseline)

┌──────────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ MR (Pre-merge│───►│ Build    │───►│ CI/DEV   │───►│ TEST Exit│
│ Gate 4)      │    │ Gate 5   │    │ Gate 6   │    │ Gate 7   │
└──────────────┘    └──────────┘    └──────────┘    └──────────┘
                                                         │
                                                         ▼
                                                  ┌──────────────┐
                                                  │ PREPROD /    │
                                                  │ Release Gate │
                                                  │ Gate 8       │
                                                  └──────┬───────┘
                                                         │
                                                         ▼
                                                  ┌──────────────┐
                                                  │ PROD Smoke   │
                                                  │ Gate 9       │
                                                  └──────────────┘
                                                         │
                                                         ▼
                                                  ┌──────────────┐
                                                  │ PROD running │
                                                  │ Gate 10 (lrn)│
                                                  └──────────────┘

8.2 Gate specifikace

Detailní specifikace per gate (entry, criteria, evidence, schvalovatel, fail action) je v QA přístupu §4.2. Zde shrnutí:

8.3 CI/CD pravidla

• Žádný manual override pipeline gate bez waiveru s explicit autorem + důvodem + expirací.
• Žádný skip/continue-on-failure v produkční pipeline. Skip jen v explicit testovací větvi s commentem a expirací.
• Pipeline as code. YAML v Gitu, code-reviewed jako aplikační kód.
• Pipeline duration < 30 min pro G4+G5+G6 (combined) pro kategorii B/C. Kategorie A může jít 60 min při zařazení perf.
• Pipeline auditability. Každý běh má SHA-256 hash bundle (kód, deps, env, artifact) zaznamenaný v Quality Studio.

9. Test design approach

Detail technik v Koncepci testování §3. Master strategie definuje závazný approach:

9.1 Závazné techniques

9.2 BDD jako sdílený jazyk

• AC v Given/When/Then povinné pro každou story (DoR).
• Test cases odvozené z AC, traceabilita Xray.
• Domain language sdílený mezi PO, QA, DEV — Glossary v Confluence per produkt.

9.3 Traceability

Requirement (Jira Epic / Story)
    │
    ▼
Risk (Jira Risk issue type)
    │
    ▼
Test Case (Xray)
    │
    ▼
Test Execution (Xray + Allure)
    │
    ▼
Defect (Jira Bug)
    │
    ▼
Fix + Retest (Jira + Xray re-execution)
    │
    ▼
Evidence (Quality Studio Evidence Browser)

Pravidlo: Pro kategorii A je traceability vyžadována 100 % pro kritické UC. Pro B doporučená. Pro C volitelná.

10. Automation strategy

10.1 Cíle automatizace

10.2 Framework pravidla

Detail patterns v Koncepci testování §6. Master strategie definuje:

• Page Object Pattern pro Playwright (FE).
• Repository Pattern pro test data access (BE).
• Fixtures v dedicated module, žádný duplicate setup.
• Test isolation — žádný shared state mezi testy.
• Parallel-safe — testy musí běžet paralelně bez konfliktu.
• Deterministic — žádný sleep, jen explicit waits / polling s timeout.
• Self-cleanup — test, který vytváří entity, je musí uklidit (nebo používat ephemeral fixture).
• Lokalizace v jediném resource souboru, ne hardcoded v test kódu.

10.3 Flaky management

• Detekce: Quality Studio Quality Intelligence Agent + manual flag.
• Quarantine: Po 3× flaky run za 7 dní → quarantine s expirací 5 prac. dní.
• Fix mandatory: Quarantine > 5 dní = block release pro test owner.
• Audit: Quarantine list je veřejně viditelný v Quality Studio Dashboard.

11. Specializované testovací domény

Detail metodologie v Koncepci testování §7-§11. Master strategie definuje scope a vlastníky:

11.1 Performance

• Profily: Load (cílová zátěž), Stress (bod zlomu), Soak (24h+ stabilita), Spike (rychlý nárůst), Capacity (sizing).
• Vlastník: QA + SRE.
• Nástroj: k6 primární, JMeter pro legacy.
• Frekvence: Per release A; kvartálně Stress + Capacity; per release B pokud relevantní.
• Baseline storage: Confluence + Git, retence trvale (regression analysis).

11.2 Security

• Layers: SAST (per commit), SCA (per build), Container (per build), DAST (per release), Pentest (ročně / change A).
• Vlastník: SecOps; DEV implementuje fix.
• Threat modeling: OWASP Threat Dragon / IriusRisk, mandatory per epic kategorie A.
• CVE response SLA: Critical → fix do 48h, High → 7 dní, Medium → 30 dní.

11.3 Accessibility

• Standard: WCAG 2.1 AA.
• Vlastník: QA + UX.
• Nástroj: axe-core + Lighthouse + manual.
• Frekvence: Per UI release.
• Compliance: zák. 99/2019 Sb. pro public/employee UI.

11.4 Crypto / PKI

• Scope: TLS verze a ciphers, cert lifecycle (OCSP/CRL), mTLS, HSM key rotation, encryption at-rest a in-transit.
• Vlastník: DevSecOps + SecOps.
• Nástroj: testssl.sh + custom scripts + HSM management tooling.
• Frekvence: Per release A + měsíčně periodic scan.

11.5 DR / Resilience

• Scope: Backup restore, failover, full DR drill, chaos.
• Vlastník: OPS + SRE + QA.
• Frekvence:
  • Backup restore: měsíčně.
  • Failover komponentový: kvartálně.
  • Full DR drill: pololetně.
  • Chaos engineering: ročně + při změně HA.
• RTO / RPO: Per system v Risk register; measurement při každém drill.

11.6 AI/ML eval

• Scope: Model regression, drift detection, eval harness.
• Vlastník: AIE + QA.
• Frekvence: Per model deploy + týdně drift check pro produkční modely.
• Out of scope tohoto dokumentu: AI governance policy (samostatný dokument).

12. Role a RACI

12.1 Rozšířená RACI tabulka

Detail RACI per quality gate je v QA přístupu §6.2.

12.2 Konflikt v RACI

Pokud dvě role nárokují A (accountable) pro stejnou aktivitu, rozhoduje HoQ. Pokud HoQ je strana sporu, Quality Board.

13. Defect management

13.1 Severity vs. Priority

Severity = technický dopad chyby
Priority = business naléhavost opravy

Severity Critical: ztráta dat / bezpečnost / total down
Severity High:     hlavní funkčnost narušena, workaround neexistuje
Severity Medium:   funkčnost narušena, workaround existuje
Severity Low:      kosmetické, malý dopad
Severity Trivial:  typo, drobnost

Priority P0: blocker pro release / production incident
Priority P1: must-fix v aktuálním sprintu
Priority P2: fix v dalším sprintu
Priority P3: backlog

13.2 Defect lifecycle

   ┌──────────────┐
   │ New          │  vytvořen QA / agent / customer
   └──────┬───────┘
          │  triage QA Lead / PM
          ▼
   ┌──────────────┐
   │ Triaged      │  severity + priority + assignee
   └──────┬───────┘
          │
          ▼
   ┌──────────────┐         ┌──────────────┐
   │ Open         │────────►│ Won't Fix    │  s odůvodněním + waiver
   └──────┬───────┘         └──────────────┘
          │
          ▼
   ┌──────────────┐
   │ In Progress  │
   └──────┬───────┘
          │
          ▼
   ┌──────────────┐
   │ Code Review  │
   └──────┬───────┘
          │
          ▼
   ┌──────────────┐
   │ Fixed        │  merged
   └──────┬───────┘
          │  retest QA
          ▼
   ┌──────────────┐         ┌──────────────┐
   │ Retest PASS  │────────►│ Reopen       │  zpět do Open
   └──────┬───────┘         └──────────────┘
          │
          ▼
   ┌──────────────┐
   │ Closed       │  PROD validation
   └──────────────┘

13.3 RCA (Root Cause Analysis)

• Vyžadováno pro každý P0/P1 defekt.
• Volitelné pro P2 (ad-hoc dle vzoru).
• 5 Whys + Fishbone + technical write-up.
• Output: Action items v test gap backlogu (G10 Learning Gate).

13.4 Gate kritéria per kategorie

14. Reporting a evidence

14.1 Reporting layers

┌────────────────────────────────────────────────────────┐
│ Strategic — Quality Board monthly                       │
│  KPI dashboard (TMMi, escaped defects, DRE, lead time)  │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Tactical — Weekly QA Report                             │
│  Sprint progress, blocked stories, gate fails, risks    │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Operational — daily standup + Quality Studio dashboard │
│  CI flake rate, regression status, defect inflow        │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Release — Release Evidence Pack + Go-Live record        │
│  All gates, all evidence, SHA-256, WORM                 │
└────────────────────────────────────────────────────────┘

14.2 Release Evidence Pack

Plný obsah v QA přístupu Příloha B. Master strategie definuje:

• Auto-generovaný Quality Studiem.
• Immutable (WORM, retention 5 let A, 3 roky B, 1 rok C).
• SHA-256 hash v Go-Live zápisu.
• Audit-ready do 24h od žádosti.

14.3 Evidence retention

15. Compliance overlay

Kompletní mapování v QA přístupu §9. Master strategie definuje scope:

Princip: Compliance je vynuceno gates (G7/G8/G10), ne jen mapováno v dokumentaci.

16. Release model

16.1 Release cadence

16.2 Release flow

Sprint commit
   │
   ▼
G4-G6 (Pre-merge → Build → CI)
   │
   ▼
Deploy do TEST (auto)
   │
   ▼
G7 TEST Exit Gate (QA Lead approval)
   │
   ▼
Deploy do PREPROD
   │
   ▼
UAT + Perf + Security + Crypto + DR + WCAG
   │
   ▼
G8 PREPROD/Release Gate
   │
   │  kategorie A: CIO + CAB + HoQ + PO
   │  kategorie B: HoQ + PO
   │  kategorie C: QA Lead
   │
   ▼
Deploy do PROD
   │
   ▼
G9 PROD Smoke Gate (OPS + QA Lead)
   │
   ▼
PROD running
   │
   ▼ T+5 dní
G10 Learning Gate (PIR, retro, test gap)

16.3 Hotfix flow

• Hotfix branch z release tagu.
• Lite gate set: G4 (MR) + G5 (Build) + G7 lite + G8 lite.
• Required: SAST/SCA, smoke, perf delta (musí být ≤ baseline).
• Schvaluje: CIO + HoQ pro kategorii A; HoQ pro B; QA Lead pro C.
• PIR povinný (i pro hotfix).

16.4 Rollback

• Rollback plán je součástí každého release pack (povinné).
• Automatický rollback při G9 fail (do 5 min od deploy).
• Manuální rollback s evidencí + decision log.
• Rollback test v PREPROD jako součást G8 (kategorie A).

17. Test Plan per release

17.1 Účel Test Plánu

Test Plan per release říká CO se v tomto konkrétním releasu testuje, na rozdíl od:

• Test Policy = PROČ.
• Master strategie = JAK obecně.
• Koncepce testování = JAK konkrétní metodikou.
• Test Plan = CO v tomto releasu.

17.2 Vlastník

QA Lead (per release).

17.3 Schvalovatelé

• Kategorie A: QA Lead + PO + ARCH + HoQ (info).
• Kategorie B: QA Lead + PO.
• Kategorie C: QA Lead.

17.4 Šablona Test Plánu

TEST PLAN — Release {ID} — {název} — {datum}
═══════════════════════════════════════════════════════════════

1. METADATA
   - Release ID:
   - Kategorie projektu: A | B | C
   - Datum cíl Go-Live:
   - Test Plan vlastník:
   - Schvalovatelé:

2. SCOPE
   - In scope: {epics, stories, integrace}
   - Out of scope: {explicit boundaries}
   - Dependencies: {externí systémy, sandboxes, partneri}

3. APPROACH
   - Test levels: {Unit/Component/Integration/System/UAT/E2E/Operational}
   - Test types: {z 40 typů — co se použije}
   - Risk-based prioritization: {top 5 rizik per epic + RS}

4. ENVIRONMENT & DATA
   - TEST refresh datum:
   - PREPROD refresh datum:
   - Test data strategy: {synthetic / anonymized / fixtures}
   - DPO sign-off: {odkaz}

5. ENTRY/EXIT KRITÉRIA
   - Entry to G7: {konkrétní hodnoty}
   - Exit from G7 (PREPROD entry): {konkrétní hodnoty}
   - Exit from G8 (PROD entry): {konkrétní hodnoty}

6. SCHEDULE
   - Test design: {datum}
   - Test execution: {datum-datum}
   - UAT: {datum-datum}
   - Performance window: {datum}
   - Security/DAST window: {datum}
   - Crypto/PKI window: {datum}
   - DR drill (pokud release-time): {datum}

7. RESOURCES
   - QA Lead:
   - QA Engineers:
   - QA Automation:
   - SecOps:
   - SRE:
   - PO:
   - External vendors:

8. RISKS
   - Risk 1: {popis, RS, mitigace, owner}
   - Risk 2: ...

9. METRICS & REPORTING
   - Daily report: Quality Studio dashboard link
   - Weekly report: Confluence link
   - Defect SLA: P0 fix 24h, P1 fix 3 dny, P2 fix per sprint
   - Pass rate targets: regression ≥ 98 %, smoke 100 %

10. APPROVALS
    QA Lead:    ________________ Datum: _________
    PO:         ________________ Datum: _________
    ARCH (A):   ________________ Datum: _________

18. Externí dodavatelé

18.1 Smluvní závazek

Externí dodavatelé musí přijmout:

• Test Policy + tato Master strategie v rozsahu díla.
• Definition of Ready / Done / Released checklisty.
• Release Evidence Pack dodavací povinnost.
• PIR účast T+5 dní.
• Compliance (NIS2 supply chain, GDPR jako processor).
• Audit-ready evidence do 24h.

18.2 Acceptance testy CEPS

CEPS provádí vlastní acceptance testy dodavatelského release:

• Kategorie A: Full G7 + G8 v CEPS prostředí.
• Kategorie B: G7 + lite G8.
• Kategorie C: Smoke + UAT key flows.

18.3 Dodavatelská quality clauses

19. KPI a metriky

19.1 Leading indicators (per gate)

Plný seznam v QA přístupu §8.1. Master strategie definuje klíčové:

19.2 Lagging indicators

19.3 Audit

• Quarterly KPI review Quality Boardem.
• Annual TMMi assessment externí.
• Compliance audit dle regulace (NIS2 externí, ZKB ISMS externí).

20. Risk management

20.1 Risk register

• Forma: Jira Risk issue type.
• Pole: Description, Impact (1-5), Probability (1-5), Risk Score (auto), Owner, Mitigation, Triggers, Review date.
• Update cadence: Per release minimum + ad-hoc.

20.2 Waiver workflow

Risk identifikováno
   │
   ▼
Risk Score calculated (Impact × Probability)
   │
   ▼
Mitigation hledána
   │
   ├─► Mitigation existuje → tracked, no waiver needed
   │
   └─► Mitigation neexistuje / neproveditelná
       │
       ▼
   Waiver request s expirací + trigger pro re-evaluaci
       │
       ▼
   Schvaluje (dle §6.3 Test Policy):
       RS 1-4:    QA Lead
       RS 5-9:    QA Lead + PM
       RS 10-15:  QA Lead + PM + HoQ
       RS 16-20:  + CIO/COO
       RS 21-25:  + Quality Board
       │
       ▼
   Waiver evidence v Quality Studio Risk & Waiver Center
       │
       ▼
   Expirace dohlížena n8n notifikací

20.3 Trigger pro re-evaluaci

Mandatory triggers (i před expirací):

• Změna v dotčeném systému / kódu.
• Související incident v PROD.
• Změna regulace.
• Změna kategorie projektu.

21. Maturity model — TMMi

21.1 Cíle

21.2 Roadmap

Detail v QA přístupu §10. Master strategie definuje fáze:

F0  Scope & governance      2-3 týdny
F1  Process baseline         4-6 týdnů
F2  Quality Studio MVP       6-8 týdnů
F3  Agentic MVP              6-8 týdnů
F4  Security & NFR agents    6-8 týdnů
F5  Prod Sentinel + scale    4-6 týdnů

Celkem F0-F5: 6-8 měsíců. Měřitelná hodnota od F1.

22. Životní cyklus strategie

22.1 Annual review

• Datum: Do 31. 1. každého roku.
• Vlastník: HoQ.
• Vstupy: Quality Board KPI, TMMi assessment, incident learning, regulatorní změny.
• Výstup: Updated Master strategie verze nebo potvrzení beze změny.

22.2 Ad-hoc update

Vyžadovaný při:

• Změně Test Policy (master strategie aligní).
• Změně toolchainu významného rozsahu.
• Změně organizace / role.
• Quality Board rozhodnutí.

22.3 Changelog

23. Schválení

Master testovací strategie CEPS HUB v2.2 — 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ář (sdílený s Test Policy)

Viz Test Policy Příloha A (sdílený glosář pro celý rámec) a QA přístup Příloha C (rozšíření o agentic terminologii).

Příloha B — Reference

• Test Policy CEPS HUB v1.0 (03-test-policy.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)
• TMMi Foundation reference (https://www.tmmi.org)
• ISO/IEC/IEEE 29119 (Software Testing)
• ISTQB Foundation + Advanced syllabi
• OWASP ASVS, OWASP Testing Guide
• WCAG 2.1 AA standard
• ENTSO-E Common Information Model, Transparency Platform spec, ECP/EDX

Konec Master testovací strategie CEPS HUB v2.2.