Část III Vývoj: jak projekt uřídit
Kapitola 20: Testování, převzetí a spuštění
Akceptací přebíráte dílo. Váže se k ní fakturace, začátek záruky i změna odpovědnosti za vady. Je to poslední chvíle, kdy máte páku, takže nepřebírejte nic pod časovým tlakem, bez ověření na reálných datech, bez kódu nebo dokumentace. Spouštějte podle připravenosti, ne podle data, a po spuštění počítejte s několika týdny zvýšené podpory.
Testů je víc druhů a vy osobně děláte jen jeden
Každý druh testu hlídá něco jiného. Většinu provádí dodavatel nebo specialista. Vy si vyžádejte jejich výsledky. Uživatelské akceptační testy ale děláte vy: s klíčovými uživateli, na reálných scénářích a anonymizovaných reálných datech. Vymyšlená data neodhalí všechny problémy skutečného provozu.
| Test | Na co se ptá | Kdo dělá | Co chtít vidět |
|---|---|---|---|
| Jednotkové a integrační | Fungují jednotlivé části a jejich propojení? | dodavatel, automaticky | report z automatického sestavení |
| End-to-end | Projde celý proces napříč systémy? | dodavatel | výsledky na reálných scénářích |
| Výkonový a zátěžový | Vydrží systém tolik uživatelů, kolik slibuje? | dodavatel nebo specialista | výsledek proti nefunkčním požadavkům |
| Bezpečnostní skeny | Neobsahuje kód nebo knihovna známou zranitelnost? | dodavatel, automaticky | výsledky skenů a opravy |
| Penetrační test | Dostane se útočník dovnitř? | nezávislá třetí strana | zpráva a doklad o opravách |
| Přístupnost | Zvládne systém i člověk se čtečkou nebo jen s klávesnicí? | auditor | automatický i ruční audit |
| Uživatelské akceptační (UAT) | Dá se v tom reálně pracovat? | vaši klíčoví uživatelé | protokol a seznam vad A/B/C |
| Migrace a obnova | Přenesou se data správně a lze obnovit původní stav? | dodavatel a vaše IT | odsouhlasené počty a součty |
Podle běžné praxe; konkrétní požadavky na testy patří do smlouvy a do akceptačních kritérií.
Penetrační test zadejte třetí straně, ne dodavateli softwaru. Nikdo nemá zkoušet zámky, které sám montoval. Opravené nálezy z testu patří mezi podmínky převzetí.
Akceptace má tři možné výsledky
Dodavatel předá etapu s protokolem vlastních testů. Vy testujete ve sjednané lhůtě. Orientačně počítejte s 10–15 pracovními dny pro etapu a 3–5 dny pro sprint. Každou nalezenou vadu zapíšete a zařadíte do kategorie. Výsledek je jeden ze tří:
- akceptováno,
- akceptováno s výhradou: zbývají jen drobné vady, případně omezený počet závažných s termínem opravy,
- neakceptováno: dodavatel opraví a akceptace se opakuje.
Podpis akceptace má zásadní důsledky. Dodavatel může fakturovat, začne běžet záruka za jakost (pravidlo palce 12–24 měsíců) a vady se od té chvíle řeší jako reklamace, ne jako nedodělek. Část ceny, orientačně 5–10 %, si proto ponechte jako zádržné do konce záruky nebo hypercare.
Kategorie vad a jejich limity dejte do smlouvy předem. Jinak se o tom, jestli je vada „kritická“, budete přít ve chvíli, kdy dodavatel tlačí na podpis a vy na termín.
| Kategorie | Co to je | Vliv na akceptaci | Typická oprava |
|---|---|---|---|
| A (kritická) | systém nebo klíčový proces nefunguje, ztráta dat, bezpečnostní díra | brání akceptaci | hodiny až 1–2 dny |
| B (závažná) | funkce je omezená, ale existuje náhradní postup | do sjednaného počtu s výhradou | dny |
| C (drobná) | kosmetika, nepohodlí | nebrání | do další verze |
Přehled vychází z běžné praxe; lhůty oprav jsou orientační. Limit vad B pro akceptaci s výhradou sjednejte ve smlouvě.
Nepřebírejte dílo bez kódu a dokumentace
Podpisem převzetí ztrácíte páku. Předtím chtějte předávací balíček: kód ve vašem repozitáři s historií a postupem sestavení, licenci k úpravám i jinou firmou, seznam komponent třetích stran (SBOM), dokumentaci, přístupy na vaše jméno a výsledky testů. Test je jednoduchý: „Ukažte, že dokážeme systém sestavit a nasadit bez vás.“
Co při převzetí nedostanete, budete platit roky. Kam to vede, ukazuje daňový systém ADIS, kde závislost na dodavateli ze smlouvy z roku 1992 skončila pokutami od ÚOHS (kapitola 24).
Spouštějte podle připravenosti, ne podle data
Go/no-go je rozhodnutí krátce před spuštěním: je systém připravený? Spuštění schvalte jen tehdy, když platí všechny následující podmínky:
- žádná otevřená vada A a vady B pod sjednaným limitem,
- úspěšná zkušební migrace dat,
- splněný výkonový test,
- penetrační test bez kritických nálezů,
- vyškolení uživatelé,
- připravený a vyzkoušený návrat zpět,
- schválená bezpečnost a u úřadu splněné zákonné povinnosti.
Rozhodnutí zapište i s tím, kdo ho udělal. Spouštějte postupně: nejdřív pilot s jedním útvarem nebo pobočkou, pak rozšíření. Britská vládní služba GDS pouští nové služby nejdřív omezenému okruhu uživatelů, pak všem v režimu beta a naostro až po hodnocení GDS, fáze beta. Postupným spuštěním omezíte rizika, která by se jinak dotkla všech uživatelů naráz.
Převod dat ze starého systému je samostatná část dodávky s vlastní akceptací: zkušební migrace na kopii produkčních dat, odsouhlasené počty a kontrolní součty a vyzkoušený návrat zpět (viz checklist).
Digitalizace stavebního řízení: spuštění (MMR, 2024)
Systém šel do ostrého provozu celoplošně 1. 7. 2024, protože to určoval zákon. Akceptace proběhla 20. 6. 2024, tedy dřív, než 28. 6. skončilo uživatelské testování. Informační systém stavebního řízení testovali 4 uživatelé, zástupci klíčových uživatelů do akceptace zapojeni nebyli a všechna plnění byla převzata bez výhrad. Penetrační testy proběhly jen na části systémů Audit DSŘ, technická část, 2025.
Podle právní části auditu systémy nesplňovaly všechny požadavky zákona o kybernetické bezpečnosti a provoz začal bez předložení provozní dokumentace Digitální a informační agentuře Audit DSŘ, právní část, 2025. Řídicí výbory přitom v březnu a dubnu 2024 zasedaly a technický dozor na nich varoval před kritickými riziky. Účinně na to nikdo nereagoval Audit DSŘ, technická část, 2025. V říjnu 2024 vláda rozhodla systémy dál nevyvíjet a připravit novou soutěž Vláda, 16. 10. 2024.
Poučení: zákonné datum nenahrazuje go/no-go. Když termín hrozí, vyjednejte včas přechodné období nebo náhradní řešení. Možnosti zastavení projektu rozebírá kapitola 19. Spor o soutěž u ÚOHS popisuje kapitola 12.
Zdroj: Audit DSŘ, technická část (19. 8. 2025), Audit DSŘ, právní část (4. 4. 2025), Materiál pro vládu, 16. 10. 2024
Po spuštění: lidé a období zvýšené podpory
Systém je hotový, až když v něm lidé umí pracovat. Školení podle rolí dělejte krátce před spuštěním, ne tři měsíce předem, kdy lidé řadu věcí do spuštění zapomenou. Na pracovištích pomůžou superuživatelé, cvičné prostředí a krátké návody. Počítejte s dočasným poklesem produktivity a s tím, že starý postup musí opravdu skončit. NKÚ v roce 2026 upozornil, že digitalizace formulářů práci zaměstnanců úřadů zatím neurychlila, protože procesy uvnitř zůstaly ruční NKÚ, 2026.
Prvních 4–12 týdnů po spuštění (pravidlo palce) potřebujete hypercare: posílený tým dodavatele, kratší reakční doby a denní krátkou poradu nad problémy. Konec hypercare určují předem daná kritéria, třeba 2 týdny bez vady A, ne datum. Hypercare patří do smlouvy o vývoji, běžný provoz pak do smlouvy o podpoře (kapitola 21).
| Jak to dopadá špatně | Jak to dělat dobře |
|---|---|
| Jak to dopadá špatněAkceptace „na papíře“ pod časovým tlakem. | Jak to dělat dobřeAkceptace podle předem dohodnutých kritérií a lhůt. |
| Jak to dopadá špatněUAT na vymyšlených datech. | Jak to dělat dobřeUAT s klíčovými uživateli na reálných scénářích a anonymizovaných reálných datech. |
| Jak to dopadá špatněPentest až po spuštění, nebo ho dělá sám dodavatel. | Jak to dělat dobřeNezávislý pentest před spuštěním, nálezy opravené před akceptací. |
| Jak to dopadá špatněKód předaný jako ZIP bez postupu sestavení. | Jak to dělat dobřeRepozitář s historií a build; třetí strana systém sestaví a spustí. |
| Jak to dopadá špatněSpuštění dané datem, pro všechny naráz. | Jak to dělat dobřeGo/no-go podle kritérií, pilot a pak rozšíření. |
| Jak to dopadá špatněPo spuštění „volejte, kdyby něco“. | Jak to dělat dobřeHypercare 4–12 týdnů s kritérii ukončení ve smlouvě. |
- Podmínky akceptace, klasifikaci vad, sankce a předávací balíček dejte do zadávací dokumentace a smlouvy. Pozdější změkčení nebo prodloužení lhůt je změna závazku (kapitola 18).
- Správce určeného informačního systému předkládá DIA před zahájením provozu provozní dokumentaci a službu smí spustit až po jejím vyjádření Zákon č. 365/2000 Sb.. Počítejte s tím v harmonogramu.
- Bezpečnostní povinnosti podle zákona č. 264/2025 Sb. splňte před spuštěním. Tým v hypercare musí incident umět rozpoznat a nahlásit v zákonných lhůtách Zákon č. 264/2025 Sb. (kapitola 15).
- Před spuštěním zajistěte audit přístupnosti a prohlášení o přístupnosti Zákon č. 99/2019 Sb..