Komplexní QA přístup CEPS HUB

Verze: 1.0 (návrh) · Stav: ke schválení Quality boardem Vlastník: Head of Quality · Schvalovatelé: CIO, Head of Quality, Head of Operations Účinnost: od schválení Quality boardem Klasifikace: Interní Vztah k existujícím dokumentům: doplňuje Test Policy (PROČ), Master testovací strategii v2.2 (JAK testujeme) a Test Plans (CO se v releasu testuje). Tento dokument definuje JAK řídíme kvalitu napříč celým SDLC — od Discovery po Post-release learning, ne jen v testovací fázi.

0. TL;DR pro management

Co měníme: QA dnes končí v gate PREPROD → PROD. Nově je QA kontinuální funkce přes celé SDLC s formálními quality gates v každé fázi (Discovery → DoR → Design → MR → Build → CI → TEST → PREPROD → PROD → Learning).

Jak: Třívrstvý operační model

1. Process layer — quality gates, DoR/DoD, RACI, evidence (rozšiřuje master strategii).
2. Tooling layer — Quality Studio jako jednotný control plane nad existujícími tooly (Playwright, pytest, Pact, k6, ZAP, Semgrep, Trivy, ReportPortal, Grafana, GitLab CI).
3. Agentic layer — lokální agentní tým (LangGraph + MCP Gateway + vLLM), který v rámci Quality Studia automatizuje analýzu, návrh testů, exekuci, triage a evidenci. Produkce zůstává read-only.

Proč: Kategorie A (kritická infrastruktura) vyžaduje shift-left k 100 % traceabilitě, shift-right k SLO/error-budget governance a regulatorní evidenci (NIS2, ZKB 264/2025, GDPR, ENTSO-E). Bez kontinuálního měření a automatizovaných gates nedosáhneme TMMi L3 (cíl 2026) a L4 (cíl 2027).

Klíčové výstupy pro každý release: QA Gate Record × 10 gates + Release Evidence Pack + Risk & Waiver Register + PIR report. Vše immutable, audit-ready do 24 hodin.

1. Filozofie a principy

1.1 Sedm závazných principů

1.2 Tři pilíře

┌───────────────────────────────────────────────────────────┐
│                    QUALITY GOVERNANCE                      │
│  (Test Policy, Master Strategy, Quality Board, KPIs)       │
└───────────────────────────────────────────────────────────┘
            │                  │                  │
            ▼                  ▼                  ▼
┌──────────────────┐  ┌──────────────────┐  ┌──────────────────┐
│   PROCESS        │  │   TOOLING        │  │   AGENTIC        │
│   layer          │  │   layer          │  │   layer          │
│                  │  │                  │  │                  │
│ • Quality Gates  │  │ • Quality Studio │  │ • LangGraph      │
│ • DoR / DoD      │  │ • FE Test Hub    │  │ • MCP Gateway    │
│ • RACI           │  │ • BE Quality Hub │  │ • vLLM (lokálně) │
│ • Evidence rules │  │ • Evidence store │  │ • 9 agent rolí   │
│ • Compliance     │  │ • Tool registry  │  │ • Audit log      │
└──────────────────┘  └──────────────────┘  └──────────────────┘

2. Architektura QA — třívrstvý operační model

2.1 Process layer — pravidla, gates, RACI

Tato vrstva je autoritativní. Definuje:

• Kategorizaci projektů (A/B/C dle Master Strategy §3).
• 10 quality gates napříč SDLC (viz §4).
• Definition of Ready, Definition of Done, Definition of Released (§5).
• Role, odpovědnosti a schvalovatele (§6).
• Compliance overlay (§9).
• Metriky a KPI (§8).

Process layer je nezávislý na konkrétních toolech — pokud Playwright nahradíme Cypressem, gates a evidence pravidla se nemění.

2.2 Tooling layer — Quality Studio jako control plane

Quality Studio není další testovací nástroj. Je to wrapper / control plane / evidence plane nad existujícím schváleným toolchainem (viz Master Strategy §6.1).

Co Quality Studio dělá:

Architektura:

                ┌────────────────────────────┐
                │      Quality Studio        │
                │   Control Plane + GUI       │
                │   (Process & Evidence)      │
                └──────────────┬──────────────┘
                               │
        ┌──────────────────────┼──────────────────────┐
        │                      │                      │
 ┌──────▼──────┐        ┌──────▼──────┐        ┌──────▼──────┐
 │ FE Test Hub │        │ BE Quality  │        │ Observability│
 │             │        │ Hub         │        │ & Compliance │
 │ Playwright  │        │ pytest      │        │              │
 │ Appium      │        │ Pact        │        │ Grafana      │
 │ axe-core    │        │ k6 / JMeter │        │ Prometheus   │
 │ Lighthouse  │        │ Schemathesis│        │ Loki / OTel  │
 │ Visual diff │        │ ZAP / Semgrep│       │ Sentry       │
 │ Maestro     │        │ Trivy / SBOM│        │ Synthetic    │
 └──────┬──────┘        └──────┬──────┘        └──────┬──────┘
        │                      │                      │
        └──────────────┬───────┴──────────────┬───────┘
                       │                      │
              ┌────────▼────────┐    ┌────────▼────────┐
              │ Evidence Store  │    │ Quality Data DB │
              │ MinIO + Allure  │    │ ClickHouse + PG │
              │ (WORM, 3-5 let) │    │ (metrics, runs) │
              └─────────────────┘    └─────────────────┘

Co Quality Studio NEDĚLÁ:

• Nevyvíjí vlastní test execution engine.
• Nenahrazuje Xray jako test management — naopak, Quality Studio Xray konzumuje a obohacuje (přidává evidence ze SAST/SCA/DAST/perf/observability).
• Není primární orchestrátor agentů — to dělá LangGraph (viz §2.3). Quality Studio je GUI pro agentní výstupy.

2.3 Agentic layer — lokální agentní tým

Plně zaintegrovaný do Quality Studia přes Agent Console. Devět rolí podle fáze SDLC (viz §3 a Agentic QA System v0.2).

Bezpečnostní hranice (hard guardrails):

3. Umístění agentů a toolů v SDLC

3.1 Mapa SDLC × Agenti × Tooly × Gate

3.2 Kdo dělá rozhodnutí (NEVĚŘ AGENTŮM SCHVALOVÁNÍ)

Agent navrhuje. Člověk rozhoduje. Quality Studio eviduje.

4. Deset quality gates — kompletní specifikace

Master strategie v2.2 definuje 7 gates v CI/CD pipeline (§9.1). Tento přístup je rozšiřuje na 10 o gates v Discovery, Refinement a Post-release fázi.

4.1 Přehled gates

PRE-DEVELOPMENT             DEVELOPMENT             POST-DEPLOY
┌─────────────────────────┐ ┌─────────────────────┐ ┌──────────────────┐
│ G1  Discovery Gate      │ │ G4  MR Gate         │ │ G9  PROD Smoke   │
│ G2  DoR Gate            │ │ G5  Build Gate      │ │ G10 Learning Gate│
│ G3  Design Gate         │ │ G6  CI Gate         │ │                  │
└─────────────────────────┘ │ G7  TEST Exit Gate  │ └──────────────────┘
                            │ G8  PREPROD Gate    │
                            └─────────────────────┘

4.2 Gate-by-gate specifikace

Každý gate má: Vlastník · Vstup · Kritéria · Evidence · Schvalovatel · Co se stane při fail.

G1 — Discovery Gate

G2 — DoR Gate (Definition of Ready)

G3 — Design Gate

G4 — MR Gate (Pre-merge)

G5 — Build Gate

G6 — CI / Dev Gate (po deploy do DEV)

G7 — TEST Exit Gate

G8 — PREPROD / Release Gate

G9 — PROD Smoke Gate

G10 — Learning Gate (Post-release)

4.3 Vizualizace toku gates

                           AGENTI                              LIDÉ
                  ┌────────────────────┐            ┌─────────────────────┐
                  │ Requirements&Risk  │            │  HoQ approval       │
   G1 Discovery   │ Agent              │ ─────────► │  Kategorie A/B/C    │
                  └────────────────────┘            └─────────────────────┘
                              │
                              ▼
                  ┌────────────────────┐            ┌─────────────────────┐
   G2 DoR         │ DoR Agent          │ ─────────► │  PO + QA Lead       │
                  └────────────────────┘            └─────────────────────┘
                              │
                              ▼
                  ┌────────────────────┐            ┌─────────────────────┐
   G3 Design      │ Test Architect     │ ─────────► │  QA Lead + ARCH     │
                  └────────────────────┘            └─────────────────────┘
                              │
                              ▼ ━━━━━━━━━━━━━━━━━━━ shift-right ━━━━━━━━━┓
                  ┌────────────────────┐            ┌─────────────────────┐
   G4 MR          │ Code QA + Test     │ ─────────► │  Dev Lead           │
                  │ Builder Agents     │            │                     │
                  └────────────────────┘            └─────────────────────┘
                              │
                              ▼
   G5 Build       (automated: SBOM, image sign, SCA)
                              │
                              ▼
                  ┌────────────────────┐
   G6 CI          │ Execution & Triage │ ──── auto ──► rollback DEV při fail
                  └────────────────────┘
                              │
                              ▼
                  ┌────────────────────┐            ┌─────────────────────┐
   G7 TEST Exit   │ Exec&Triage + Sec  │ ─────────► │  QA Lead + PM       │
                  │ &NFR Agents        │            │                     │
                  └────────────────────┘            └─────────────────────┘
                              │
                              ▼
                  ┌────────────────────┐            ┌─────────────────────┐
   G8 PREPROD/    │ Security&NFR +     │ ─────────► │  CIO + CAB + HoQ    │
      Release     │ Quality Intel      │            │  (kategorie A)      │
                  └────────────────────┘            └─────────────────────┘
                              │
                              ▼
                  ┌────────────────────┐            ┌─────────────────────┐
   G9 PROD Smoke  │ Prod Sentinel      │ ─────────► │  OPS + QA Lead      │
                  │ (read-only)        │            │                     │
                  └────────────────────┘            └─────────────────────┘
                              │
                              ▼
                  ┌────────────────────┐            ┌─────────────────────┐
   G10 Learning   │ Prod Sentinel +    │ ─────────► │  QA Lead + PM       │
                  │ Quality Intel      │            │  + Retro            │
                  └────────────────────┘            └─────────────────────┘
                              │
                              ▼
                       feedback loop ──────► do G1 / G2 / G3 dalších releasů

5. Definition of Ready / Done / Released (rozšířený DoR/DoD/DoX model)

Master strategie definuje DoR a DoD. Tento přístup přidává Definition of Released (DoX) pro shift-right governance.

5.1 DoR — checklist (Definition of Ready)

Splnění všech položek vyžadováno pro vstup story do sprintu:

• AC ve formátu Given/When/Then
• AC schválená PO + QA + Dev Lead (3 podpisy)
• UI mockup k dispozici (pokud relevantní)
• API kontrakt schválený a v Pact (pokud relevantní)
• Závislosti identifikované a vyřešené/plánované
• INVEST kritéria splněna
• Velikost ≤ 8 SP (jinak split)
• DoR score ≥ 80 % (DoR Agent)
• Riziko klasifikováno (Impact × Probability)
• NFR scope určen (pokud story dotýká kritického endpointu)

5.2 DoD — checklist (Definition of Done)

Splnění všech položek vyžadováno pro označení story jako Done:

• Kód v hlavní větvi (mergováno)
• Code review schválen min. 1 reviewerem (kategorie A: 2)
• Unit testy napsané, coverage ≥ minimum kategorie
• Integrační testy napsané (pro integrační vazby)
• Contract test (Pact) zelený pro nové/změněné API
• SAST/SCA bez Critical findings
• Funkcionalita ověřena v DEV (smoke)
• Dokumentace aktualizovaná (API spec, README, runbook)
• AC verifikovaná QA
• Žádné otevřené Critical/High defekty na story
• Xray Test Case existuje a je linknut na story (kategorie A, P0/P1)
• Připraveno k nasazení do TEST

5.3 DoX — checklist (Definition of Released) [NOVÉ]

Splnění všech položek vyžadováno pro označení release jako "úspěšně vydaný" (uzavření PIR):

• Release Evidence Pack signed a uložen ve WORM storage
• PROD smoke PASS, synthetic monitoring zelený 24h
• 0 incidentů P1/P2 v prvních 72h po deploy
• Error budget consumption < 25 % v týdnu po release
• Performance baseline aktualizovaná (pokud změna kritického endpointu)
• Escaped defects analyzovány (G10 Learning Gate)
• PIR napsán T+5 dní
• Test gap backlog tickety založeny
• Lessons learned v retro
• Annual review flag aktualizován pokud systémový nález

6. Role, RACI a schvalovací matice

6.1 Mapování rolí (rozšiřuje Master Strategy §12)

6.2 RACI per gate

Pravidla:

• Každý gate má právě jedno A (accountable).
• Pro kategorii A je A u G8 vždy CIO + CAB + HoQ.
• Žádný agent není A ani R. Agenti jsou C (consulted, jako doporučující entity).

6.3 Schvalovací matice waiver / risk acceptance

Waiver má povinnou expirační dobu (default 90 dní) a Trigger pro re-evaluaci.

7. Tooling a integrace — kompletní mapa

7.1 Tool registry (autoritativní)

Existující toolchain z Master Strategy §6.1 je zachován. Quality Studio jen přidává wrapper layer a agent layer.

7.2 Pravidla pro tooling

• Žádný nový nástroj bez ARCH + Security review (Master §6.2 zachováno).
• Adapter pattern pro každý nástroj v Quality Studio — pokud vyměníme Playwright za Cypress, mění se 1 adapter, ne 50 testů.
• Test cases žijí v Xray (Master §6.2 zachováno). Quality Studio Xray nenahrazuje.
• API kolekce verzované v Gitu (Master §6.2 zachováno).
• JUnit XML → Xray + ReportPortal přes CI/CD, vždy.
• SBOM se generuje při každém buildu, ukládá v artifact registry s retencí 3 roky.

8. Metriky, KPI a evidence

8.1 Metriky per gate (leading indicators)

8.2 Lagging indicators (Master Strategy §19.2 zachováno + rozšířeno)

8.3 Evidence retention

9. Compliance overlay — mapování gates na regulaci

Tento přístup integruje regulatorní povinnosti přímo do quality gates (Master §14 mapping).

9.1 NIS2

9.2 ZKB (zákon č. 264/2025 Sb.)

9.3 GDPR

9.4 ENTSO-E

9.5 Accessibility (zák. 99/2019)

10. Implementační roadmapa

Vychází z Agentic QA roadmapy v0.2, ale proces a tooling layer jdou napřed. Agentic layer se přidává až po stabilní baseline.

10.1 Fáze přehled

Q3 2026    Q4 2026     Q1 2027     Q2 2027     Q3 2027     Q4 2027
──┬────────┬───────────┬───────────┬───────────┬───────────┬──────────
  │        │           │           │           │           │
  │ F0     │ F1        │ F2        │ F3        │ F4        │ F5
  │ Scope  │ Process   │ Quality   │ Agentic   │ Security  │ Prod
  │ &      │ baseline  │ Studio    │ MVP       │ & NFR     │ Sentinel
  │ govern │           │ MVP       │           │ agents    │ + scale

10.2 Detailní plán

10.3 Pilotní projekt — doporučení

Doporučení: kategorie B (důležitá, ne kritická).

• Důvod: kategorie A je příliš riziková pro pilot agentic systému; kategorie C nemá dostatečnou váhu pro test gate pravidel.
• Kandidáti (z portfolia CEPS HUB): reportingový systém, plánování odstávek.

10.4 Co je MUSÍ být hotové do F1 (bez tooling/agentů)

I bez Quality Studia a agentů musí být do konce F1 hotové:

• 10 gates ručně dokumentované (Confluence šablony).
• QA Gate Record v Jira / Confluence.
• Risk register jako Jira issue type.
• Weekly QA report v1 (manuálně).
• Schvalovací matice waiver.
• DoX checklist.
• PIR template.

Tooling a agenti to zrychlí a zlevní, ale proces musí stát i bez nich.

11. Rizika přístupu a mitigace

12. Otevřené otázky pro Quality board

Před schválením je nutné rozhodnout:

1. Pilotní projekt — kategorie B, který? (Reporting / plánování odstávek / jiné?)
2. GitLab CI vs. Jenkins — Master §6.1 říká GitLab CI. Potvrzeno na 100 %?
3. Xray vs. Quality Studio test management — kde žije autoritativní test case? (Doporučení: Xray zůstává primary, Studio konzumuje.)
4. vLLM hosting — on-prem CEPS infra, nebo dedikovaný GPU cluster?
5. RAG ingest scope — co smí být v indexu? (Doporučení: Confluence Quality space + Xray + GitLab MR public — vše citlivé out.)
6. Hermes Agent — je interní CEPS Hermes, nebo open-source Hermes? Pokud interní, namapovat schopnosti.
7. Waiver expirace — default 90 dní, ale kategorie A může vyžadovat 30 dní?
8. Rozpočet — F0+F1 ~ 3 měsíce internal cost, F2+ vyžaduje rozhodnutí o investici do platformy.
9. Hosting Quality Studia — interní vývoj, vendor, nebo open-source základ (např. Sealights / OpenTestingPlatform / vlastní)?
10. Externí dodavatelé — jak je závazek z §18 Master Strategy aplikován v novém modelu? (Doporučení: smlouva odkazuje na DoR/DoD/DoX + Release Evidence Pack povinnost.)

13. Schválení

Quality Board approval:
─────────────────────────
CIO:                   _________________________  Datum: __________
Head of Quality:       _________________________  Datum: __________
Head of Operations:    _________________________  Datum: __________
QA Lead:               _________________________  Datum: __________
Head of SecOps:        _________________________  Datum: __________
Head of DevOps/SRE:    _________________________  Datum: __________

Příloha A — QA Gate Record (šablona)

QA Gate Record
═══════════════════════════════════════════════════════════════
Gate ID:              G{n}-{release}-{date}
Gate:                 G{n} — {název gate}
Release:              {release_id} / {název}
Kategorie projektu:   A | B | C
Datum:                {YYYY-MM-DD}
Vlastník (A):         {role / jméno}
Schvalovatel(é):      {role / jméno + datum + podpis}

VSTUP (Entry kritéria)
─────────────────────────────────────────────────────────────
[ ] Kritérium 1: {hodnota / důkaz}
[ ] Kritérium 2: {hodnota / důkaz}
...

VÝSTUP (Exit kritéria)
─────────────────────────────────────────────────────────────
[ ] Pass | Fail | Conditional pass
[ ] Otevřené defekty: P1=0, P2=0, P3=N (limit dle kategorie)
[ ] Risk acceptance záznamy: {RISK-* odkazy}
[ ] Evidence: {odkazy na artefakty v Evidence Store}

AGENT PŘÍSPĚVKY
─────────────────────────────────────────────────────────────
[ ] Agent: {jméno agenta} — {confidence / precision pro tento běh}
[ ] Doporučení: {pass/fail/conditional}
[ ] Tool calls: {seznam}
[ ] Reviewer (člověk): {jméno + datum}

ROZHODNUTÍ
─────────────────────────────────────────────────────────────
Status:               PASS | FAIL | CONDITIONAL PASS (s waiverem)
Důvod:                {volný text}
Další kroky:          {akce + ownership + termín}

PODPISY
─────────────────────────────────────────────────────────────
{role}: ________________________  Datum: __________
{role}: ________________________  Datum: __________

Příloha B — Release Evidence Pack (obsah)

Auto-generovaný PDF/HTML balíček před každým PROD release. Generuje Quality Studio na základě dat z Quality Data DB + Evidence Store.

Povinný obsah:

1. Cover page — release ID, kategorie, datum, schvalovatelé.
2. Executive summary (1 strana) — Go/No-Go doporučení, top 5 rizik, key KPIs.
3. Scope — co se vydává (epics, stories, bugs fixed).
4. Quality Gate summary — všech 8 pre-release gates (G1-G8), pass/fail/waiver.
5. Test execution summary — Xray + Allure data, regression suite, pass rate.
6. Defect summary — otevřené P3+, fix versions, waivers.
7. Performance evidence — baseline vs. tento release, p95/p99, throughput.
8. Security evidence — SAST/SCA/DAST findings, SBOM, pentest summary (A).
9. Compliance evidence — NIS2/ZKB/GDPR/ENTSO-E checklists per release.
10. DR / failover evidence (A, pololetně).
11. Accessibility evidence (UI release).
12. Rollback plán — kroky, autorita, validace.
13. On-call & escalation — kontakty, postupy.
14. Risk register snapshot — aktivní rizika a jejich status.
15. Agent activity log — co agenti doporučili, jak člověk rozhodl.
16. Signatures — schvalovatelé, datum.

Pravidla:

• Pack je immutable po vygenerování (WORM storage).
• SHA-256 hash je součástí Go/No-Go zápisu.
• Retence 5 let.
• Audit-ready do 24h.

Příloha C — Glossary doplnění (k Master §23)

Konec dokumentu.