Týmy a testeři vyvíjející software dnes čelí poměrně velkému tlaku na rychlost dodávání svých produktů. Svět se mění, zrychluje, a tak i požadavky na rychlost narůstají absurdním tempem. Před 10 lety nebylo půl roku mezi releasy žádné tabu. Zato dnes nám agilní vývoj radí, že release našich produktů se má ideálně odehrát na konci každého sprintu. To je ale každých 14 dní (typická délka sprintu)! Jak ale stihnout nakódovat software během 14 dní, k tomu ověřit jeho kvalitu, a přitom si zachovat příčetnost? Spousta vývojářských týmů v tomto bodě ne nepochopitelně selhává. Pojďme se podívat na možné viníky.
Nedostatečná automatizace
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ů.
