Proč nám testování trvá tak dlouho?

Představme si tým vyvíjející například mobilní aplikaci pro předpověď počasí. Aplikace je rozdělena na frontend, backend a data o počasí se získávájí ze serverů externího partnera. Na začátku sprintu tým srdnatě naplánuje dodat 3 nové featury, které bez obstrukcí začnou implementovat. Implementace zabere většinu sprintu a poslední 4 dny před koncem sprintu se vrhnou na testování. Aby ověřili, že aplikace neobsahuje zásadní chyby, sepsali si moudře množinu testcaseů, jimiž prověří novou funkcionalitu, a také regresní testy, které prověří, že nerozbili nic v původním kódu. Veškeré testy jsou manuální, a je tedy nutné celou aplikaci tzv. proklikat. To je časově dost náročné, a proto na tom zapáleně pracuje celý tým. Problém je v tom, že množství regresních testů není zrovna malé, a navíc se nám každý sprint nepříjemně zvětšuje. Tým velice rychle zjistí, že i když je tvořen partou solidních nadšenců, není schopen ověřit produkt kompletně – a tak sahá k různým typům redukcí testovacích sad. Nehezkým výsledkem ale neodvratitelně je, že týmu uniká čím dál více chyb. Jelikož nalezené chyby je nutné opravit, ztrácíme další čas na opakovaný release.

Přitom správná odpověď na tuto situaci není nijak složitá: je třeba investovat do tvorby automatických testů (ideálně hned od počátku produktu). Vraťme se k našemu týmu z příkladu a jejich aplikaci. Pokud nová featura zavádí přidání deseti nových parametrů, jejich manuální otestování – např. pro deset druhů zařízení a operačních systémů – nás stojí sto kombinací (viz kartézský součin). Tak tohle bude náš tým z příkladu stíhat manuálně jen s jazykem na vestě! Přitom spustit automatické testy ve všech kombinacích nás stojí pouze strojový čas, ale lidský effort je téměř stejný. Proto klíčem ke zrychlení a snížení časové náročnosti členů týmu je právě automatizace testování.

Nevhodné místo pro automatizaci

Pokud již automatizované testy máme v repertoáru, stále nemáme vyhráno – týmům v prostředí agilního testování často nastává další nepříjemnost: údržba automatických testů konzumuje mnoho času. Představme si následující scénář – pro zjednodušení si jej ukažme na našem týmu vyvíjejícím mobilní aplikaci. Tým investoval dost času, aby si vytvořil automatické testy na GUI. Údržba těchto testů je ale poměrně časově náročná legrace. Při každé změně a přidávání položek se musí automatické testy adaptovat na změnu a množství takto zasažených testů je velké. Důvodem je zaměření týmu na špatnou oblast, kde ověřují kvalitu produktu. Pěkně je tato situace viditelná na Pyramidě testování (obr1). Čím výše se při automatizaci budete pohybovat, tím časově náročnější bude automatizace i samotná údržba. Tým by se měl především zaměřit z pohledu white-box testování na automatizaci unit testů (píší většinou vývojáři pro každý kód, který vytvoří). A z pohledu black box testování by se měl zaměřit na komponent testy a integrační testy, kde například zaměření na testování backendu nebo API umožňuje výrazně snazší automatizaci než je tomu u frontendu. Důvodem, proč je backend snazší, je absence rozpoznávání obrazu a absence identifikace grafických objektů.

Automatizace automatizace a Continuous Integration

Spousta týmu končí s tím, že mají vytvořené automatické testy. Ty pak více či méně spouštějí ručně a kontrolují výsledky. To, co mi připadá na automatických testech opravdu úžasné, je jejich další možnost automatizace. Co tím myslím? Pokud máte automatický test, který vám kontroluje, že při poslání dotazu na server obsahující data o počasí se vám vrátí relevantní údaje o počasí. Pak není nic snadnějšího než tento test zahrnout do hromadnéhou spouštění, tedy nechat tyto testy, aby se pouštěly při každem buildu produktu, a vy tak měli stálý přehled o kvalitě vašeho produktu. Unit testy se mohou pouštět při každém uložení do repozitáře. Integrační testy se zase mohou spouštět ihned po buildu produktu. Celému tomuto procesu se říká Continuous Integration a je to taková automatizace automatizace – tedy automatické řízení buildění, pouštění a vyhodnocení všech automatických testů a sledování celkové kvality produktu. Mnohé týmy tvrdí, že na CI nemají čas. Přitom čas strávený manuálním pouštěním, vyhodnocováním a řešením problémů během pouštění testů jim nevadí. Dává vám to smysl? Mně tedy ne! CI vám naopak ušetří čas, který můžete investovat smysluplně jinde.

Závěr

Co vzletného říci závěrem… automatizovat, automatizovat – a to na vhodném místě! Je ale třeba myslet na to, že plná automatizace většinou není efektivní. Vhodné je zvolit automatizaci tam, kde odhalíme podstatné chyby nebo výrazně zjednodušíme testování.

Současný trend ve zvyšování rychlosti při vývoji software je viditelný asi všem. Do budoucna nepředpokládám, že by se tento trend zpomalil, spíš přesně naopak. Rychlost změn se stále zvyšuje a schopnost týmů při vývoji software se tomu přizpůsobit, vidím jako klíčovou pro úspěch vašich projektů.

Proto se nabízí otázka na závěr: Jaký je váš plán pro navýšení automatických testů ve vašem týmu? Pojďte se podělit o svoje zkušenosti a trable při automatizaci testování. Neváhejte mě kontaktovat.