V rámci tradičního vývojového procesu se často zapomíná na jednu jeho nenápadnou, ale zato podstatnou složku: testery. Developeři si po sobě ten systém přece otestují sami, ne? Přesně na základě takového předpokladu pak bývá testování opomíjeno i při počátečních estimacích potřebného rozpočtu a plánování milníků pro doručení finálního produktu. Co je koneckonců to nejhorší, co se může stát?
Standardně to celé probíhá následovně. Ze začátku vše vypadá nadějně a funkcionality se do systému přidávají podle plánu. Postupně si ale tým začne všímat nekonzistencí a neočekávaného chování aplikace na několika místech. Při vývoji komplexnější platformy se množství bugů (tedy chyb v kódu) může nahromadit až takovým způsobem, že to zpomalí samotný vývoj funkcionalit a vývojáři namísto tvorby nových částí produktu musí věnovat značnou část svého času právě odstraňování těchto chyb. V takovou chvíli si Product Owner začíná uvědomovat, že se projekt nestíhá doručit ve slíbeném termínu, a komunikuje tuto skutečnost s investory a stakeholdery, kteří pochopitelně nejsou právě nadšení. Celý tým se tak ocitá pod tlakem hned z několika stran a jeho původní vize se tak pomalu, ale jistě hroutí.
Proč ne vývojáři?
Jakožto firma poskytující softwarové služby na zakázku jsme rychle zjistili, že očekávat od vývojářů, že kromě svých primárních povinností budou ještě všechno pravidelně testovat, je nereálné. Vývoj a testování vyžadují dva různé způsoby myšlení – jedná se o tvorbu nové funkcionality versus validaci existujícího řešení. Pokud budeme požadovat od vývojářů, aby oba tyto způsoby myšlení přepínali na denní bázi, pravděpodobně jedinými dlouhodobějšími výsledky budou zvýšená míra tlaku na ně a naopak snížená kvalita soustředění kvůli časté změně kontextu. Testování navíc vyžaduje pohled na řešení z různých úhlů pohledu. Developeři, kteří si svou práci testují sami, mohou mít tendenci pohlížet na svá vlastní řešení podobnými způsoby, a tím pádem potenciálně neobjevovat nevyřešené případy, nebo dokonce chyby v dané funkcionalitě.
Chtít po klientech, aby si celý produkt otestovali sami, se nám ale také nejevilo jako dobré řešení. Chceme doručovat kvalitní software, který klient ihned může použít namísto toho, aby nám musel nejprve reportovat bugy.
Proto jsme se nakonec jsme rozhodli vyčlenit kontrolu kvality jako samostatnou roli – roli testera, neboli QA.
Co dělá QA a proč bych ho měl chtít na svém projektu?
Primární odpovědnosti
Hlavní rolí testera je kontrola kvality vyvíjeného produktu. Pomocí úzké spolupráce s týmem zajišťuje, aby byla doručena kvalitní, udržovatelná a škálovatelná aplikace.
Definice testovacích scénářů
Testování není deterministické, tedy nelze dopředu určit, jestli a kolik bugů bude objeveno. Při tvorbě testovacích scénářů je tedy potřeba vyhodnotit, jaký dopad má daná funkcionalita na koncové uživatele, a podle toho alokovat čas na pokrytí této funkcionality testy.
Před psaním samotných testů je úkolem QA zmapovat všechny funkcionality koncového produktu a identifikovat, typicky za pomoci Product Ownera, kritické cesty v systému (funkcionality, které musí vždy fungovat podle očekávání). Na základě toho se tester primárně věnuje těm funkcionalitám a scénářům, které byly vyhodnoceny jako kritické.
Manuální testování
Manuální testování je pro testery denním chlebem. Tato činnost obnáší pravidelné procházení vydefinovaných scénářů, kontrolu, zda se aplikace chová podle očekávání, a nahlášení chyb předtím, než se daná funkcionalita dodá koncovým uživatelům.
Není ale udržitelné vše testovat manuálně – QA by potom nemělo čas na nic jiného. Pro dobrou udržovatelnost a škálovatelnost aplikace se proto implementují automatizované testy, které pokrývají kritické funkcionality.
Implementace automatizovaných testů
Abychom udrželi kontrolu nad kvalitou vyvíjené aplikace s rostoucí komplexitou, je potřeba v rámci vývoje psát testy. Některé z nich píšou přímo vývojáři (typicky unit testy, integrační testy) a některé jsou zodpovědností QA (tzv. end-to-end testy, které simulují interakci uživatele s vyvíjeným systémem).
Díky automatizovaným testům lze odchytit chyby nových i stávajících funkcionalit při zavádění změn do systému. Tento proces pomáhá zamezit již zmíněnému hroucení produktu pod vlastní tíhou při postupném kupení neodhalených chyb.
Čím ještě může QA přispět?
Kromě zmíněných zodpovědností se QA může účastnit procesů, kde pomáhá nastavit a dodržovat kontrolu kvality nad produktem.
Analýza požadavků
Při počáteční analýze požadavků může QA nabídnout specifický pohled na věc – vidí možná úskalí navržených uživatelských scénářů, pomáhá identifikovat nespecifikované chování a pokládá správné otázky tak, aby tým hned ze začátku pracoval s co nejúplnější sadou požadavků a očekávání.
Součástí tohoto procesu bývá také analýza rizik, kdy se QA snaží identifikovat potenciální problémy předem. Díky tomu tým dokáže v lepším případě problému předejít, v horším případě ho komunikovat zákazníkovi, a včas tak s ním počítat.
Zvážení test-driven development přístupu
V tradičním vývojovém procesu nejprve probíhá implementace, a poté následují testy pro danou funkcionalitu. Při aplikaci tzv. TDD (test-driven development) přístupu je to právě naopak – na základě požadavků a očekávání je sestavena sada testů a implementace je potom přizpůsobena tak, aby těmito testy prošla.
QA pomáhá při počátečních fázích určit, zda je tento přístup vhodný pro aktuální projekt. Aby měl TDD kýžený účinek, je totiž potřeba, aby se na tom tým domluvil hned na začátku vývoje.
Pro více informací o test-driven developmentu si neváhejte poslechnout ngBeer prezentaci od Matěje Chalka. Slidy prezentace si můžete projít zde.
Určení a dodržení milníku pro pokrytí systému testy
Jedním z měřitelných faktorů kvality produktu je míra pokrytí systému testy. Podle typu vyvíjené aplikace a podoby kritických cest v systému se mohou požadavky na pokrytí testy pro různé funkcionality lišit.
Úlohou QA je vykomunikovat a dohodnout požadavky na pokrytí testy s klientem při počáteční fázi projektu a neopomenout potřebné úsilí pro definici a implementaci domluveného množství testovacích scénářů při estimacích.
Proces odbourávání bugů při agilním vývoji
V tradičním vývojovém procesu může odhalení bugů znamenat meškání termínů a zvýšenou pracovní zátěž vývojářského týmu. Přechodem na agilní vývoj pomocí scrumu jsme ale ve flowup přišli na způsob, jak integrovat bugy do sprintů.
Vše, co jste chtěli vědět o tom, jak pracujeme v rámci Scrumu (a nebáli jste se zeptat)
Existuje nespočet pracovních postupů, pomocí kterých tým developerů vyvine nový software. Ve FlowUpu jsme si za několik let našeho fungování ověřili, že nám nejvíce vyhovuje Scrum, obecně nejpopulárnější agilní metoda softwarového vývoje vůbec. V tomto článku vám popíšeme, proč jsme si Scrum vybrali, jak v rámci něj fungujeme a jaké výhody vám přinese, pokud se spolu pustíme do spolupráce.
15 min. čtení od
Při plánování sprintu část kapacity rezervujeme pro neočekávané problémy, mezi něž může patřit právě oprava nalezených chyb. QA při plánování pomáhá Product Ownerovi identifikovat nejprioritnější bugy, které jsou následně přidány do sprintu. Díky tomuto přístupu bugy nenarušují tempo doručování funkcionalit.
Kontrola kvality pomocí CI/CD
Abychom zaručili, že nově přidaný kód odpovídá nastaveným standardům a nerozbije naši nasazenou aplikaci, máme na našich projektech tzv. CI/CD pipeliny. CI/CD pipeline se skládá ze série kroků, které se spouští při přidání nového kódu do aplikace. Ten je validován a testován před nasazením nové verze aplikace do cílového prostředí. Pipeliny jsou typicky vytvářeny a udržovány vývojářským týmem.
Kromě revize kvality kódu a jiných měřítek mohou tyto pipeliny také spouštět automatizované testovací sady naimplementované vývojáři i testerem. Díky tomuto procesu dokážeme zaručit, že aplikace funguje dle očekávání po každé přidané změně.
Zaručí tedy přítomnost testera nulový výskyt bugů?
Díky zmapování a pravidelnému testování funkcionalit systému QA snižuje riziko, že se neodhalené chyby dostanou až do finální verze aplikace. Je ale nutno dodat, že bugy jsou přirozenou součástí vývoje a nelze je nikdy úplně eliminovat.
Přítomnost QA zajišťuje přehled a kontrolu nad odhalenými chybami tím, že tyto chyby nahlašuje a zaručuje se za to, že jsou postupně odbourávány v rámci vývojových iterací, aniž by ovlivnily vývojové tempo týmu. Zároveň se podílí na tvoření automatizovaných testovacích sad pro kritické funkcionality, které zajišťují korektní chování těchto funkcionalit po dobu celého vývojového procesu.
Závěr
V případě absence QA ve vývojovém týmu se zákonitě značné množství chyb dostává rovnou do produkčního prostředí, kde s aplikací interagují koncoví uživatelé. V takové situaci je většinou zapotřebí řešit frustraci nejen uživatelů, ale i stakeholderů vašeho projektu, a následně navýšit potřebný rozpočet pro opravu těchto chyb. Pokud máte smůlu, narazíte i na chyby, které jsou přímo spojeny s vnitřní logikou aplikace a jejich oprava bude trvat déle, než byste si přáli.
Dedikovaný tester, který pravidelně kontroluje kvalitu vašeho produktu a prochází stávající i nově přidané funkcionality, může vyřešit více, než se na první pohled zdá. Díky QA máte přehled o všech nahlášených chybách spolu s doporučením, které z nich je potřeba začít odbourávat jako první. Ačkoli QA přímo neimplementuje funkcionality vašeho systému, zásadně se podílí na tom, aby vaše aplikace splnila všechna očekávání – vás i koncových zákazníků.
