Aplikace vytvořená s pomocí AI: co prověřit před prvním releasem
AI vám pomohla vytvořit webovou aplikaci, přihlášení funguje a hlavní formulář lze odeslat. Před prvními zákazníky však potřebujete vědět, zda aplikace správně dokončí jejich práci, zachová data a oddělí přístup jednotlivých účtů. Tento postup je určen zakladateli nebo malému týmu, který má funkční prototyp a potřebuje srozumitelné podklady pro rozhodnutí o prvním release.
Co úspěšná ukázka ještě nepotvrzuje
Při ukázce obvykle používáte připravený účet, platné údaje a pořadí kroků, které znáte. Zákazník může formulář odeslat dvakrát, vrátit se k rozpracovanému úkolu nebo otevřít odkaz ze starého e-mailu. Právě přechody mezi obrazovkami, uloženými daty a externími službami potřebují samostatné ověření.
Původ kódu sám o sobě neurčuje jeho kvalitu. Při rychlém vývoji s AI je však užitečné sepsat pravidla produktu mimo konverzaci s asistentem: kdo smí co udělat, co se má uložit a co se má stát při chybě. GitHub u generovaných návrhů upozorňuje na možný nesoulad se záměrem vývojáře a doporučuje kontrolu i testování kódu. Dokumentace GitHub Copilot.
Vysvětlení AI, že funkci opravila, berte jako popis změny. Výsledek potvrďte opakováním původního scénáře a kontrolou jeho očekávaného výsledku. Jinak může zůstat bez povšimnutí, že zmizela chybová hláška, ale nesprávné ukládání dat pokračuje.
Modelový příklad: rezervace termínu v malém studiu
Představme si web, přes který zákazník rezervuje konzultaci. Má vlastní účet, vybere volný termín, dostane potvrzení e-mailem a později může rezervaci zrušit. Pracovník studia spravuje termíny a vidí rezervace zákazníků. Jde o modelový příklad pro vysvětlení postupu, nikoli o výsledky konkrétního projektu.
Před testováním dohodněte pravidla: jeden termín přijímá jednu rezervaci, zákazník vidí pouze své záznamy a zrušení termín opět uvolní. Při nedostupném e-mailu má rezervace zůstat uložená a tým má vědět o neodeslaném potvrzení. Pokud se vaše pravidla liší, upravte očekávání ještě před kontrolou.
Připravte dva zákaznické účty, účet pracovníka a několik zkušebních termínů. Použijte oddělené testovací prostředí a e-mailové adresy pod kontrolou týmu. Zapište verzi aplikace a nastavení integrací, aby bylo možné nález později zopakovat.
Projděte celou uživatelskou cestu
Začněte odkazem, který dostane nový uživatel, a pokračujte až k dokončenému výsledku. U rezervace to znamená registraci, přihlášení, výběr termínu, potvrzení a opětovné otevření rezervace. Ověřte také odhlášení, další přihlášení a zrušení termínu. V každém kroku sledujte, zda uživatel rozumí aktuálnímu stavu a dokáže pokračovat.
Přihlášení vyzkoušejte s nesprávným heslem i po vypršení přihlašovací relace, tedy období, během kterého systém považuje uživatele za přihlášeného. Rozpracovaný formulář nesmí vyvolávat dojem úspěšného uložení, pokud server požadavek odmítl. Pokud produkt nabízí obnovu hesla, ověřte celý postup včetně použití odkazu z e-mailu.
Ke každému scénáři zapište vstupní podmínky, kroky a očekávaný výsledek. „Rezervace funguje“ nahraďte ověřitelným popisem: vznikne jeden záznam se správným zákazníkem a termínem, je viditelný v účtu a pracovník ho najde ve svém seznamu. Takový zápis lze použít při ruční kontrole i automatizaci.
Ověřte data také po obnovení stránky
Hlášení „Uloženo“ samo nepotvrzuje, že se změna dostala do trvalého úložiště. Obnovte stránku, odhlaste se a rezervaci otevřete znovu. Porovnejte termín, zákazníka, stav a časové údaje. Následně zkontrolujte tentýž záznam z účtu pracovníka. Pokud se výsledky liší, je třeba prověřit načítání i ukládání dat.
Vyzkoušejte úpravu záznamu, zrušení a opakované odeslání formuláře. Dvě karty prohlížeče nebo dva účty mohou současně rezervovat stejný termín. Podle pravidel modelového produktu má uspět pouze jedna rezervace a druhý uživatel má dostat srozumitelné vysvětlení. Nestačí, že se obsazený termín skryje až po obnovení stránky.
U nálezu uveďte identifikátor rezervace, čas pokusu a oba výsledky. Člověk, který kontroluje server nebo databázi, pak může dohledat konkrétní operaci. Do záznamu chyby vkládejte zkušební údaje, abyste při sdílení nemuseli zpřístupňovat údaje zákazníků.
Oprávnění musí platit také na serveru
Skryté tlačítko administrace není důkazem zamítnutého přístupu. Oprávnění je třeba vynucovat na serveru při každém požadavku na chráněný údaj nebo operaci. OWASP výslovně upozorňuje, že kontrola pouze v prohlížeči nesmí rozhodovat o povolení přístupu. OWASP Authorization Cheat Sheet.
V modelové aplikaci vytvořte rezervaci účtem A a zkuste ji otevřít účtem B přes přímý odkaz. Prověřte čtení i změnu a zrušení. Stejná pravidla musí platit při přímém požadavku na API, tedy rozhraní, přes které web komunikuje se serverem. Tuto část svěřte člověku, který dokáže požadavek připravit a vyhodnotit.
Zkontrolujte také nepřihlášeného návštěvníka a běžný účet při operacích pracovníka. Výsledkem má být odmítnutí operace bez zpřístupnění cizího záznamu nebo jeho změny. Funkční kontroly oprávnění pomáhají ověřit pravidla produktu; nenahrazují bezpečnostní audit aplikace a její infrastruktury. Potřebný rozsah bezpečnostního posouzení závisí také na zpracovávaných údajích a způsobu nasazení.
Chybové stavy a integrace zkoušejte záměrně
Ověřte prázdné povinné pole, neplatný e-mail, již obsazený termín a přerušené spojení při odesílání. Sledujte nejen hlášku, ale také to, co zůstalo uložené a zda uživatel může pokus rozumně zopakovat. Při nejistém výsledku po výpadku nemá další kliknutí vytvořit druhou rezervaci téže operace.
U e-mailové služby rozlišujte uložení rezervace, předání zprávy poskytovateli a její doručení do zkušební schránky. Potom připravte případ, kdy služba požadavek odmítne nebo neodpoví v očekávaném čase. Podle dohodnutých pravidel ověřte stav rezervace i informaci pro tým. Pokud aplikace přijímá zpětná oznámení služby, vyzkoušejte také opakované doručení téhož oznámení.
Některé odpovědi lze nasimulovat náhradou služby, označovanou jako mock. Reálné napojení však prověřte také v testovacím prostředí poskytovatele, pokud ho nabízí. Rozdíly a omezení rozebírá článek mock, sandbox nebo reálná služba. Testovací e-maily směrujte do vlastních schránek a během kontrol nevytvářejte skutečné zákaznické rezervace.
Vyzkoušejte zařízení a způsob ovládání zákazníka
Hlavní cestu projděte na mobilu i počítači a v prohlížečích, které chcete podporovat. Na menší obrazovce sledujte překrytá tlačítka, výběr data a chybové hlášky. Zkuste formulář ovládat klávesnicí: uživatel má dokázat sledovat aktivní prvek, vyplnit pole a dokončit rezervaci. Tyto základní kontroly accessibility doplňují funkční testování; samy nepotvrzují celkovou přístupnost webu.
Vytvořte opakovatelné minimum před releasem
První sadu sestavte z již pochopených scénářů. Zachovejte zápis kroků i očekávání a automatizujte především kontroly, které budete opakovat po dalších změnách. Pro modelový produkt jsou vhodným základem:
- přihlášení a vytvoření jedné rezervace;
- ověření uloženého záznamu po novém načtení;
- odmítnutí přístupu druhého zákazníka;
- zrušení rezervace a uvolnění termínu;
- opakované odeslání a selhání e-mailové služby.
Každý automatizovaný test připravte s vlastními daty a známým počátečním stavem. Nemá záviset na rezervaci vytvořené předchozím testem. Nezávislost testů doporučuje také dokumentace Playwrightu, protože usnadňuje opakování a diagnostiku selhání.
Část kontrol může procházet webem, další ověří pravidla přímo přes API. Výběr rozebírá pořadí prvních automatizovaných scénářů. Sadu spouštějte stejným postupem a ukládejte výsledek spolu s verzí aplikace. Ke každé opravené důležité chybě přidejte kontrolu, která ověří také původní chybnou situaci.
Co má první release zastavit
Priority dohodněte podle důsledku pro uživatele a možnosti obnovy. Pro modelovou aplikaci může rozhodování vypadat takto:
| Nález | Navrhované rozhodnutí |
|---|---|
| Cizí účet otevře nebo změní rezervaci | Zastavit release a opravu znovu ověřit. |
| Rezervace se ztratí nebo vznikne dvojí obsazení | Zastavit release, prověřit také uložená data. |
| Potvrzení se neodešle, rezervace zůstane správná | Posoudit náhradní postup a dopad na zákazníka. |
| Menší vizuální odchylka bez omezení ovládání | Lze odložit s vlastníkem a termínem opravy. |
Rozhodujte podle výsledků, které dokážete zopakovat
Před nasazením sepište, co prošlo, co selhalo a co zůstalo mimo rozsah. Určete člověka odpovědného za rozhodnutí i za kontrolu po nasazení. Připravte postup při problému včetně obnovy dat; samotný návrat staršího kódu nemusí napravit nesprávně uložené záznamy.
Takto získáte konkrétní obraz připravenosti aplikace a základ pro další releasy. Nejbližším krokem je vybrat jednu hlavní uživatelskou cestu, dopsat její pravidla a projít ji se dvěma oddělenými účty. Zjištění ukážou, které opravy a automatické kontroly mají dostat přednost.