Testovací strategie a audit

Od byznys požadavku k testu: jak se dohodnout, co má aplikace ověřitelně dělat

Požadavek „zákazník se má umět přihlásit na workshop“ ještě neříká, podle čeho poznáte správný výsledek. Product owner, tedy člověk odpovědný za směřování produktu, analytik, vývojář i tester si pod ním mohou představit něco jiného. Společné zadání má proto popsat vstupy, podmínky a očekávané chování tak, aby ho klient dokázal schválit a tým následně ověřit. Začít lze i bez hotových testovacích scénářů.

Proč seznam kliknutí nestačí

Postup „otevři web, vyber workshop, stiskni Přihlásit“ popisuje ovládání aplikace. Chybí mu ale význam úspěchu: vznikla platná registrace, ubylo místo a vidí uživatel správný stav? Zelený výsledek testu, který zkontroloval pouze zobrazení tlačítka, na tyto otázky neodpovídá.

Podobně nejasné jsou požadavky „má to být rychlé“ nebo „chybu je třeba správně ošetřit“. Tým potřebuje dohodnout podmínky, pozorovatelný výsledek a podle potřeby také časový limit. Aktuální chování aplikace může pomoci při zkoumání, samo o sobě však není důkazem zamýšleného pravidla. Jinak si do zadání přepíšete i existující chybu.

Tento krok předchází rozhodování, kdy spustit smoke, sanity nebo akceptační testy. Zde se dohodne, co má aplikace dělat; uvedené typy testování pak tuto dohodu používají k různým účelům.

Co přinést, když nemáte připravené scénáře

Klient nemusí napsat technickou specifikaci. Užitečnějším začátkem bývá ukázka běžné práce, popis problému a konkrétní případ, při kterém vznikla chyba nebo nejistota. Analytik či tester z těchto podkladů připraví návrh, otevřené otázky a příklady ke schválení.

Na společné setkání stačí připravit:

• Cíl a uživatele: kdo potřebuje něco udělat a proč je výsledek důležitý.
• Vstupy: například zvolený workshop, účet účastníka a počet obsazených míst; při ukázkách používejte připravené testovací údaje.
• Předpoklady: co už musí platit, například přihlášený uživatel, otevřená registrace a existující workshop.
• Očekávaný výsledek: co uživatel nebo navazující systém pozoruje po provedení akce.
• Hranice a výjimky: poslední volné místo, plná kapacita, opakovaný požadavek či nedostupná závislost.
• Vlastníka rozhodnutí: kdo může potvrdit pravidlo, když mají členové týmu odlišný výklad.

Chybějící odpověď zapište jako otevřenou otázku s konkrétním vlastníkem. Předpoklad „asi se má poslat e-mail“ nesmí nenápadně přejít do schváleného požadavku. Pokud bez odpovědi nelze určit správný výsledek, daný scénář ještě není připravený k realizaci.

Jak z rozhovoru vzniknou přijímací kritéria

Přijímací, často označovaná také jako akceptační, kritéria jsou podmínky, podle kterých posoudíte splnění požadavku. Pravidlo může mluvit o všech registracích, konkrétní příklad však ukáže jeho výklad: při jedenácti obsazených místech z dvanácti se další účastník ještě může přihlásit.

Při rozhovoru oddělte pravidla, příklady a nezodpovězené otázky. Takto s nimi pracuje také metoda Example Mapping v dokumentaci Cucumber. Užitečné je přidat i seznam odložených témat, aby všichni viděli hranice aktuálního zadání.

Doporučeným výstupem je krátký záznam u požadavku: schválená kritéria, příklady, otevřené otázky a rozhodnutí o rozsahu. Zvlášť označte návrh testera a potvrzené byznys pravidlo. Tester dokáže odhalit nejasnost, ale bez pověření nerozhoduje, komu má firma umožnit registraci.

Modelový příklad: registrace na poslední místo

Následující příklad je vymyšlené zadání. Čísla a pravidla slouží k vysvětlení postupu, nikoli jako doporučené nastavení každého rezervačního systému.

Požadavek R-17: „Přihlášený uživatel se může zaregistrovat na otevřený workshop, pokud je volné místo. Počet potvrzených registrací nesmí překročit kapacitu.“ Po rozhovoru tým doplní, že jeden účet může mít na stejném workshopu pouze jednu platnou registraci. Čekací listina a e-mailové notifikace jsou mimo tento požadavek.

Z K1 vznikne scénář S-17-1. Předpokladem je otevřená registrace, kapacita 12, přesně 11 potvrzených účastníků a přihlášený účet, který mezi nimi není. Akcí je odeslání registrace. Očekávaným výsledkem je potvrzený stav u tohoto účtu, jeho jediný záznam v seznamu organizátora a celkový počet 12.

Takové členění odpovídá zápisu Given–When–Then: výchozí stav, událost a očekávaný výsledek. Dokumentace Gherkin doporučuje výsledek ověřovat na pozorovatelném výstupu. K dohodě však stačí běžný text nebo tabulka; zavedení konkrétního nástroje není podmínkou.

K2 až K4 potřebují vlastní scénáře. Dva postupné pokusy nenahrazují souběžný pokus z K4. Tester s vývojářem musí dohodnout způsob, jak vytvoří souběh a rozliší výsledky obou účtů. Pokud test ověřil pouze poslední místo pro jednoho uživatele, kritérium souběhu zůstává neověřené.

Co bude důkazem provedeného testu

Scénář popisuje očekávání; výsledek běhu zaznamenává, co se skutečně stalo. U S-17-1 má být dohledatelné označení požadavku a kritéria, verze scénáře, testovaná verze aplikace, prostředí, použité účty a výchozí obsazenost. K tomu patří skutečné výsledky jednotlivých ověření a celkový stav běhu.

Přiměřeným důkazem může být záznam potvrzené registrace dostupný v účtu uživatele a odpovídající seznam organizátora. Technická kontrola může výsledek číst také přes dohodnuté API, tedy rozhraní, kterým komunikují programy. Způsob ověření má odpovídat kritériu; samotná úspěšná odpověď serveru ještě nepotvrzuje správný počet účastníků.

Snímek potvrzení pomůže při kontrole zobrazení, ale sám neprokáže, že nevznikla duplicita. Stejně tak nestačí souhrn „test prošel“, pokud z něj nelze zjistit, které podmínky skutečně ověřoval. Rozsah a podobu důkazů dohodněte podle potřeby projektu, nikoli podle všeho, co testovací nástroj dokáže vyprodukovat.

Co schvaluje klient a co řeší technický tým

Klient nebo pověřený product owner schvaluje zamýšlené chování, příklady a hranice rozsahu. V našem příkladu potvrdí, že rozhoduje účet uživatele, opakováním nevzniká další registrace a čekací listina zatím nevznikne. Zároveň určí, kdo odpoví na otázky nebo schválí pozdější změnu pravidla.

Technický tým odpovídá za proveditelný postup, přípravu dat a přiměřená ověření. Klient nemusí schvalovat každý selektor, tedy pravidlo pro vyhledání prvku na webu. Má však rozumět tomu, co výsledek testu potvrzuje a co zůstalo mimo kontrolu. Schválení scénáře před implementací také není automatickým přijetím hotové funkce.

AI má zachovat schválený význam scénáře

Při tvorbě testu pomocí umělé inteligence (AI) zůstává schválený slovní popis podkladem ke kontrole. AI může navrhnout kód, doplňující otázky nebo opravu technického kroku. Nemá měnit vstupy, postup či očekávané výsledky jen proto, aby test prošel.

Pokud selže ověření dvanácti registrací, nahrazení přesného počtu podmínkou „seznam není prázdný“ oslabí kritérium. Vynechání kontroly duplicity zase odstraní část dohodnutého chování. Oprava selektoru může zachovat význam, i při ní však člověk prověří, zda test stále pracuje se správným prvkem a účtem.

Změnu významu musí schválit oprávněný člověk a má se promítnout do požadavku, kritéria i scénáře. Při kontrole porovnávejte slovní popis se skutečnými kroky a ověřeními. Zelený výsledek je použitelný až ve spojení s tím, co test provedl.

Co tím získáte a kde zůstávají hranice

Propojení požadavek → kritérium → scénář → důkaz umožní při neshodě najít konkrétní pravidlo a odpovědnou osobu. Analytik dokáže ukázat nevyřešené otázky, tester chybějící ověření a klient rozsah, který přijímá. Při změně kapacity nebo pravidel účtů se snáze dohledají dotčené testy.

Ani důkladně zpracovaná registrace nepokrývá celý produkt. Bezpečnost, accessibility či chování při velké zátěži mohou potřebovat další požadavky a samostatné ověření. Jejich priority patří do širší testovací strategie.

První krok u vašeho požadavku

Vyberte jednu důležitou uživatelskou činnost a dopište k ní úspěšný příklad, hraniční případ a chybový tok. U každého určete vstupy, předpoklady, výsledek a způsob jeho ověření. Nejasnosti přidělte konkrétnímu rozhodovateli. Takový podklad umožní dohodnout rozsah práce i tehdy, když zatím nemáte jediný automatizovaný test.