Automatizace SIT testů při vývoji a nasazování správce souhlasů na webové platformy nadnárodní společnosti

S příchodem GDPR stál klient (nadnárodní společnost z oblasti automotive, která přímo či nepřímo zodpovídá za desítky webových portálů v řadě zemí světa) před nutností nasadit odpovídající řešení pro správu souhlasů návštěvníků dle jednotlivých typů cookies.

Na udělené souhlasy s jednotlivými typy cookies se pak váže spuštění webové analytiky, případně její omezené verze atp.

Pokud by tento takzvaný „consent manager" nebyl nasazen, případně by nefungoval správně, hrozily by klientovi výrazné finanční sankce.

O čem to bude

• Jak to začalo 
• Co jsme řešili 
• S čím jsme testovali 
• Jak to dopadlo

Jak to začalo

U tohoto projektu jsme dostali na starost vytvořit automatizované SIT testy v rozsahu scénářů, které byly diskutovány s product ownerem a business analytikem. Nicméně během vývoje a následného procesu nasazování prošly testy samotné i spolu se svou architekturou poměrně dynamickým a zásadním vývojem. Klient se před začátkem projektu rozhodl pro následující řešení:

• Samotný consent manager, jeho technickou podporu a rozvoj dodala externí společnost jako již hotový produkt splňující všechny požadavky klienta 
• Consent manager bylo nicméně nutno integrovat do systémů klienta - zejména se samotnými weby a také systémem pro webovou analytiku 
• Zároveň bylo nutné managera vzhledově upravit tak, aby odpovídal vizuálnímu stylu klienta

Co jsme řešili 

Prvotním záměrem bylo testy využívat během vývoje. Na tento cíl byla taky jejich architektura a obsluha (způsob spouštění, reporting, atp.) designována. Po dokončení vývoje ale přišel požadavek, aby byly testy používány na každém nasazení. Zjednodušeně řečeno bylo pro každý připravovaný release na dalším webu/trhu třeba řešení otestovat před spuštěním a poté po spuštění na produkci. To znamenalo úpravu testů a jejich parametrizaci přes příkazovou řádku.

Po čase následovala další změna, kdy se rozhodlo, že release nebude probíhat jenom pro jeden web/trh, ale bude prováděn hromadně, například po pěti webech, respektive trzích. V tuto chvíli už nebylo reálné nějak rozumně testy, které jsou silně parametrizované, spouštět ručně přes příkazovou řádku, ale bylo potřeba urychleně vytvořit a začít používat CI server.

Nakonec jsme testování vyladili do stavu, kdy se pro každý nasazovaný web, respektive trh, na CI vytvoří parametrizovaný testovací job. Tyto joby běží na testovacím prostředí. Po nasazení na produkci pak klon testovacího jobu s lehce odlišnou konfigurací obsluhuje testy pro daný web na produkci.

S čím jsme testovali 

Protože téměř veškerý vývoj probíhá v JavaScriptu, byla z naší strany snaha nalézt vhodný testovací framework v tomto jazyce. Framework také musel být schopen přímo poskytnout či zprostředkovat interakci s webem, datovou vrstvou a se sítovou komunikací browseru.

Nakonec jsme zvolili webdriver.io. Jde o velice robustní JavaScriptový framework, který integruje Selenium - interakce s webem, Puppeteer (umožní zachytávání síťového provozu browseru). Nabízí metody pro snadný přístup k objektům okna browseru (datová vrstva). A v neposlední řadě podporuje Page Object Pattern při tvorbě testů, který v tomto projektu využíváme.

CI server je Jenkins, jeho instanci máme zprovozněnu na Google Cloud Platform. O reportování se stará Allure plugin v Jenkinsu.

Jak to dopadlo 

Consent manažer byl úspěšně integrován do systémů klienta a v současnosti probíhá již několik měsíců nasazování na weby napříč trhy, kde klient působí.