Testovanie web aplikácií

Aplikácia vytvorená s pomocou AI: čo preveriť pred prvým releasom

AI vám pomohla vytvoriť webovú aplikáciu, prihlásenie funguje a hlavný formulár sa dá odoslať. Pred prvými zákazníkmi však potrebujete vedieť, či aplikácia správne dokončí ich prácu, zachová dáta a oddelí prístup jednotlivých účtov. Tento postup je určený zakladateľovi alebo malému tímu, ktorý má funkčný prototyp a potrebuje zrozumiteľné podklady na rozhodnutie o prvom release.

Čo úspešná ukážka ešte nepotvrdzuje

Pri ukážke zvyčajne používate pripravený účet, platné údaje a poradie krokov, ktoré poznáte. Zákazník môže formulár odoslať dvakrát, vrátiť sa do rozpracovanej úlohy alebo otvoriť odkaz zo starého e-mailu. Práve prechody medzi obrazovkami, uloženými dátami a externými službami potrebujú samostatné overenie.

Pôvod kódu sám osebe neurčuje jeho kvalitu. Pri rýchlom vývoji s AI je však užitočné spísať pravidlá produktu mimo konverzácie s asistentom: kto smie čo urobiť, čo sa má uložiť a čo sa má stať pri chybe. GitHub pri generovaných návrhoch upozorňuje na možný nesúlad so zámerom vývojára a odporúča kontrolu aj testovanie kódu. Dokumentácia GitHub Copilot.

Vysvetlenie AI, že funkciu opravila, berte ako opis zmeny. Výsledok potvrďte opakovaním pôvodného scenára a kontrolou jeho očakávaného výsledku. Inak môže zostať nepovšimnuté, že zmizla chybová hláška, ale nesprávne uloženie dát pokračuje.

Modelový príklad: rezervácia termínu v malom štúdiu

Predstavme si web, cez ktorý zákazník rezervuje konzultáciu. Má vlastný účet, vyberie voľný termín, dostane potvrdenie e-mailom a neskôr môže rezerváciu zrušiť. Pracovník štúdia spravuje termíny a vidí rezervácie zákazníkov. Ide o modelový príklad na vysvetlenie postupu, nie o výsledky konkrétneho projektu.

Pred testovaním dohodnite pravidlá: jeden termín prijíma jednu rezerváciu, zákazník vidí iba svoje záznamy a zrušenie termín opäť uvoľní. Pri nedostupnom e-maile má rezervácia zostať uložená a tím má vedieť o neodoslanom potvrdení. Ak sa odlišujú vaše pravidlá, upravte očakávania ešte pred kontrolou.

Pripravte dva zákaznícke účty, účet pracovníka a niekoľko skúšobných termínov. Použite oddelené testovacie prostredie a e-mailové adresy pod kontrolou tímu. Zapíšte verziu aplikácie a nastavenie integrácií, aby sa dal nález neskôr zopakovať.

Prejdite celú používateľskú cestu

Začnite odkazom, ktorý dostane nový používateľ, a pokračujte až po dokončený výsledok. Pri rezervácii to znamená registráciu, prihlásenie, výber termínu, potvrdenie a opätovné otvorenie rezervácie. Overte aj odhlásenie, ďalšie prihlásenie a zrušenie termínu. Pri každom kroku sledujte, či používateľ rozumie aktuálnemu stavu a vie pokračovať.

Prihlásenie skúste s nesprávnym heslom aj po vypršaní prihlasovacej relácie, teda obdobia, počas ktorého systém používateľa považuje za prihláseného. Rozpracovaný formulár nesmie navodzovať dojem úspešného uloženia, ak server požiadavku odmietol. Ak produkt ponúka obnovu hesla, overte celý postup vrátane použitia odkazu z e-mailu.

Ku každému scenáru zapíšte vstupné podmienky, kroky a očakávaný výsledok. „Rezervácia funguje“ nahraďte overiteľným opisom: vznikne jeden záznam so správnym zákazníkom a termínom, je viditeľný v účte a pracovník ho nájde vo svojom zozname. Takýto zápis sa dá použiť pri ručnej kontrole aj automatizácii.

Overte dáta aj po obnovení stránky

Hlásenie „Uložené“ samo nepotvrdzuje, že sa zmena dostala do trvalého úložiska. Obnovte stránku, odhláste sa a rezerváciu otvorte znova. Porovnajte termín, zákazníka, stav a časové údaje. Následne skontrolujte ten istý záznam z účtu pracovníka. Ak sa výsledky líšia, treba preveriť načítanie aj uloženie dát.

Vyskúšajte úpravu záznamu, zrušenie a opakované odoslanie formulára. Dve karty prehliadača alebo dva účty môžu súčasne rezervovať rovnaký termín. Podľa pravidiel modelového produktu má uspieť iba jedna rezervácia a druhý používateľ má dostať zrozumiteľné vysvetlenie. Nestačí, že sa obsadený termín skryje až po obnovení stránky.

Pri náleze uveďte identifikátor rezervácie, čas pokusu a oba výsledky. Človek, ktorý kontroluje server alebo databázu, potom môže dohľadať konkrétnu operáciu. Do záznamu chyby vkladajte skúšobné údaje, aby ste pri zdieľaní nemuseli sprístupňovať údaje zákazníkov.

Oprávnenia musia platiť aj na serveri

Skryté tlačidlo administrácie nie je dôkazom zamietnutého prístupu. Oprávnenia treba vynucovať na serveri pri každej požiadavke na chránený údaj alebo operáciu. OWASP výslovne upozorňuje, že kontrola iba v prehliadači nesmie rozhodovať o povolení prístupu. OWASP Authorization Cheat Sheet.

V modelovej aplikácii vytvorte rezerváciu účtom A a skúste ju otvoriť účtom B cez priamy odkaz. Preverte čítanie aj zmenu a zrušenie. Rovnaké pravidlá musia platiť pri priamej požiadavke na API, teda rozhranie, cez ktoré web komunikuje so serverom. Túto časť zverte človeku, ktorý vie požiadavku pripraviť a vyhodnotiť.

Skontrolujte aj neprihláseného návštevníka a bežný účet pri operáciách pracovníka. Výsledkom má byť odmietnutie operácie bez sprístupnenia cudzieho záznamu alebo jeho zmeny. Funkčné kontroly oprávnení pomáhajú overiť pravidlá produktu; nenahrádzajú bezpečnostný audit aplikácie a jej infraštruktúry. Potrebný rozsah bezpečnostného posúdenia závisí aj od spracúvaných údajov a spôsobu nasadenia.

Chybové stavy a integrácie skúšajte zámerne

Overte prázdne povinné pole, neplatný e-mail, už obsadený termín a prerušené spojenie pri odoslaní. Sledujte nielen hlášku, ale aj to, čo zostalo uložené a či používateľ môže pokus rozumne zopakovať. Pri neistom výsledku po výpadku nemá ďalšie kliknutie vytvoriť druhú rezerváciu tej istej operácie.

Pri e-mailovej službe rozlíšte uloženie rezervácie, odovzdanie správy poskytovateľovi a jej doručenie do skúšobnej schránky. Potom pripravte prípad, keď služba požiadavku odmietne alebo neodpovie v očakávanom čase. Podľa dohodnutých pravidiel overte stav rezervácie aj informáciu pre tím. Ak aplikácia prijíma spätné oznámenia služby, skúste aj opakované doručenie toho istého oznámenia.

Niektoré odpovede možno nasimulovať náhradou služby, označovanou ako mock. Reálne napojenie však preverte aj v testovacom prostredí poskytovateľa, ak ho ponúka. Rozdiely a limity rozoberá článok mock, sandbox alebo reálna služba. Testovacie e-maily smerujte do vlastných schránok a počas kontrol nevytvárajte skutočné zákaznícke rezervácie.

Vyskúšajte zariadenie a spôsob ovládania zákazníka

Hlavnú cestu prejdite na mobile aj počítači a v prehliadačoch, ktoré chcete podporovať. Pri menšej obrazovke sledujte prekryté tlačidlá, výber dátumu a chybové hlášky. Skúste formulár ovládať klávesnicou: používateľ má vedieť sledovať aktívny prvok, vyplniť polia a dokončiť rezerváciu. Tieto základné kontroly accessibility dopĺňajú funkčné testovanie; samy nepotvrdzujú celkovú prístupnosť webu.

Vytvorte opakovateľné minimum pred releasom

Prvú sadu zostavte z už pochopených scenárov. Zachovajte zápis krokov aj očakávaní a automatizujte najmä kontroly, ktoré budete opakovať po ďalších zmenách. Pre modelový produkt sú vhodným základom:

• prihlásenie a vytvorenie jednej rezervácie;
• overenie uloženého záznamu po novom načítaní;
• odmietnutie prístupu druhého zákazníka;
• zrušenie rezervácie a uvoľnenie termínu;
• opakované odoslanie a zlyhanie e-mailovej služby.

Každý automatizovaný test pripravte s vlastnými dátami a známym počiatočným stavom. Nemá závisieť od rezervácie vytvorenej predchádzajúcim testom. Nezávislosť testov odporúča aj dokumentácia Playwrightu, pretože uľahčuje opakovanie a diagnostiku zlyhaní.

Časť kontrol môže prechádzať webom, ďalšie overia pravidlá priamo cez API. Výber rozoberá poradie prvých automatizovaných scenárov. Sadu spúšťajte rovnakým postupom a ukladajte výsledok spolu s verziou aplikácie. Ku každej opravenej dôležitej chybe pridajte kontrolu, ktorá overí aj pôvodnú chybnú situáciu.

Čo má prvý release zastaviť

Priority dohodnite podľa dôsledku pre používateľa a možnosti obnovy. Pre modelovú aplikáciu môže rozhodovanie vyzerať takto:

Rozhodujte podľa výsledkov, ktoré viete zopakovať

Pred nasadením spíšte, čo prešlo, čo zlyhalo a čo zostalo mimo rozsahu. Určte človeka zodpovedného za rozhodnutie aj za kontrolu po nasadení. Pripravte postup pri probléme vrátane obnovy dát; samotný návrat staršieho kódu nemusí napraviť nesprávne uložené záznamy.

Takto získate konkrétny obraz pripravenosti aplikácie a základ pre ďalšie releasy. Najbližším krokom je vybrať jednu hlavnú používateľskú cestu, dopísať jej pravidlá a prejsť ju s dvoma oddelenými účtami. Zistenia ukážu, ktoré opravy a automatické kontroly majú dostať prednosť.