O tom, že testování je nesmírně důležitou částí každého nového nebo rozvojového projektu v IT, dneska nepochybuje pravděpodobně nikdo. Jak by ale mělo takové testování konkrétně probíhat pro zaručení maximálního efektu s minimalizací chybovosti vašeho digitálního projektu, se s vámi rádi podělíme na základě více než dvacetiletých zkušeností u nás v SiteOne.

Testování QA specialistou

Závěry nových projektů bývají hektické a testeři nebo QA Specialisté v nich hrají hlavní roli. Právě oni mají na starosti finální výstup – právě oni tak kontrolují, že všechny ty ideje, funkcionality, use cases a uživatelské cesty jsou v konečném produktu přesně v takové podobě a použitelnosti, v jaké být mají – proto je důležité QA specialisty zapojovat již v úvodních fázích projektů. Čím víc do detailů projekt nebo záměr za ním znají, tím komplexněji dovedou kontrolovat jednotlivé scénáře.

A právě oni jsou tak mnohdy posledním nárazníkem před tím, že by vaše značka mohla nepovedeným projektem schytat negativní ohlasy nebo dokonce ránu v reputaci.

Tým QA specialistů v SiteOne jednotlivé projekty testuje na beta prostředí, předprodukčním prostředí i po uvedení do produkce. A to hned v několika úrovních:

a) manuální testování

b) automatizované End-to-end testování

c) vizuálně regresní testování


Manuální testování

Srdce práce QA specialisty spočívá v neustálém kontaktu s jednotlivými projekty, především před jejich nasazením do produkce. Naši testeři tak kontrolují uživatelské rozhraní (UI), vykreslování obsahu, funkčnosti podle testovacích scénářů definovaných jednotlivými use cases, nebo responzivitu - kompatibilitu s plejádou prohlížečů na větších obrazovkách i mobilních zařízeních.

Součástí finálního testování projektu je také kontrola, jejíž postup je definovaný naším interním „Checklistem kvalitního webu“ – souborem bezmála stovky vlastností a parametrů z oblastí výkonu, zabezpečení, SEO, měřících nástrojů a mnohých dalších. Část z těchto položek kontroluje také hlavní backendový a frontendový vývojář daného projektu.

Zároveň při každém updatu projektu prochází sadu testovacích scénářů pro všechny důležité use cases webu nebo aplikace. A to i v případě, že se konkrétního use case update vůbec netýkal. Vždycky tak máme jistotu, že návštěvník na webu nalezne jen to, co tam nalézt má.

Automatizované End-to-end testování (E2E)

E2E testování si lze představit jako naprogramovaného JacaScriptového robota, který přebírá kus práce QA specialisty, alespoň v oblastech pevně definovaných testovacích scénářů.

Typicky – takovému botovi (pro E2E testování používáme nástroj Cypress) „vysvětlíme“, jakým způsobem se má po stránkách nebo třeba po jednotlivých obsahových blocích stránky pohybovat a kontrolovat jejich funkčnost tak, jako je používá i návštěvník webu – ať už jde o proklikávání odkazu, formulář callbacku, nebo třeba použití vyhledávání či kalkulačky. Bot pak buď úspěšně projde celým popsaným procesem, nebo nám reportuje chybu, kterou QA specialista ručně zkontroluje.

Velkou výhodou je, že E2E testy můžeme spouštět pravidelně, třeba každý den. Tím si můžeme kontinuálně ověřovat, že nedošlo k žádným odchylkám funkčností od normálu, i třeba těm způsobených například výpadkem externí služby, na kterou nemá projekt samotný vliv.

Nevýhodou takového typu testování je nejen určitá vstupní investice, ale především nutnost E2E testy aktualizovat pokaždé, kdy se v projektu změní use case nebo cesta k němu. 

Vizuálně regresní testování (VRT)

VRT testování slouží k tomu, abychom zabránili nechtěným změnám aplikace, co se týče její vizuální formy. Proto tento typ testingu používáme především před a po releasu projektu nebo jeho aktualizace.

VRT testy spočívají v tom, že nám náš nástroj (používáme na míru našim potřebám upravený BackStop.js) vytváří snapshoty dvou verzí stránek – verze, kterou testujeme, a verze referenční, jakési kontrolní baseline snapshotů toho, jak by měl projekt vypadat. Pokud nástroj, který porovnává pixel po pixelu, zaznamená jakoukoliv změnu v testované verzi oproti baseline, v reportu nás o těchto změnách informuje.

Máme tak vždycky přehled o tom, jestli jsme si úpravou ve funkcionalitách či stylech na jednom místě nezasáhli i někam, kam jsme zasáhnout nechtěli.

Penetrační a zátěžové testování

Penetrační a zátěžové testování v SiteOne děláme před uvedením velkých projektů do produkce. Tyto typy testů nespadají přímo do gesce našeho QA oddělení, mají je na starosti naši speciálně školení seniorní bezpečnostní a výkonnostní analytici.

Jejich práce v takovém případě spočívá v poměrně zábavném procesu – snaží se naše řešení zbořit. A to ať už z pohledu simulace ohromné návštěvnické zátěže aplikace, serveru, databází a dalších klíčových prvků struktury (zátěžový test), nebo coby „white hat hacker“, kdy zkouší simulovat jednotlivé typy útoků na části projektu s potenciální zranitelností. Při penetračním testování se tak snažíme odhalit jakýkoliv bezpečnostní nedostatek řešení.

Uživatelské testování

Někdy si při testování pomáháme i zvenčí. A děláme to rádi – tvorba webů a aplikací je jedna z mála oblastí lidské činnosti, kde je testování na lidech vítaným a někdy dokonce i nutným krokem, pokud chcete mít skvěle odladěné UI.

Uživatelská testování si děláme kompletně inhouse, nejčastěji na wireframovém nebo designovém prototypu projektu, na kterém pracujeme. Tento typ testingu zvládáme i on-line, ale fyzický kontakt je pro takovou aktivitu mnohem vítanější variantou.

V přípravné části vytváříme sady testovacích scénářů, které vycházejí z jednotlivých use case a uživatelských cest projektu. Ze sady pak vybíráme jednotlivé položky do unikátního testovacího scénáře pro každý testovací subjekt (subjekty jsou uživatelé, kteří ideálně vycházejí z definovaných cílových skupin projektu). A to tak, abychom každý bod sady scénářů otestovali alespoň 4x. Většinou k tomu potřebujeme zhruba 12 testovacích subjektů.

Samotným testováním jednotlivé uživatele provází moderátor, který je důkladně seznámený nejen s jednotlivými scénáři, ale také s projektem samotným. Moderátor podle scénářů s uživatelem prochází prototyp, zjišťuje přitom jeho dojmy, potenciální překvapení či nástrahy, s nimiž se musí potýkat. Na závěr si pak s testovacím subjektem projde sadu softových dotazů, z nichž vyhodnocujeme jednotlivé aspekty projektu.

Není tedy testing, jako testing

Chtěli jsme vám tímto článkem přiblížit, že poslední a zároveň velmi důležitá součást digitalizačního projektu je opravdu komplexním souborem mnoha na sebe navazujících nebo se prolínajících aktivit, do kterých je zahrnuto spoustu specialistů.

Samozřejmě tomu tak není všude, proto byste se při zadávání poptávky měli informovat i na tuto složku, jak daná agentura postupuje v rámci testování a jakým softwarem disponuje.

U nás v SiteOn to děláme takto a máme díky této propracované metodě své dlouholeté spokojené zákazníky, kteří se nemusí cítit ohroženi ať už bezpečnostními nebo uživatelskými nedostatky svých digitálních řešení na míru.

Chcete také svůj dokonalý digitální projekt realizovat s profesionály v oboru? Obraťte se na nás.