Účel

Tento dokument představuje závaznou metodiku a technický standard pro zajišťování kvality (QA) v rámci celého ekosystému SISTA. Pravidla jsou postavena na principu „Quality by Design“ a jsou nedílnou součástí vývojového cyklu všech dodavatelů i interních týmů.

Procesní model toku testování

Následující schéma znázorňuje tok změny od vývoje až po produkci, povinné kontrolní brány (Quality Gates QG1–QG6), prostředí a odpovědné role. Selhání kterékoliv brány blokuje postup do další fáze.

Procesní model toku testování
Figure 1. Procesní model toku testování

1. Strategické cíle

Cílem testování v projektu SISTA je:

  • Minimalizace manuálních zásahů prostřednictvím hloubkové automatizace napříč systémovými vrstvami (Unit, API, E2E).

  • Zajištění stoprocentní regresní stability při nasazování nových verzí.

  • Zavedení centralizovaného dohledu nad kvalitou kódu prostřednictvím nástroje SonarQube v CI/CD.

  • Maximalizace efektivity a konzistence testování napříč všemi dodavatelskými týmy.

  • Test-Driven Development (TDD) je preferovanou metodou vývoje.

2. Role a odpovědnosti

2.1. Obecné

  1. Odpovědnost DEV týmu:

    • Každý vývojový tým je plně zodpovědný za kvalitu svého kódu. To zahrnuje psaní automatizovaných testů souběžně s vývojem (unit testy, integrační testy, API testy), dodávání reportů pokrytí (JaCoCo, Istanbul/nyc, Coverage.py) integrovaných do CI/CD pipeline, udržování testů aktuálních při refaktoringu, provádění komplexních manuálních testů před předáním k akceptaci a opravu selhávajících testů ve svých sadách do 48 hodin.

  2. Odpovědnost Interního testovacího týmu (ITT):

    • Interní testovací tým SISTA odpovídá za revizi a kontrolu správnosti manuálních a akceptačních testovacích scénářů, správu a údržbu centrální sady Smoke a E2E testů (Playwright), provádění zátěžového testování a výkonnostního reportingu, metodickou podporu garantů při přípravě akceptačních scénářů, reporting testovacích metrik a KPI (viz sekce 14) a správu centrálního nástroje pro testovací scénáře.

  3. Odpovědnost Garanta TRSu:

    • Vytváří komplexní akceptační scénáře dle byznysových požadavků. Vydává finální akceptační rozhodnutí (PŘIJATO / PODMÍNĚNĚ PŘIJATO / VRÁCENO K PŘEPRACOVÁNÍ). Spolupracuje s ITT na přípravě Smoke a E2E testů. Udržuje akceptační scénáře v čase a ověřuje změny realizované přes Freelo. Odpovídá za go/no-go rozhodnutí před nasazením na produkci na základě výsledků všech Quality Gates.

  4. Odpovědnost Ops týmu:

    • Zajišťuje stabilitu testovacích prostředí a spolehlivost CI/CD linek včetně notifikačních kanálů. Monitoruje testovací prostředí (dostupnost, výkon), spravuje testovací credentials a secrets (HashiCorp Vault nebo ekvivalent) a zajišťuje obnovu a anonymizaci dat na testovacích prostředích.

2.2. RACI matice

Rozdělení odpovědností pro každý typ testu:

Typ testu Dev tým ITT Garant Ops

Unit testy

R

A

–

–

Integrační testy

R

A

–

I

API testy

R

A

C

–

Manuální testy

R

C

A

–

Smoke testy

C

R

A

I

E2E testy

C

R

A

I

Akceptační testy

C

R

A

–

Zátěžové testy

C

R

A

C

Bezpečnostní testy

R

C

I

A
Note
Poznámky

  • R = Responsible (vykonává úkol)

  • A = Accountable (nese konečnou odpovědnost a schvaluje, pro úkol právě jedna role)

  • C = Consulted (poskytuje vstupy)

  • I = Informed (je informován o výsledku) více viz Matice odpovědností

  1. Odpovědnost R/A:

    • Accountable (A) je oddělen od Responsible (R) – tým, který test vykonává, není zároveň tím, kdo nese konečnou odpovědnost a schvaluje. Accountable nese podle typu testu ITT (unit, integrační, API), garant (manuální, smoke, E2E, akceptační, zátěžové) nebo Ops (bezpečnostní); viz matice výše.

  2. Pro přechod mezi R a A platí specifická pravidla:

    • Responsible předává Accountable výstupy testů (reporty pokrytí, výsledky běhů, dokumentaci); Accountable potvrzuje splnění prostřednictvím objektivních kontrolních bran (Quality Gates), namátkové kontroly a revize a nese konečnou odpovědnost za uvolnění – nikoli opětovným přezkoušením. Konkrétní podoba předání R→A pro jednotlivé typy testů bude upřesněna v provozní směrnici testování.

3. Detailní matice testovacích aktivit

Typ testu Nástroje Účel Prostředí Frekvence Výstup

Unit testy

JUnit, Jest, pytest

Pokrytí logiky komponent (min. 80 %).

Lokálně / CI

Každý commit/MR

JUnit XML + coverage

Integrační

Testcontainers, WireMock

Interakce mezi službami a ext. systémy.

CI Build

Na vyžádání

JUnit XML

API testy

Postman/Newman, REST Assured

Validace API (pozit. i negat. scénáře).

CI / TEST

Každý commit/MR

JUnit XML + OpenAPI

Smoke testy

Playwright

Základní funkčnost po nasazení.

TEST/STAGING/PROD

Kontinuálně

HTML + screenshot (video)

E2E testy

Playwright

Kompletní uživatelské flow.

STAGING

1× denně

HTML + video/screenshot

Manuální

Dle šablony

UX, edge cases, vizuální kontrola.

TEST/STAGING

Před akceptací

Testovací protokol

Akceptační

Dle šablony

Soulad s byznys požadavky.

STAGING

Před PROD

Akceptační protokol

Zátěžové

k6, JMeter

Chování při špičkách.

STAGING

Před velkým releasem

Zátěžová zpráva

Bezpečnostní

SonarQube, OWASP ZAP, Trivy

Zranitelnosti v kódu a závislostech.

CI / STAGING

Build (SAST), release (DAST)

Security report

4. Automatizace a kontrola kvality

4.1. Unit testy

Unit testy jsou integrální součástí vývojového cyklu každého modulu.

  • CI/CD pipeline spouští testy automaticky s každým buildem.

  • Reporty o pokrytí jsou generovány (JaCoCo, Istanbul/nyc, Coverage.py) a předávány do SonarQube.

  • SonarQube aplikuje Quality Gate:

    • Pokrytí kódu ≥ 80 % (byznys logika; exkluze: generovaný kód, DTO, konfigurace).

    • Žádné blocker nebo critical issues.

    • Code smells max. 5 na 1000 řádků.

  • Exkluze z měření pokrytí musí být explicitně definovány v SonarQube konfiguraci a schváleny ITT.

4.2. API testy

Všichni dodavatelé jsou povinni integrovat automatizované API testy do CI/CD.

  • Výstupní formát: JUnit XML (povinný pro integraci s CI/CD).

  • Testovací scénáře pokrývají:

    • Korektní i nekorektní vstupy (pozitivní i negativní testy).

    • Validaci HTTP status kódů.

    • Validaci struktury odpovědí dle OpenAPI/Swagger.

    • Ověření zpětné kompatibility při změnách API.

  1. Možnosti implementace:

    • Varianta A – Decentralizovaná: Tým si zvolí framework (Postman CLI, REST Assured, Karate). CI/CD zpracuje JUnit XML výstupy.

    • Varianta B – Centrální šablona: ITT poskytne šablonu (Playwright/Postman), dodavatelé adaptují.

Important Volba varianty je na dohodě Dev týmu s ITT. V obou případech je JUnit XML povinný.

4.3. Integrační testy

Integrační testy ověřují interakci mezi službami nebo s externími systémy.

  • Pro simulaci závislostí: Testcontainers (DB, message brokery), WireMock (externí API).

  • Zakázáno volat reálné externí registry v integračních testech (viz 6, Správa testovacích dat a prostředí).

  • Integrační testy se spouštějí na vyžádání (manuálně nebo cíleným spouštěním pipeline), nikoliv automaticky s každým commitem.

  • Selhání integračních testů musí být vyřešeno před nasazením na vyšší prostředí.

4.4. Manuální testy

Manuální testy slouží k ověření scénářů obtížně pokrytých automatizací (složité edge-case chování, ověření UX aspektů, vizuální kontrola).

  • Provádějí je Dev týmy před předáním k akceptaci.

  • Protokoly mohou být vyžádány k revizi ze strany ITT nebo garantů.

Testovací protokol používá standardizovanou šablonu s následujícími sloupci:

Sloupec Popis

Test Case ID

Jednoznačný identifikátor testovacího scénáře (např. TC001).

Název testu

Stručný popis testované funkčnosti.

Popis kroku

Detailní posloupnost akcí, které tester provádí (včetně případných prerekvizit).

Vstupní data

Data potřebná pro provedení testu (uživatel, heslo, testovací záznamy apod.).

Očekávaný výstup

Co by se mělo stát při správném chování systému.

Výsledek #N

Pass / Fail – výsledek N-tého běhu testu.

Skutečný výstup #N

Co se skutečně stalo při N-tém běhu.

Tester #N

Jméno osoby, která test provedla.

Datum testu #N

Datum provedení N-tého běhu.

Poznámky #N

Doplňující informace, screenshoty, logy.


Note
Poznámky

  • Sloupce označené #N se opakují pro každý běh testu (#1, #2, …), což umožňuje evidovat výsledky regresních re-testů v jednom dokumentu.

  • Šablona je k dispozici jako Příloha A.

4.5. Akceptační testy

Akceptační testy jsou závěrečnou fází před převzetím funkčnosti.

  • Garanti služeb připravují scénáře ve spolupráci s ITT.

  • Testy se provádějí na STAGING.

  1. Akceptační protokol dokumentuje:

    • Testované scénáře a výsledky (PASS/FAIL).

    • Seznam připomínek a požadovaných úprav.

    • Rozhodnutí: PŘIJATO / PODMÍNĚNĚ PŘIJATO / VRÁCENO K PŘEPRACOVÁNÍ.

  2. Podmíněné přijetí:

    • Funkčnost je akceptována s výhradami. Výhrada nesmí být Critical nebo High. Všechny výhrady musí mít přiřazený úkol s termínem opravy (max. 14 kalendářních dnů). O podmíněném přijetí rozhoduje garant TRSu.

4.6. Smoke a E2E testy

Smoke a E2E testy spravuje ITT ve spolupráci s Dev týmy a garanty.

  • Smoke testy: základní funkčnost systému (přihlášení, načtení klíčových stránek). Běží kontinuálně na TEST, STAGING i PROD.

  • E2E testy: kompletní uživatelské flow. Běží 1× denně na STAGING.

  • E2E testy generují screen/video evidenci pro ladění a audit.

  • Selhání smoke testu na PROD spouští incident postup (viz Section 9.2, “Postup při selhání na PROD”).

4.7. Zátěžové testy

Zátěžové testy ověřují chování systému při očekávané a špičkové zátěži.

  • Provádí ITT ve spolupráci s Ops týmem na STAGING.

  • Zátěžový profil (počet uživatelů, scénáře, ramping) definuje ITT na základě produkčních dat.

  • Akceptační prahy: response time p95 a p99 pod definovanými limity.

  • Prahy stanovuje ITT na základě baseline měření a produkčních dat před každým testem a schvaluje je garant a Ops.

  • Před prvním testem se provede baseline měření pro budoucí porovnání.

  • Podrobnosti k výstupní zprávě viz Section 11.2, “Výkonnostní reporting”.

4.8. Bezpečnostní testy

Bezpečnostní testování je povinnou součástí vývojového cyklu.

  • SAST: SonarQube bezpečnostní pravidla běží s každým buildem.

  • Dependency scanning: Trivy nebo Snyk kontroluje zranitelnosti v závislostech s každým buildem.

  • DAST: OWASP ZAP nebo ekvivalent běží před každým velkým releasem na STAGING.

  • Klasifikace dle CVSS: Critical (9.0–10.0), High (7.0–8.9), Medium (4.0–6.9), Low (0.1–3.9).

  • Akceptační kritérium: 0 Critical a 0 High. Medium musí mít přiřazený úkol s termínem.

5. Quality Gates a vymahatelnost pravidel

Quality Gates jsou kontrolní body v CI/CD pipeline. Selhání blokuje postup do další fáze. Obejití není přípustné bez formálně schválené výjimky.

Gate Kdy Kontrola Blokuje

QG1 – Build & Unit

Každý commit/MR

Kompilace, unit testy, coverage ≥ 80 %

Merge do develop

QG2 – SonarQube

Každý commit/MR

Blocker/critical = 0, smells ≤ 5/1000

Merge do develop

QG3 – API testy

Merge do develop

API testy 100 % PASS

Deploy na TEST

QG4 – Staging

Deploy na STAGING

Smoke + E2E 100 % PASS

Postup k akceptaci

QG5 – Akceptace

Před PROD

Akceptační protokol schválen

Deploy na PROD

QG6 – Security

Před PROD

0 Critical/High (CVSS)

Deploy na PROD

5.1. Proces výjimek

V odůvodněných případech lze Quality Gate dočasně obejít:

  1. Žadatel (vedoucí Dev týmu) podá písemný požadavek s odůvodněním.

  2. Schválení provádí garant TRSu po konzultaci s ITT.

  3. Výjimka je časově omezena (max. 14 kalendářních dnů).

  4. Evidence v centrálním trackeru (Jira/Freelo) s odkazem na úkol opravy.

  5. Po vypršení: automatická re-evaluace. Pokud není problém opraven, nutno znovu schválit.

5.2. Nestabilní (flaky) testy

Nestabilní test = selhává v > 10 % běhů za posledních 7 dnů bez změny kódu.

  1. Nesmí dlouhodobě zůstávat v testovacích sadách.

  2. Oprava nebo dočasná deaktivace do 48 hodin od identifikace.

  3. Deaktivace evidována v trackeru s úkolem na opravu (termín max. 14 dnů).

  4. Odpovědnost: Dev tým (unit/integrační/API), ITT (smoke/E2E).

6. Správa testovacích dat a prostředí

Klíčem ke stabilnímu testování je kontrola nad daty a prostředími:

Prostředí Účel Přístup Obnova dat Specifika

DEV/lokální

Unit, integrační testy

Dev tým

Na vyžádání

Mockované závislosti

TEST

Integrace, API testy

Dev + ITT

Týdně (automat.)

Sdílené, syntetická data

STAGING

UAT, E2E, zátěžové

ITT + Garanti

Před release cyklem

Kopie PROD (anonymizovaná)

PROD

Smoke po nasazení

Ops + ITT (read-only)

N/A

Reálná data

  1. Idempotentnost:

    • Každý automatizovaný test si musí připravit vlastní data (pomocí API nebo DB seeding) a následně po sobě prostředí vyčistit. Testy nesmí záviset na datech vytvořených jinými testy.

  2. Mockování externích služeb:

    • Je zakázáno v testech volat reálné externí registry (IS VaVaI, CEDR, RES, Bisnode/MagnusWeb). Musí být využity simulátory (WireMock, vlastní mock služby), které vrací deterministické odpovědi.

  3. Izolace prostředí:

    • Prostředí TEST je určeno pro integrační pokusy, STAGING slouží jako věrná kopie produkce pro finální UAT a zátěžové testy.

  4. Anonymizace dat:

    • Kopie produkčních dat na STAGING musí být anonymizována v souladu s GDPR. Anonymizaci zajišťuje Ops tým.

  5. Testovací účty a credentials:

    • Uloženy v bezpečném úložišti (HashiCorp Vault nebo ekvivalent). Je zakázáno používat produkční credentials v testovacích prostředích. Rotace min.1× za 90 dnů. Zákaz ukládání do repozitáře se týká produkčních a reálných credentials a secrets; fiktivní neprodukční testovací účty (např. generátor projektů na STAGING/Linksoft, osoby neexistující na produkci) jsou přípustné, doporučeně však mimo repozitář (seed data / Vault) nebo jasně označené jako neprodukční.


  6. Seed data:

    • Referenční datová sada je verzována společně s kódem v Git. Při změně DB schématu se aktualizují i seed data.

    • Správa: Dev tým dané služby.

7. Akceptační kritéria (Definition of Done)

Žádný kód nesmí být nasazen na produkci, pokud nesplňuje následující kritéria:

  1. Code Coverage:

    • Min. 80 % pokrytí unit testy (SonarQube). Exkluze (generovaný kód, DTO, konfigurace) schváleny ITT. SonarQube Quality Gate: Žádné blocker nebo critical issues. Code smells max. 5 na 1000 řádků. Žádné nové security hotspots bez review. Regresní testy: 100 % úspěšnost všech automatizovaných sad (unit, integrační, API, smoke, E2E). Dev tým rozšiřuje regresní sadu při nové funkcionalitě.

  2. API testy:

    • 100 % úspěšnost pro dotčená API rozhraní včetně ověření návratových kódů, struktury odpovědí a negativních scénářů. Změny API nesmí porušit zpětnou kompatibilitu bez zavedení nové verze API.

  3. Bezpečnostní testy:

    • 0 Critical a 0 High zranitelností (CVSS). Medium musí mít přiřazený úkol s termínem opravy.

  4. Akceptační testy:

    • Akceptační protokol schválen garantem (PŘIJATO nebo PODMÍNĚNĚ PŘIJATO). Revize ITT s potvrzením pokrytí všech byznys scénářů.

  5. Zátěžové testy:

    • Služba je odolná vůči očekávané zátěži. Response time p95/p99 v definovaných limitech. Zátěžová zpráva schválena ITT a Ops.

Note
Poznámky

  • Akceptace může proběhnout s výhradami (PODMÍNĚNĚ PŘIJATO) při splnění akceptačních, API, unit a bezpečnostních testů. Plná akceptace až po splnění všech testů včetně zátěžových.

8. Používané nástroje a technologie

Kategorie Nástroje Poznámka

Unit testy & Coverage

JaCoCo, Istanbul/nyc, Coverage.py

Dle technologie (Java/Kotlin, JS/TS, Python)

Integrační testy

Testcontainers, WireMock

Simulace DB, brokerů, externích API

API testování

Postman/Newman, REST Assured, Karate

Výstup JUnit XML

E2E a Smoke

Playwright

Centrálně spravované ITT

Zátěžové

k6, JMeter

Dle preference ITT

Statická analýza

SonarQube (on-premise)

Quality Gate v CI/CD

Bezpečnost

SonarQube (SAST), OWASP ZAP (DAST), Trivy

SAST průběžně, DAST před releasem

CI/CD

GitLab CI

Pipeline v repozitáři

Správa testů

Dle rozhodnutí ITT (TestRail, Xray, Git)

Centrální úložiště scénářů

9. CI/CD linka a notifikační proces

Celý proces je řízen automatizovanou linkou v Kubernetes:

  1. Pre-deployment:

    • Build, unit testy, integrační testy (na vyžádání), statická analýza (SonarQube), dependency scan (Trivy). [QG1 + QG2]

  2. Deploy na TEST:

    • Automatické nasazení image. Spuštění API testů. [QG3]

  3. Deploy na STAGING:

    • Automatické nasazení. Smoke testy (kontinuálně), E2E testy (1× denně). Před releasem: zátěžové a DAST testy. [QG4]

  4. Akceptace:

    • Garant provede akceptační testy na STAGING, vydá akceptační protokol. [QG5 + QG6]

  5. Deploy na PROD:

    • Automatické nasazení. Post-deployment smoke testy.

  6. Monitoring:

    • Kontinuální sledování chybovosti a výkonu po nasazení

9.1. Rollback

Pokud smoke nebo E2E testy selhou po nasazení na STAGING, je zablokován postup do další fáze a odeslána notifikace do kanálu; na STAGING se neprovádí automatický rollback. Dev tým analyzuje příčinu a opraví před dalším pokusem.

Před vyhodnocením selhání jako blokujícího je nutné vyloučit nestabilní (flaky) nebo infrastrukturní příčinu – rollback ani blokace se nespouští na základě prokazatelně flaky/infrastrukturního selhání.

Pokud smoke testy selžou na PROD: okamžitý automatický rollback, spuštění incident postupu (viz Section 9.2, “Postup při selhání na PROD”). DB migrace musí být navrženy zpětně kompatibilně (umožňují rollback).

9.2. Postup při selhání na PROD

  1. Automatický rollback na poslední stabilní verzi.

  2. Notifikace: GoogleChat + email vlastníkovi služby + Ops on-call.

  3. Ops ověřuje stabilitu po rollbacku (smoke testy).

  4. Dev tým provádí Root Cause Analysis (RCA) do 48 hodin.

  5. Opravená verze prochází kompletní pipeline od začátku.

9.3. Notifikační proces

Jakékoliv selhání v kterémkoliv kroku odesílá okamžitou notifikaci do dedikovaného kanálu v Google Chat s odkazem na logy selhání.

  • Obsah: název služby, fáze pipeline, typ selhání, odkaz na build log.

  • Reakční čas: vlastník služby do 4 pracovních hodin od nahlášení incidentu interním testovacím týmem po analýze důvodu selhání testu. Nevyžaduje se nepřetržitý (24/7) provoz – garantují se pevné reakční lhůty dle severity (zejména Critical a High).

  • Eskalace při nereakci: vedoucí Dev týmu.

10. Správa defektů

Životní cyklus defektu: New → Assigned → In Progress → Fixed → Verified → Closed. Evidence v centrálním trackeru (Jira/Freelo). Verifikaci opravy provádí nahlašovatel, nikoliv autor opravy.

Závažnost defektu Definice Lhůta na opravu

Critical

Systém je nepoužitelný, dochází ke ztrátě nebo poškození dat, byl nalezen bezpečnostní incident.

4 hodiny (hotfix)

High

Klíčová funkcionalita systému je nefunkční a nelze ji nahradit jinou funkcionalitou.

24 hodin

Medium

Funkčnost systému je omezena, existuje však náhradní funkcionalita nebo workaround.

5 pracovních dnů

Low

Vizuální nedostatek, drobná nepřesnost bez dopadu na funkčnost systému, UX zlepšení.

Další sprint
Important
Důležité

  • Critical a High defekty blokují release. Medium mohou být součástí podmíněné akceptace s termínem opravy.

11. Speciální postupy

11.1. Bug Hunt kampaně

Před každým velkým releasem organizuje TAČR Bug Hunt – časově omezené, intenzivní manuální testování celého systému týmem analytiků, testerů a zástupců byznysu s cílem odhalit chyby v UX alogice, které nelze podchytit automatickým testováním.

  • Délka: 1–3 pracovní dny dle rozsahu releasu.

Velký release vyhlašuje pravidelná schůzka k testování (resp. vedení / VK) – typicky na konci MT, u velkých úprav služeb a před klíčovými termíny (např. měsíc před podáváním monitorovacích zpráv).

  • Účastníci: analytici, ITT, zástupci byznysu, garanti služeb.

  • Defekty reportovány se štítkem „BugHunt-[datum]“.

  • Exit kritérium: všechny Critical/High z Bug Hunt opraveny před releasem.

11.2. Výkonnostní reporting

Výstupem zátěžových testů je standardizovaný dokument, který musí obsahovat:

  1. Účel testu a testovaná služba.

  2. Metodika (nástroj, typ zátěže, scénáře).

  3. Zátěžový profil (počet uživatelů, ramping, délka).

  4. Výsledky: odezvy endpointů (průměr, medián, p95, p99), chybovost, throughput.

  5. Využití infrastruktury (CPU, RAM, síť).

  6. Porovnání s baseline.

  7. Doporučení pro škálování.

  8. Závěr: VYHOVĚL / NEVYHOVĚL. Zpráva archivována v projektové dokumentaci, schvalována ITT a Ops.

12. Testování požadavků z Freelo

Změny realizované mimo scope zadání MT (např. prostřednictvím Freelo, případně změny hrazené z DNS či technodluhových MT) podléhají zjednodušenému, ale povinnému testovacímu režimu. Testovací režim je jednotný napříč rámcovými dohodami (RD) i DNS; liší se pouze fází vývoje.

Každá změna MUSÍ před nasazením splňovat:

  • Manuální ověření garantem požadavku.

  • Existenci alespoň jednoho testovacího scénáře (manuálního nebo automatizovaného).

  • Pokud změna ovlivňuje backend nebo API, musí být doplněn alespoň jeden automatizovaný test. Technické posouzení (nutnost testu, dopad na backend/API) provádí Dev tým v rámci code review, kterým prochází každá změna kódu (i z Freelo či DNS); garant posuzuje byznysovou stránku. Žádná změna kódu neobchází code review.

  • Projití CI/CD pipeline bez chyb (všechny QG).

Important
Důležité

  • Změny NESMÍ být nasazeny pouze na základě implementace bez ověření. Cílem tohoto režimu je zachování regresní stability systému i při malých změnách.

13. Správa testovacích scénářů

  • Všechny scénáře (manuální i automatizované) uloženy v centrálním nástroji (ITT).

  • Verzování a review proces při změnách.

  • Mapovatelnost na byznysový požadavek (traceability: požadavek → scénář → výsledek).

  • Nová funkcionalita = nové/aktualizované scénáře.

  • Neaktuální scénáře se archivují, nemažou.

14. Metriky a KPI

ITT měsíčně reportuje:

Metrika Definice Cíl

Code coverage

Pokrytí byznys logiky unit testy

≥ 80 %

Defect escape rate

Defekty nalezené až na PROD vs. celkem

< 5 %

Flaky test rate

Nestabilní testy v sadách

< 2 %

Mean time to fix

Průměrná doba opravy selhávajícího testu

< 48 h

Regresní úspěšnost

Úspěšnost automat. regresních sad

≥ 99 %

Akceptační úspěšnost

Akceptace bez vrácení

≥ 90 %
Note
Poznámky

  • Reportováno vedení TAČR jako podklad pro hodnocení kvality dodávek. Dlouhodobý trend je důležitější než absolutní hodnota.

  • Defect escape rate navazuje na evidenci defektů dle 10, Správa defektů.

Závěr

  1. Platnost dokumentu

    Pravidla testování představují mantinely pro Dev týmy, přičemž účastníci rámcové dohody jsou povinni tato pravidla dodržovat. Zároveň také platí, že zadavatel podporuje jejich průběžnou aktualizaci a to dle závěrů Archa rady, z úrovně řízení projektu či dobré praxe.

  2. Odborný garant

Odborný garant

Dominik Kyjevský

Kontakt

[email protected]

Verze

2

Datum poslední revize

17/06/2026

Termíny a definice

SISTA

Informační systém TAČR pro správu a hodnocení podpory výzkumu a vývoje; ekosystém služeb, kterého se tato pravidla týkají.

QA (Quality Assurance)

Zajišťování kvality – soubor činností zaručujících, že dodávka splňuje požadavky.

CI/CD

Kontinuální integrace a nasazování; automatizovaná linka, která buduje, testuje a nasazuje kód.

Quality Gate (QG)

Kontrolní bod v CI/CD pipeline; jeho nesplnění blokuje postup do další fáze.

Dev tým

Vývojový (dodavatelský či interní) tým odpovědný za kvalitu svého kódu a automatizované testy.

ITT (Interní testovací tým)

Tým SISTA spravující centrální Smoke/E2E sady, revidující manuální a akceptační scénáře, provádějící zátěžové testy a reporting metrik.

Garant (garant TRSu)

Vlastník byznysových požadavků dané služby; připravuje akceptační scénáře a vydává akceptační rozhodnutí.

Ops tým

Tým provozu; zajišťuje stabilitu prostředí, CI/CD linky, správu credentials a obnovu dat.

Unit test

Test izolované logiky komponenty.

Integrační test

Ověření interakce mezi službami nebo s externími systémy.

API test

Validace API rozhraní včetně pozitivních i negativních scénářů.

Manuální test

Ruční ověření obtížně automatizovatelných scénářů (UX, edge-case); provádí Dev tým před předáním k akceptaci.

Akceptační test

Závěrečné ověření souladu s byznysovými požadavky; provádí garant na prostředí STAGING.

Smoke test

Rychlé ověření základní funkčnosti systému po nasazení.

E2E test (End-to-End)

Ověření kompletního uživatelského flow napříč systémem.

Regresní test

Ověření, že nové změny nerozbily stávající funkčnost.

Zátěžový test

Ověření chování systému při očekávané a špičkové zátěži.

Bezpečnostní test

Hledání zranitelností v kódu a závislostech (SAST, DAST, dependency scan).

SAST / DAST

Statická analýza bezpečnosti zdrojového kódu (SonarQube) / dynamická analýza běžící aplikace (OWASP ZAP).

Coverage (pokrytí kódu)

Podíl kódu pokrytého automatizovanými testy; cíl >= 80 % byznys logiky.

TDD (Test-Driven Development)

Vývoj řízený testy – testy se píší před implementací.

Flaky test

Nestabilní test selhávající ve více než 10 % běhů bez změny kódu.

DoD (Definition of Done)

Sada akceptačních kritérií, která musí být splněna před nasazením na PROD.

Baseline

Referenční měření výkonu pro budoucí porovnání.

CVSS

Standard klasifikace závažnosti zranitelností (Critical / High / Medium / Low).

Bug Hunt

Časově omezená intenzivní manuální testovací kampaň před velkým releasem.

RACI

Matice odpovědností: Responsible (vykonává), Accountable (schvaluje), Consulted (konzultován), Informed (informován).

Prostředí (DEV / TEST / STAGING / PROD)

DEV/lokální – vývoj a unit testy; TEST – integrační a API testy na syntetických datech; STAGING – akceptační, E2E a zátěžové testy na anonymizované kopii produkce; PROD – produkce s reálnými daty.

MT

Minitendr - Zakázka/úkol dodávky SW realizovaný dle definovaného zadání (např. MT112, MT124)

Freelo

Nástroj pro řízení úkolů a požadavků; zahrnuje změny realizované mimo zadání MT.

RD / DNS

Rámcová dohoda / dynamický nákupní systém – režimy zadávání veřejných zakázek u dodavatelů.