Jak automatizovaně otestovat e-shop: od košíku po platbu
Automatizovaný test e-shopu projde vybranou nákupní cestu podobně jako zákazník: najde produkt, vloží ho do košíku, vyplní údaje a ověří výsledek objednávky. Takový end-to-end test neboli test celého procesu od začátku do konce pomáhá pravidelně kontrolovat kroky, na kterých závisejí objednávky a tržby. Je však důležité vybrat správné scénáře a nesnažit se ověřovat všechny kombinace přes uživatelské rozhraní.
Kde e-shopy nejčastěji ztrácejí jistotu
Před releasem je třeba zkontrolovat různé produkty, ceny, slevy, dopravu, platební metody i nákup přihlášeného a nepřihlášeného zákazníka. Při ručním testování se rozsah snadno mění podle toho, kolik času týmu zbývá. Okrajová kombinace se přeskočí a chyba se může projevit až u skutečné objednávky.
Rizikem není pouze nefunkční tlačítko. Košík může nesprávně přepočítat cenu, sleva se může uplatnit dvakrát nebo objednávka vznikne, přestože platba selhala. Část procesu navíc závisí na platební bráně, dopravci nebo e-mailové službě, proto jeden rozsáhlý test nemusí spolehlivě ukázat, kde problém vznikl.
Jak sestavit užitečné pokrytí
Začněte cestami s největším dopadem na zákazníka a tržby:
- Vyhledání produktu: vyhledávání, kategorie a dostupnost zboží.
- Košík: přidání a odebrání položky, změna množství, cena a sleva.
- Přihlášení nebo nákup bez registrace: podle toho, co e-shop podporuje.
- Checkout: povinné údaje, doprava, platba a srozumitelné chybové stavy.
- Dokončení objednávky: potvrzení na stránce a správný stav objednávky v systému.
Ne každá kombinace potřebuje samostatný test v prohlížeči. Výpočty cen, pravidla slev a řadu chybových stavů lze rychleji ověřit na úrovni API nebo aplikační logiky. Přes rozhraní pak stačí menší počet reprezentativních cest, které potvrdí, že jednotlivé části fungují společně.
Test si má připravit vlastní data, aby neselhal jen proto, že se produkt vyprodal nebo jiný test změnil stejnou objednávku. Platbu je vhodné zkoušet v testovacím režimu platební brány bez skutečného účtování. Pokud testy běží v CI/CD, tedy v procesu, který automaticky kontroluje změny kódu, dostane tým výsledek při dohodnutých událostech. Podle konfigurace může při chybě obdržet také snímek, video nebo podrobný záznam průběhu.
Na co si dát pozor
Testovací prostředí se může lišit od produkce a simulace platby nepotvrdí dostupnost ostré platební brány. Automatizované opakované kontroly má proto smysl doplnit bezpečně navrženým monitoringem nejdůležitějších cest v produkci. Produkční kontroly však nesmějí vytvářet skutečné platby, měnit zásoby ani pracovat s osobními údaji bez jasných pravidel.
Co tím získáte
- Stejné kritické cesty se ověří při každém dohodnutém běhu.
- Tým dříve zjistí, ve kterém kroku nákupu problém nastal.
- Ruční testování se může soustředit na nové funkce, použitelnost a neočekávané situace.
- Testy zůstanou v repozitáři a váš tým je může dále rozvíjet.
Další krok
Sepište si tři až pět nákupních cest, jejichž výpadek by měl největší dopad na zákazníky. Pokud chcete ověřit jejich vhodnost pro automatizaci, ozvěte se nám. Navrhneme první vrstvu testů i kontroly, které je výhodnější přesunout na API.