Exploratorní testování chápu jako cílené zkoumání systému, při němž se další otázka mění podle toho, co právě zjistíme. Není to seznam předem sepsaných kroků ani bezcílné klikání. Má mít vymezený účel, čas a záznam. Charter je stručné zadání průzkumu: kterou oblast zkoumáme, jaké riziko hledáme a jaký důkaz chceme získat. Přínos vidím zejména tam, kde existují nejasné požadavky, složité návaznosti nebo neobvyklé kombinace uživatelských kroků.
U bankovní aplikace může standardní scénář potvrdit, že přihlášený klient úspěšně odešle platbu. Průzkum se ale ptá také na přerušení připojení, opakování požadavku, návrat do předchozího okna nebo změnu oprávnění během rozpracované operace. Ne každá odchylka je chyba. Úkolem testera je poznat, kdy potřebuje vysvětlení pravidla, kdy doložit nesprávné chování a kdy objevil riziko, které zatím nikdo přesně nevymezil.
Skutečný případ: TSB, Spojené království, duben 2018
Po migraci platformy TSB v dubnu 2018 nastaly rozsáhlé problémy s bankovními službami. FCA a PRA v prosinci 2022 oznámily celkovou pokutu 48,65 milionu liber za nedostatky řízení provozních rizik a správy programu. Podle regulátorů se data převedla úspěšně, ale nová platforma vykazovala technické poruchy.
Tento případ nedokazuje, že by konkrétní exploratorní sezení incidentu zabránilo. Z veřejného oznámení také neznáme úplný seznam provedených testů. Pro mou úvahu je však důležité odlišení úspěšného převodu dat od funkční služby. Navrhovala bych zkoumat celý uživatelský výsledek a návaznosti, ne pouze potvrdit jeden dílčí technický milník. Jde o analytické ponaučení, nikoli o automatický přenos britských právních povinností do českého prostředí.
Jak napsat charter, který skutečně pomáhá
Slabé zadání zní „otestovat platby“. Lepší zadání by vymezilo například přerušení spojení po potvrzení odchozí platby a cíl zjistit, zda klient pozná její skutečný stav a zda opakování nevytvoří duplicitu. Takový charter nepředepisuje všechny kroky. Dává testerovi rozhodovací rámec, podle kterého může volit kombinace, sledovat reakce systému a zaznamenat, které situace zůstaly neprozkoumané.
Před začátkem bych ujasnila prostředí, oprávnění, testovací účty a bezpečné limity. Platby bych simulovala v odpovídajícím testovacím prostředí, nikoli svévolně v produkci. Zapsala bych známé omezení simulátoru a dostupné důkazy: identifikátor požadavku, čas události, historii změn stavu a klientské hlášení. Pokud některé důkazy nemáme, ovlivňuje to závěr. Není správné označit operaci za úspěšnou pouze proto, že uživatelské rozhraní zobrazilo potvrzení.
Modelové sezení: nejistý výsledek platby
Představme si devadesátiminutové sezení s fiktivním převodem 1 000 Kč mezi testovacími účty. Prvních patnáct minut věnuji přípravě a ověření běžného průchodu. Dalších čtyřicet minut měním okamžik přerušení komunikace: před odesláním, po přijetí serverem a před zobrazením odpovědi klientovi. Zbytek času ponechám na reprodukci nejzajímavějšího nálezu a na společné vyhodnocení. Časy i částka jsou pouze modelové.
Pokud klient dostane chybové hlášení, ale zůstatek se změní, otázka zní, co má správně udělat dál. Zkusila bych znovunačtení historie a kontrolované opakování požadavku. Sledovala bych, zda systém rozpozná stejnou operaci a zda stav ve frontě odpovídá stavu zobrazenému klientovi. Za nález bych nepovažovala samotné zpomalení; důležitý je nesoulad, který může uživatele vést k chybnému dalšímu kroku.
Druhou větev by tvořila změna oprávnění. Má-li pracovník právo platbu připravit, ale nikoli schválit, ověřila bych chování rozpracovaného formuláře po změně role. Následovala by otázka, kdo kontroluje oprávnění v rozhodujícím okamžiku. Pouhé skrytí tlačítka nemusí být dostatečný důkaz správné autorizace. Způsob ověření bych dohodla s technickým týmem, abych nepřekročila povolený rozsah testování.
Jak bych zapisovala průběh
Pracovní poznámky bych vedla jako časovou osu: záměr, provedená změna, pozorování a nový směr. U překvapení bych oddělila fakt od domněnky. „Po opakování se zobrazily dvě položky se stejnou částkou“ je pozorování. „Server neumí zabránit duplicitě“ je zatím vysvětlení, které potřebuje ověřit identifikátory a skutečné zaúčtování. Právě toto rozlišení umožňuje vývojáři navázat bez zbytečného sporu o příčinu.
Po sezení bych neodevzdávala jen seznam chyb. Součástí výsledku by byla pokrytá oblast, použité podmínky a zbývající otázky. Například jsme prozkoumali přerušení během potvrzení, ale ne výpadek závislé služby při dávkovém zpracování. Taková informace chrání tým před přehnaným závěrem, že platby byly „kompletně otestované“. Nález s vyšším dopadem bych předala hned, nikoli až po dokončení formálního zápisu celého sezení.
Jak proměnit objev v trvalejší ochranu
Dobře reprodukovatelný problém bych propojila s konkrétním požadavkem a návrhem regresního scénáře. Ne každý objev však potřebuje automatizovaný test na úrovni prohlížeče. Některé pravidlo lze levněji ověřit na rozhraní služby nebo přímo v doménové logice. Rozhodovala bych podle toho, kde vzniká riziko a jaký test poskytne stabilní, srozumitelný signál. Explorace tím neztrácí význam; pomáhá objevit, co má být pravidelně chráněno.
Vyhnula bych se hodnocení testera jen podle počtu nalezených chyb. Sezení může přinést hodnotu i tím, že vyjasní nejednoznačné pravidlo nebo doloží správné zvládnutí rizikové situace. Zároveň bych charter nezaměňovala za důkaz pokrytí. Je to plán zkoumání. Teprve skutečný záznam ukazuje, co se provedlo, jaké výstupy byly pozorovány a které omezení může výsledek zpochybnit.
Debrief jako společné rozhodnutí o dalším kroku
Po ukončení sezení bych chtěla krátce projít nálezy s člověkem, který rozumí účelu služby. U každého překvapení bych položila tři otázky: jaké chování bylo očekáváno, jaký důkaz máme a co by mohlo vysvětlit rozdíl. Pokud očekávání není jasné, výsledkem může být požadavek na jeho doplnění. Pokud chování odporuje potvrzenému pravidlu, vzniká hlášení vady. Pokud se ukáže omezení testovacího prostředí, zaznamenám jej jako překážku závěru, ne jako chybu produktu.
Další charter bych odvodila z konkrétní mezery. Jestliže se stav platby správně zobrazil po novém přihlášení, ale ne v původním okně, mohu se zaměřit na aktualizaci rozhraní. Pokud se rozcházejí identifikátory dvou navazujících služeb, zvolila bych průzkum datové návaznosti. Tím vzniká série účelných krátkých zkoumání. Není nutné všechna rizika vměstnat do jediné rozsáhlé relace, jejíž závěr pak nikdo nedokáže jednoznačně interpretovat.
Záznam by měl umožnit návrat po několika týdnech. Připojila bych proto verzi systému, použitou roli, časové pásmo a podmínky přerušení komunikace. Zbytečné osobní údaje bych do sdíleného zápisu nevkládala. U důležitého nálezu bych označila, který krok je spolehlivě opakovatelný a který závisel na náhodném načasování. Právě tato poctivost pomáhá plánovat další ověření a chrání tým před falešnou jistotou, že jednou pozorovaná situace je plně vysvětlena.
Shrnutí a doporučení
Doporučila bych začít úzkým charterem navázaným na konkrétní uživatelské riziko. Předem připravit bezpečné prostředí, ponechat čas na reprodukci a pravidelně vyhodnocovat, co se tým naučil. Zjištění předávat s důkazem, očekáváním a popisem omezení. Exploratorní testování doplňuje předem připravené kontroly tím, že ponechává prostor pro otázky vzniklé během práce. Jeho kvalitu ukazuje srozumitelný poznatek, nikoli množství nahodilých kliknutí nebo pouze délka sezení.