Petr Hendl je v Shoptetu jedním z těch, kdo hlídají, aby se do produkce dostával důkladně otestovaný software. Vede QA tým, se kterým pracuje na začleňování dalších testů i na procesních výzvách. Co je podle něj nejdůležitější schopnost u testera a jaká byla cesta k tomu, že verifikační fáze je ve vývoji považována za standard?
Shoptet má dnes více než 25 000 klientů, kteří očekávají bezvýpadkový provoz. Některé úkoly, které růst firmy přináší pro IT, už v rozhovoru zmínil CTO Filip Kopecký. Stále důležitější roli má také tým QA. O tom, jak se v Shoptetu přistupuje k automatickým či manuálním testům a jaké jsou další plány, se rozpovídal šéf QA týmu Petr Hendl.
Jakou funkci má QA v Shoptetu?
QA se stará o to, aby jakákoliv změna software dostala do produkce až po ověření, že plní svoji funkci (product test) a nerozbila nic jiného (regression test). Jsme asi uprostřed toho, kde bychom chtěli být. Kdybych měl popsat cestu, tak když jsme před 3 lety začínali, bylo testování intuitivní a přímočaré, zběžně se kontrolovalo, že požadovaná změna funguje.
Od toho jsme se posunuli k systematickému procesu, který začíná test plány, datovými scénáři, produktovými testy a navazuje regresním release testem. Tím to ale nekončí. Chceme rozšiřovat pokrytí automatickými testy. Máme před sebou řadu potřebných vylepšení do infrastruktury testů a budeme zobecňovat a popisovat postupy testování. Bude to nutné, zákazníci vyžadují bezvýpadkový provoz a zároveň budeme zodpovídat za více projektů. Počet testerů bude výrazně narůstat.
Jsi u toho od začátku. Jaká byla největší výzva v přerodu „aby to fungovalo a nepadalo” až do situace, kdy víme, že máme důkladně otestováno?
První byla vůbec změna v procesu vývoje a doručování do produkce. Bylo potřeba prosadit změnu v myšlení u vývojářů a u produkťáků. Nejen, že produktové testy začaly zabírat více času, ale také jsme zavedli verifikační fázi před vlastním deploy do produkce. To, že programátor něco naprogramuje a řekne „mně to funguje”, najednou přestalo znamenat, že tím okamžikem se to zpřístupní v produkci. Bylo potřeba zavést proces a zvyknout si, že se vše vlastně formalizuje a zpomalí.
Dneska už se na to díváme jako na standard, víme, že ověřovací fáze tam je a i když zdržuje, má svůj účel. Odměny jsme se dočkali během několika týdnů až měsíců. Úplně na začátku jsme dennodenně odchytávali side efekty a nedotestovaný věci i v produkci. Dnes je to výjimka a výpadky, které by postihovaly klienty, jsou výrazně vzácnější. Nedá se jich ale úplně vyvarovat, systém je pod velkým náporem, dodáváme toho hodně. Nicméně jsme už úplně jinde než třeba před třemi lety.
Jak vypadá aktuální tým? Nejsou to jen automatičtí testeři, že?
Ne, obecně je to klišé, že automatické testy vše vyřeší. U nás platí o to víc, protože automatické testy jsme začali psát v momentě, kdy byl systém poměrně rozsáhlý a bylo by těžké automatickými testy dohnat úplně všechno. Navíc řada chyb, na které narážíme, jsou speciální kombinace, co postihnou pár e-shopů z těch pětadvaceti tisíc. Jde o hodně specifické situace, které těžko předpokládat a předem nasimulovat, takže je i nejlevnější to otestovat ručně.
Máme rozdělané věci, které se vyplatí automatizovat, a samozřejmě se snažíme, aby jich bylo co nejvíc. U API testů je to prakticky stoprocentní pokrytí, u testů, které jsou end to end a které testují uživatelské rozhraní, je pokrytí výrazně menší.
Část týmu dělá manuální testy, jsou to lidé, kteří výborně znají administraci a všechny kombinace, varianty nastavení. Ne náhodou jsou to lidé, kteří nastoupili z naší technické podpory. Druhá část týmu se soustředí na automatické testování. Vytipovávají funkce, které má smysl automatizovat, dále na denní bázi pouštíme automatické testy a rozšiřujeme, aby pokrývaly větší a větší část. Nejde všechno najednou, tak prioritně doplňujeme automatické testy pro věci, které ovlivňují nejvíce zákazníků. A dále oblasti, u kterých máme empiricky vyzkoušeno, že se tam chyby opakovaně projevují.
Kolik automatických testů aktuálně běží?
Automatických testů v oblasti API máme kolem 2500, v oblasti GUI pak kolem 400. Celková doba běhu automatických testů je přibližně čtyři hodiny (reálný čas je kratší, běží paralelně). API testy mají velké pokrytí, takže už dobře slouží jako pojistka. Když se v API něco mění a testy projdou, je vysoce pravděpodobné, že to funguje dobře a nic jsme nerozbili. U GUI testů máme spíše základní indikaci a je třeba ještě dotestovat ručně.
S jakými technologiemi aktuálně pracujete?
Máme stejné prostředí, jako mají naši vývojáři, které je založené na Vagrantu a Virtualboxu, a pro release testy máme staging prostředí. Tam máme zmenšenou kopii klíčových komponent produkčního prostředí, tam pouštíme manuální i automatické testy. Vlastní automaty jsou založené frameworku Codeception. Ten jsme zvolili, protože jsme to chtěli založit na PHP stejně jako zdrojový kód a protože nám to umožňuje mít jeden framework pro unit testy, integrační testy, API testy i end-to-end (acceptance) testy. Má navíc moduly pro řadu funkcí a nástrojů, které používáme. Ty end-to-end testy spouštíme přes Selenium a aktuálně je pouštíme jen proti Chrome. Jako obálka pro testy nám slouží Jenkins. Začínají ale i projekty založené na Reactu a koketujeme s Cypresem, takže nás čeká i JavaScript.
Bude v rámci technologií posun do budoucna?
Určitě. Řadu věcí umíme odhalit dřív, než mají šanci se projevit v produkci. K tomu testy slouží jako dobrý základ, když vývojáři dělají riskantnější změny, mohou si ověřit, že to v zásadě nerozbili. Máme základ, abychom mohli testy rozšiřovat, a myslím jak růst do šířky, kdy můžeme pokrývat další oblasti, tak i kvalitativní růst. Tam máme celou řadu dluhů a představ pro další rozvoj. Zmínil bych třeba užší začlenění do CI, snazší spouštění v rámci vývoje, začlenění dalších testů, jako je měření regresních performance, větší paralelizace běhu, lepší reprezentace výsledků. Řada věcí bude vázaná na další změny, které se dějí ve vývojovém prostředí vývojářů, přechod na GitLab, procesně přechod na Jiru nebo i větší podpora prostředí, aby se dalo dokerizovat, vytvářet paralelní prostředí.
Na Shoptetu běží více a více e-shopů, takže je logické, že tyhle změny přicházejí teď. Nese to s sebou potřebu obsluhovat více klientů, ale zároveň celý proces líp podchytit a rychleji vyvíjet. A když nechceme hazardovat s kvalitou kódu, potřebujeme udržovat, co máme rozjeté, opravovat chyby a doručovat funkce. A to je obtížná práce i se zkušenými lidmi, které se podařilo zejména v posledním roce nabrat. Momentálně hledáme i testery.
Proč by se měl tester přidat zrovna do tvého týmu?
Zmínil bych dvě věci, které mi přijdou důležité. V týmu je parta super lidí, kteří mají rádi svoji práci a dělají to s nasazením, ať umí to, či ono. A zatímco testují funkci sčítající 30miliardový obrat od 3,5 milionu nakupujících, tak vtipkují a pak spolu jdou na oběd.
A druhou věcí je, že teď máme takovou pěknou fázi. Už máme základ procesu testování i automatických testů, který je rozjetý, nezačíná se od nuly, a přitom je tu pořád ještě spousta tvůrčí práce a prostoru pro zlepšování.
Jakého testera teď hledáš, co se týče zkušeností?
Tím, jak rozvíjíme testování a proporcionálně potřebujeme posílit stavy vzhledem k přibývajícímu počtu vývojářů a projektů ve firmě, potřebujeme pokrývat manuální i automatické testy. Pro mě vždy bylo důležité, aby si člověk našel oblast, ve které se bude realizovat a bude ho bavit.
Přístup testera musí být proaktivní. To není o check listu, ale o intuici a o tom, aby upřel síly správným směrem a našel správné chyby nebo mezírky v kódu. Aby vždy myslel o kousek dál a jinak než vývojář. Tester musí být kombinace systematika i rebela. Člověk naslouchající instinktu, mít prst na tepu kódu. Musí být šťoural, ale umět dobře vyhodnotit chyby a komunikovat je s vývojáři. Aby tam nebyla nevraživost, ale spolupráce. Musí mít cit pro čas strávený testem a přínosem i riziky testované změny.
Co můžeš říct o týmu testerů?
Pro náš tým bylo v době, kdy jsme byli v kanceláři, příznačné, že kolem našeho pracovního ostrůvku jsme se hodně nasmáli. Děláme si rádi legraci, třeba i ze sebe. Teď se jednou týdně sejdeme online, zapneme si kamery. Tým spolu musí hodně komunikovat, takže je důležité i osobnostně si sednout, aby to pak fungovalo i pracovně. Kolikrát dáme hlavy dohromady a při testování rychle najdeme řešení nějaké chyby. Nebojí se mi říct ani to, že se jim třeba něco nelíbí.
Napsat komentář