Na eWay-CRM soustavně pracuje celý tým vývojářů. Jak se vlastně podobný systém „vyrábí“?
O tom, co všechno děláme pro to, aby naši laboratoř opouštěl kvalitní software, se rozpovídal Roman Štefko, technický ředitel eWay-CRM.

Romane, jak se vlastně staráme o to, aby eWay-CRM fungovala, jak má?

Jako každý software, i naše eWay-CRM vzniká zápisem programu v programovacím jazyce, neboli kódováním. Jedná se o dnes již velice obsáhlý produkt, který tvoří dlouhý a složitý kód.

A když se vyvíjí kód, vznikají při tom chyby, které je zapotřebí najít a opravit.
U nového produktu vždy vzniká chyb méně. Často na něm také pracuje třeba jediný programátor, který si lépe pamatuje, co do kódu kdy napsal. Čím je však produkt starší, tím komplexnější je jeho kód. A tím také vzniká více chyb.
Vývojář po sobě hned všechno testuje, ale to nestačí. Možností, co by se mohlo pokazit, je mnoho. Některé testovací scénáře ho ani při vývoji nemusí napadnout, protože v tu chvíli je ovlivněn samotným psaním kódu.

A od toho máme testera, že?

Hledání chyb je skutečně z části práce takzvaného testera. Tester testuje software z uživatelského hlediska, jinak řečeno – zda to, na čem vývojář pracoval, funguje tak jak by mělo. A zda to negeneruje nějaké chyby.
Když jsme například vyvinuli náš nejnovější modul Úkoly, tester postupně vyzkoušel všechny jeho funkce.
Ani tester však nemůže stihnout vše sledovat. V praxi by to znamenalo, že by po každé malé změně prošel úplně celý systém a otestoval všechny funkcionality.
A proto v eWay-CRM používáme unit testy.

Unit testy? Co to znamená?

Jedná se o automatizované testy, které umí ověřit kód a jeho funkčnost. „Unit test“ se mu říká podle toho, že se ověřuje samostatně testovatelná část programu, tedy jednotka neboli unit. Tyto testy u nás píší sami programátoři.

Unit test funguje následovně:

1. Napíšeme si testovací případy a nadefinujeme tak, co se má v konkrétním případě stát. Pro každý testovací případ vytvoříme unit test, což je takový malý kousek zdrojového kódu, které mají za úkol zkontrolovat jednotlivé části hlavního zdrojového kódu aplikace. Pro jednu část hlavního zdrojového kódu můžeme mít klidně i víc unit testů, protože ji chceme otestovat na mnoho různých scénářů. To není vůbec na škodu. Naopak.
2. Unit testy připravíme, uděláme tedy takový snapshot v konkrétním čase a tak v budoucnu snadno zjistíme, zda po úpravách kódu nedošlo k požkození nějaké části programu.

Jak často se do něčeho takového pouštíme?

Unit testy pouštíme každý večer a jsme tak schopni projít stovky možných scénářů.
Tohle všechno by testerovi zabralo neuvěřitelné množství času, ale s automatickými testy je to otázka několika minut. Živý tester a automatické testy se skvěle doplňují. Například když jsme vyvinuli nový modul Úkoly, tester ho testoval z uživatelského hlediska a zkoumal, zda se chová dle očekávání.
To je jiný typ testování, nejedná se o procházení funkčnosti celého systému jako v případě unit testů, ale o zaměření na nově vyvinutou funkcionalitu. Automatický test nám například neřekne, že něco nevypadá hezky.
Metodou unit testů jsme schopni odhalit všechny nevědomé chyby, které vyvolaly úpravy systému. Vývojář zjistí, že jeho akce vyvolala chybu v úplně jiné části našeho software a na základě toho může třeba ještě v zárodku podchytit špatný postup implementace řešení.
Také si hlídáme, jak moc jsou jednotlivé části kódu pokryty testy. Pokrytí se nám zobrazuje v procentech. V detailu pak můžeme i konkrétně zjistit, která část pokryta není.
Zkrátka s testy pracujeme skutečně do hloubky.

Takové důkladné testování asi zabírá spoustu času. Vyplatí se to vůbec?

eWay-CRM je veliký a komplexní produkt. Pracujeme na něm více než 10 let a vystřídaly se na něm desítky vývojářů. Samotný náš kód má asi 376 862 řádků. To je více než desetkrát delší text, než třeba taková Bible! Takový systém už není nikdo schopen udržet v hlavě. Proto jsme se v poslední době začali na testy více zaměřovat a píšeme jich čím dál tím více.
Psaní testů je ovšem něco „navíc“. Nyní kromě vývoje nové funkce trávíme čas ještě náročnějším testováním. Náklady na vývoj i sebemenší funkce se ze začátku mohou díky tvorbě unit testů i zněkolikanásobit, ukazuje se však, že z dlouhodobého hlediska se to velmi vyplácí.
Dříve jsme se o některých zásadních chybách dozvídali se zpožděním. Když si tedy představíme, že jsme na nové verzi pracovali tři měsíce, za další měsíc se pak dostala ke klientovi a ten si po dalším měsíci všiml nějaké chyby, dostali jsme se do situace, kdy jsme museli znovu začít řešit takto starý kód. Tedy bylo potřeba přijít s rychlou a efektivní nápravou kódu, která nenapáchá jiné škody, zatímco jsme již dávno pracovali na něčem jiném.

Nakonec jsme tedy po těch několika měsících museli plno času vynaložit na opravu, analýzu, novou verzi, aktualizaci. To na produkt vrhá špatné světlo a není to vůbec levná záležitost.
Nyní jsme díky unit testům schopni celou věc podchytit už při vývoji a do světa posíláme mnohem kvalitnější software. Zaměření na důkladnější testování do určité míry zpomaluje vývoj našeho produktu, ale výsledky jsou vidět. Vývojáři si zvykli trávit testováním více času a efekt sami vidí. Testování hlídá jejich práci. A to opravdu pomáhá a počet chyb klesá.

Jsou v eWay-CRM tyhle testy novinkou?

Unit testy jsme dělali i dříve, nyní jsme se však do toho opřeli ještě víc. Zaměřujeme se na funkce s větším dosahem a rostoucí klientele chceme nabízet opravdu kvalitní produkt. Proto jsme si na testování vyčlenili dostatek času a prostředků.

Zaujala vás tématika vývoje eWay-CRM? Přečtěte si také rozhovor s Honzou Spilkou o kódování.
Možná vás zaujme také zpověď testera Martina Štefka, nebo třeba rozhovor s Romanem o bezpečnosti dat.