Explorativní testování: co samotná automatizace nenajde
Automatizovaný test spolehlivě opakuje kontrolu, kterou jsme mu zadali. Nedokáže však sám posoudit všechno, co uživatele zaskočí, působí nejasně nebo vznikne v kombinaci stavů, se kterou autor testu nepočítal. Právě tam má místo explorativní testování: tester se během práce učí o produktu, navrhuje další pokusy a ihned je provádí.
Nejde o náhodné klikání bez přípravy. Dobře vedené explorativní testování má cíl, časový rámec, poznámky a závěrečné vyhodnocení. Doplňuje automatizovanou regresi, nenahrazuje ji.
Úspěšná regrese ještě neznamená dobrý produkt
Představte si checkout, u kterého automat zkontroluje přidání produktu, adresu, platbu i potvrzení objednávky. Všechny aserce projdou. Člověk si však může všimnout, že tlačítko na mobilu překrývá klávesnice, chybová zpráva neříká, které pole je potřeba opravit, nebo návrat z platební brány vytvoří v košíku nejistý stav.
Automat neudělal chybu. Ověřil přesně to, co obsahoval scénář. Problém je v hranici předem známé kontroly: pokud nikdo nenapsal aserci na srozumitelnost zprávy nebo scénář s návratem tlačítkem prohlížeče, výsledek „passed“ o nich nic neříká.
Čím je aplikace dynamičtější, tím více záleží na pořadí kroků, datech, oprávněních a předchozím stavu. Formálně správná odpověď může být pro uživatele stále nesrozumitelná. A požadavek může být implementován přesně, přestože samotný požadavek nepokrývá důležitou situaci.
Co znamená testovat explorativně
U skriptovaného testu známe kroky a očekávaný výsledek ještě před spuštěním. U explorativního testu máme předem určenou misi, nikoli celý seznam kliknutí. Misí může být například: „Prozkoumej změnu doručovací adresy po návratu z platby a hledej stavy, ve kterých uživatel neví, zda objednávka vznikla.“
Tester potom pracuje v krátké, soustředěné relaci. Pozorování z jednoho kroku ovlivní další krok. Pokud aplikace po dvojitém odeslání zobrazí neobvyklý stav, tester jej prozkoumá, zkusí návrat, obnovení stránky, jinou roli nebo přerušení sítě. Takové větvení by v pevném scénáři nebylo, dokud by jej někdo výslovně nenavrhl.
ISTQB v sylabu Advanced Level Test Analyst popisuje relace řízené testovací chartou a následným shrnutím výsledků. Charta udrží pozornost na riziku, ale ponechá testerovi prostor reagovat na nové informace.
Oblasti, kde připravený automat často nestačí
Explorativní pohled přináší největší hodnotu tam, kde správnost není pouze jedna porovnatelná hodnota.
- Nejasná uživatelská zkušenost. Funkce technicky pracuje, ale názvy, pořadí kroků nebo zpětná vazba vedou člověka k nesprávnému rozhodnutí.
- Neočekávané pořadí událostí. Uživatel otevře dvě karty, vrátí se zpět, obnoví stránku, změní údaje uprostřed procesu nebo pokračuje po vypršení relace.
- Kombinace rolí, dat a stavů. Samostatná pravidla fungují, ale jejich souběh vytvoří konflikt. Příkladem je sleva, částečně vrácená objednávka a účet s omezeným oprávněním.
- Slabé nebo chybějící požadavky. Automat umí potvrdit shodu se specifikací. Hůře odhalí, že specifikace neřeší přerušení procesu nebo uživateli nenabízí bezpečnou cestu zpět.
- Vizuální a obsahové nesrovnalosti. Vizuální regrese porovná obrázky, ale člověk lépe posoudí význam nešťastně zalomeného textu, zavádějící popis nebo nepřiměřenou hierarchii informací.
- Nová rizika po změně. Redesign, nový způsob autentizace nebo změna integrace může přinést chování, které historické testy vůbec nemají ve svém modelu.
Některé z těchto kontrol lze později automatizovat. Explorace však nejprve pomůže zjistit, co má smysl kontrolovat. To je jiná úloha než rychle opakovat již známé očekávání.
Jak připravit užitečnou testovací relaci
Praktická relace může trvat 45 až 90 minut. Delší blok zvyšuje únavu a ztěžuje přesné poznámky. Před začátkem stačí připravit šest věcí:
- Riziko a misi. Místo „otestuj profil“ určete, co chcete zjistit: například chování rozpracovaných změn při ztrátě připojení.
- Rozsah. Pojmenujte role, zařízení, prostředí a části produktu, které do relace patří. Stejně důležité je uvést, co je mimo ni.
- Vhodná data. Připravte běžné, hraniční i neúplné údaje. Pokud tester polovinu času čeká na účet nebo objednávku ve správném stavu, relace ztrácí soustředění.
- Orákulum. Určete, podle čeho budete chování hodnotit: požadavek, obchodní pravidlo, předchozí verze, srovnatelná funkce nebo rozumné očekávání uživatele.
- Způsob záznamu. Stačí stručné poznámky s časem, použitými daty, prostředím a důkazem. Při selhání přidejte kroky, log, snímek nebo síťový požadavek podle typu problému.
- Závěrečný debrief. Po relaci oddělte potvrzené chyby, otázky k požadavkům, nápady na další test a oblasti, které se nestihly prověřit.
Výsledkem není počet kliknutí. Je jím lepší mapa rizik a rozhodnutí, co opravit, co ještě ověřit a co zařadit do opakovatelné regrese.
Jak spojit exploraci s automatizací
Tyto přístupy se posilují. Automatizace může před relací vytvořit účet, naplnit košík nebo dostat aplikaci do složitého stavu. Tester potom neplýtvá časem opakováním známé přípravy a soustředí se na nové chování.
Opačným směrem putují stabilní zjištění. Když explorace odhalí důležitou chybu a tým dokáže jednoznačně popsat očekávaný výsledek, vznikne kandidát na automatizovaný regresní test. Ne každé zjištění je nutné automatizovat: jednorázová kosmetická odchylka nebo kontrola vyžadující lidský úsudek může zůstat v manuálním rozsahu. Pomůže výběr toho, co se nevyplatí automatizovat.
Rozumný rytmus může vypadat takto: krátká automatizovaná kontrola při každé změně, cílená explorace nové nebo rizikové funkce před releasem a občasná širší relace nad místy, kterých se běžná regrese dlouho nedotkla. Frekvence závisí na riziku a tempu změn, ne na univerzálním kalendáři.
Kdo má explorativní relaci vést
Exploraci nemusí dělat pouze člověk s pracovní pozicí tester. Vývojář zná technické hranice a umí cíleně zkoušet souběh událostí. Produktový člověk rozumí obchodním výjimkám. Designér si spíše všimne nejasné zpětné vazby a pracovník podpory zná situace, se kterými se zákazníci skutečně potýkají.
Zkušený tester přináší testovací techniky, odstup a schopnost systematicky měnit jednu podmínku. Velmi účinná proto bývá párová relace: tester s vývojářem, doménovým expertem nebo designérem. Jeden člověk ovládá produktový kontext, druhý vede experiment a dokumentuje zjištění.
Role se vyplatí střídat. Autor funkce může nevědomky opakovat zamýšlený postup a přehlédnout alternativu, zatímco člověk bez kontextu nerozpozná důležité obchodní pravidlo. Krátký úvod k riziku a následný debrief spojí oba pohledy, aniž by se relace změnila v neorganizovanou skupinovou kontrolu.
U opakovaných relací sdílejte také použité heuristiky a nezodpovězené otázky. Další člověk tak nezačne od nuly, ale stále má prostor prozkoumat produkt jinou cestou a zpochybnit předchozí předpoklady.
Co explorativní testování nenahrazuje
Explorace není důkaz úplného pokrytí. Dvě relace vedené různými lidmi nebudou totožné a bez poznámek se zjištění hůře reprodukuje. Výsledek závisí na znalosti domény, zvídavosti i schopnosti klást dobré otázky.
Nenahrazuje ani specializované měření výkonu, bezpečnostní posouzení, kontrolu přístupnosti či právní hodnocení. Může na problém upozornit, ale k potvrzení jsou často potřeba vhodné nástroje a odborný postup. U pravidelných regresí zase automatizace poskytuje rychlost a konzistentnost, kterou manuální relace nedokáže hospodárně zopakovat.
Proto má mít explorace vlastníka a výstup. Pokud tým pouze řekne „někdo to prokliká“, aktivita se při časovém tlaku ztratí a její kvalitu nelze posoudit.
Praktický přínos pro tým
Dobře cílená relace dá týmu informace, které před přípravou testu neznal. Může odhalit mezeru v požadavku ještě předtím, než se z ní stane série chybných implementací, nebo upozornit na uživatelský problém, který technické metriky neukazují.
Zároveň zpřesňuje automatizační backlog. Namísto růstu sady podle počtu dostupných testovacích případů tým přidává kontroly tam, kde již vidí konkrétní riziko. Taková kombinace omezuje falešný pocit jistoty z vysokého počtu zelených testů a dává testovací strategii zpětnou vazbu z reálného používání.
Další krok
Vyberte jednu nedávno změněnou nebo uživatelsky citlivou funkci. Sepište pro ni jednořádkovou misi, vyhraďte 60 minut a po relaci rozdělte zjištění na chyby, otázky, nová rizika a kandidáty na regresi. Už první dobře zdokumentovaná relace ukáže, co vaše dnešní automatizace ověřuje — a o čem zatím nic neříká.