Co se změnilo na vývoji softwaru?
Vyvíjí váš tým SW produkt a ještě nemáte automatizované testy? Byly doby, kdy manuální testy byly naprosto běžné a kvalitu softwaru ve většině případů jinak ověřovat ani nešlo. To už ale neplatí. Svět se změnil. Ptáte se jak? Dříve trval vývojový cyklus běžně několik měsíců až let. Já sám jsem pracoval na projektu, kde se release dělal jednou za půl roku. To ale kalendář ukazoval rok 2002. Dnes v době agilního vývoje a continuous delivery se releasy dělají klidně každých 14 dní a v tomto tempu již není možné testovat manuálně. Tedy neznamená to, že manuální testování definitivně skončilo, rozhodně ne. Jen se objem testovaného SW jednoznačně přehoupl na stranu automatizovaných testů. Také možnosti, které dnes díky cloudu a internetovým projektům obecně máme, jsou úžasné. Většina moderních nástrojů pro vývoj a testování umožňuje integraci s ostatními, a tak se dá poměrně rychle sestavit skládačka obsahující automatické buildy, automatické testy, automatické reporty a propojení s requirementy a bugy. Proč to tedy nevyužít.
Proč je automatizace dnes nezbytná?
Aby to ale celé fungovalo jak švýcarské hodinky, je nutné mít automatizované testy. Ty šetří čas, odhalují bugy v dřívějších fázích a tedy snižují náklady (viz obr. č. 1 – více se dozvíte v tomto článku v kapitole Nevhodné místo pro automatizaci) a dělají testování zábavnější – protože nikdo nemá rád opakující se manuální rutinu. Díky automatizaci dochází i ke zpřesnění. Představte si, jak tester internetové aplikace musí vykonat 10 kroků konkrétního testu na všech prohlížečích a všech OS. Pravděpodobnost, že se někde splete nebo něco přehlédne, je obrovská. Jako vše, i automatizace testování má ovšem své temné stránky. Pokud nevíte jak správně ji vytvořit, nebo kde se má automatizovat a co se má automatizovat, můžete spálit stovky hodin effortu na automatizaci, která bude velmi nákladná na údržbu a nebude nacházet podstatné chyby. Spousta firem prostě neví jak automatizovat. Často říkám – napsat automatický test je jednoduché, těžké je vymyslet, co se má automatizovat 😃.
Jak tedy začít automatizovat?
Zavedení automatizace rozděluji na následující fáze. Jedná se o postupné kroky, jež pomohou tvorbu automatizace efektivně zpřehlednit.
- stanovit kde budeme automatizovat
- stanovit co budeme automatizovat
- vytvořit první automatizované testy
- nakonfigurovat stabilní testovací prostředí
Obr. č. 1 testing pyramida
Prvním krokem je stanovit místo kde se bude automaticky testovat (viz obr. č. 1 – testing pyramida). Tím místem mohou být automatické testy na API, back-end testy, testy jedné komponenty, nebo ještě lépe začněte s unit testy. Najít takové místo ale není tak snadné, jak se na začátku může zdát. Proto s touto fázi nespěchejte! Zkuste více míst a diskutuje vše uvnitř týmu. Čím níže z pohledu test pyramidy se vám podaří dostat, tím lépe pro budoucí práci. Pokud ale máte v rukou projekt o několika týmech, nic nebrání tomu začít paralelně na více úrovních (unit testy, integrační testy a funkční testy).
Pokud již máte místo, které je možné automatizovat, můžete se vrhnout na výběr co se bude automatizovat. Tím CO myslím, jaké testy vyberete. Ideální je začít od toho jednoduššího, co vám ukáže slabá místa na projektu. Tím nejjednoduším je začít automatizovat existující testy funkcionality. Je dobré vybrat takovou, která je klíčová pro zákazníka. Příklad: Pokud začínáte automatizovat back-endovou část svého serveru, jako první testy pro automatizaci můžete vybrat třeba autentizaci, ta se používá vždy a je tedy klíčová. Pokud je váš produkt velmi komplikovaný a nedaří se vám automatizaci realizovat, začněte s poloautomatickými testy – čili snažte si zautomatizovat činnosti, které při testování stále opakujete. Například přihlašování na testovací stroje, plnění DB testovacími daty, filtrování logů, konfigurace testovaného produktu atd.
Jakmile víte, kde a co automatizovat, můžete se pustit do samotného vytvoření prvního automatického testu. Než se do něj pustíte, je dobré zvolit si, v čem jej budete programovat (Python, Perl, C, Java) a jakých nástrojů využijete (testovací framework, knihovny s komunikačními protokoly atd.) Mně se osvědčilo využít skriptovací jazyky, protože mají rozsáhlou podporu již předpřipravených scénářů, jež můžete využít. Já osobně preferuji Python. V počátku určitě nepotřebujete vytvářet testovací framework – na to bude správný čas, až budete mít větší představu o tom, co vše budete automatizovat a co budete potřebovat. Můžete ale využít některý z již existujích testovacích frameworků. Možná vás tady napadne otázka, kdo by měl takový test psát? Programátor, tester nebo snad scrummaster? 😃 Ten posledně zmíněný – pokud tedy není zároveň vývojář – by jej psát neměl, ale jinak může kdokoliv z týmu. Záleží na tom, jak se tým domluví, pokud se tedy bavíme o agilních týmech. Pokud jedete vodopádem, pak je to vše na testovacím týmu.
Dále je dobré vytvořit stabilní testovací prostředí. Většina týmů a jednotlivců tvoří své první automatizované testy na svých počítačích a testují produkt, který je také instalovaný na jejich PC. To je pro začátek určitě dobré především pro urychlení. V pozdější fázi ale komplikuje celou automatizaci a také vyhodnocení těchto testů především proto, že stabilita testovaného produktu není dostatečná. Jak ji tedy zlepšit? Máte dvě možnosti: vytvoříte testbedy – tedy testovací prostředí, které obsahuje váš produkt a je nutné, aby bylo stále v jasně definovaném stavu. Co to znamená? Databáze musejí obsahovat testovací data, uživatele, přístupové oprávnění, sítě příslušné interfacy atd. Pokud se vám totiž bude prostředí stále měnit, těžko budou testy spolehlivě vyhodnocovat chyby v produktu. Příklad: Nastaví-li někdo uživateli (který má mít omezené přístupové právo) práva super admina, automatický test, který vám ověřuje, že uživatel nemá na něco právo, zahlásí chybu, které v produktu ale není. Takové testy pak budou vést k pochopitelné demotivaci těch, kteří je analyzují. Druhá možnost je nasazovat testovaný produkt automaticky a z „čistého“ buildu. Automatické testy potom na začátku připraví testovací data a na konci je zase odstraní, pokud běží testů více po sobě.
Často se stává, že narazíte na chybně vytvořenou architekturu celého systému, jež vám znemožňuje testovat na nižších vrstvách. Pokud je možné produkt rozdělit na jasné bloky, které mají stanovené vstupy a výstupy, automatizace bude výrazně jednodušší.
Nejčastější chyby
Špatné místo pro automatizaci – většina týmů hned v úvodu chybuje v tom, že se pokouší o automatizaci co nejblíže uživateli (z pohledu test pyramidy to je co nejvýše). Tedy že automatizuje GUI místo toho, aby tvořili integrační testy, testy komponent, API testy apod. Důvodem je většinou mylná představa, že potřebují vytvořit identické testy s těmi manuálními. Vhodnější pohled je říci si, co můžeme automaticky testovat na úrovni programátorské. Co na úrovni komponent, co na integrační a co jsme nikde neotestovali?
Další chybou je, že se snaží vymyslet super univerzální testovací framework (před tím než se pustí do automatizace jednotlivých testů) a dělají měsíční analýzu toho, co budou potřebovat. Přitom často naráží na nedostatek informací, co a jak se bude dělat a jaké jsou vlastně požadavky na framework. Řešení je snadné – prvně pište testy a z potřeb, které objevujete, vytvářejte testovací framework. Tedy např. až když zjistíte, že všechny testy otevírají HTTP spojení, tak vytvořte funkci, jež HTTP spojení vytváří, a zařaďte ji do frameworku. Budete tím postupovat po malých krocích, které jsou ale stabilní a nehrozí riziko zbytečného effortu, který pak přichází vniveč.
Podcenění času, který je na vytvoření kompletní automatizace třeba – to je další častý problém. Spousta týmů a managerů chce mít rychle automatizaci hotovou a odbytou, tak to ale nefunguje. Tvorba automatizovaného testovaní se nedá udělat dopředu bez dalšího effortu do budoucna. Je to kontinuální proces, každý cyklus (sprint, release, měsíc) je třeba navrhnout nové testy, opravit změny dle nové funkcionality a zavést vylepšení. Proto se spíše ptejte, kolik času budete každý cyklus věnovat této činnosti.
Další kroky
Pokud realizujete zmíněné 4 kroky a vyvarujete se nejčastějším chybám, získáte kvalitní základ automatizovaných testů, na kterém se dá dále pracovat a který můžete rozvíjet dle svých potřeb. Možné další kroky jsou:
- navrhnout testovací framework
- vytvořit sadu automatických smoke testů
- vytvořit sadu automatických regresních testů
- navrhnout propojení s dalšími systémy (automatické buildy, TMT, requirementy, automatické reporty)
Pokud se chcete naučit jak se automatizuje testování mrkněte na kurz: Jak automatizovat testy. Automatizované testy jsou v dnešní době nutností, která dělí vývojové týmy na ty úspěšné a neúspěšné podle toho, jak se týmu podaří automatizaci zavést. Přeji vám, ať automatizované testy ve vašem týmu šetří čas i peníze a jsou silným pomocníkem – to je ostatně jejich hlavní smysl! Čím dřív začnete, tím dřív je budete moc využívat.
Pokud vás článek zaujal, budu rád za komentáře a postřehy z vaší praxe. Automatizaci zdar! 🙂
