Za hranicemi testingu: quality assurance jako další krok vpřed

Důsledný testing je nedílnou součástí vývoje jakéhokoliv softwaru. Vždyť právě díky němu můžeme ověřit, že každá část systému funguje přesně tak, jak má, a tak přinášet spokojenost všem stranám. Klientům, koncovým uživatelům, ale i nám jakožto vývojářům. 

Přiznejme si však, že v realitě to nebývá zdaleka tak růžové, jak se někdy prezentuje. Testing má totiž svá omezení, která mimo jiné zahrnují i způsob, jak v základu funguje. Věnuje se mu často pozornost až po nasazení softwaru, a až v tomto bodu tedy dochází k opravě bugů a objevování nedorozumění. Bohužel není možné dobře predikovat, kolik takových případů bude, a tak vývojáři mohou jen doufat, že bude jejich práce co nejlepší.

Testing se nezaměřuje na prevenci chyb a funguje na reaktivní úrovni. To je jedním z důvodů, proč je ve většině případů neoptimálním a hlavně neefektivním přístupem. Existuje něco lepšího? Rozhodně ano – quality assurance je disciplínou, která testing zahrnuje, ale mnohem lépe se díky ní dosahuje požadované kvality softwaru.

V INVENTI už se nesoustředíme na testing jakožto samostatnou jednotku. Co všechno za naším rozhodnutím stojí a co to znamená pro vás?

Už žádná dramata v projektech

Člověk se chybami učí. Za více než 10 let fungování už máme představu o nejčastějších slabých místech vývoje, kterým je potřeba věnovat speciální pozornost. Ani to však nezaručuje, že se po spuštění aplikace nevyskytnou závažné defekty.

Při předání nového projektu do vývoje ještě donedávna probíhalo typické kolečko. Pustili jsme se do strategického plánování a sestavení týmu, abychom aplikaci dodali včas a v rámci stanoveného rozpočtu. Analyzovali jsme požadavky našeho zákazníka a navrhovali postupy, které měly vést k jeho maximální spokojenosti.

Nicméně přibližně v polovině projektu mnohdy nastal zlom. Vývoj nešel zcela podle plánu a navíc jsme už měli vyčerpaný risk buffer na bugy i změnové požadavky.

Transformace Testing oddělení na Quality Assurance se jevila jako ideální řešení. To koneckonců potvrzuje i studie globálního leadera v oblasti digitální transformace, Capgemini. Podle ní QA přináší nejen 50% snížení defektů na produkční úrovní, ale také vede až k 60% snížení časové náročnosti testingu. 

V rámci studie od společnosti Springer, která publikuje řadu akademických materiálů zaměřených mimo jiné i na obor technologií, pak došlo k analýze tří týmů z Microsoftu a jednoho z IBM. Po adopci QA přístupu se u nich snížila míra defektů před spuštěním projektu o 40 až 90 %.

To přirozeně vede k mnohem většímu klidu napříč vývojovými týmy. Snižuje se totiž riziko, že se dostanou do finanční či časové tísně.

Reaktivita testingu je problémem, proaktivita quality assurance řešením

Celý proces testingu je nastaven veskrze reaktivně. Na projektu nastavíte testing strategii, plánujete, co a kdy otestujete a děláte přípravu na základě zadání od analytika. V momentě, kdy najdete bug, řešíte s vývojovými a analytickými týmy, kde vznikl, projektovému manažerovi pak reportujete stav testování.

Jste v cyklu neustálých reakcí na to, co se stalo, ale neřešíte, jak ke spouštěči došlo. Přesně tímto způsobem dochází k popsaným dramatům.

Oproti tomu díky quality assurance zaujímáte proaktivní přístup k celému projektu. Na úplném začátku se bavíte se zadavatelem, co pro něj znamená kvalitní aplikace – tedy co přesně by měla naplňovat. Následně se zaměřujete na prevenci chyb, které by kvalitu mohly narušit.

Náš QA tým vyžaduje u projektů odpovědi na následující otázky:

• Je analýza validovaná se zadavatelem? Máme k dispozici zápis ze schůzky?
• Co všechno patří mezi funkční a nefunkční požadavky?
• Jaká jsou akceptační kritéria?
• Je celý tým dobře informován o rizicích a cílech daného projektu?
• Jaká je zpětná vazba od zadavatele v průběhu vývoje?
• Jaké jsou aktuální priority?
• Proč nám vznikla chyba? Co je její skutečná příčina?

V quality assurance je klíčová především komunikace se zadavatelem a celým týmem. V INVENTI veškeré procesy nastavujeme hned ze začátku. Jejich dodržování pak nevyhodnocujeme jednorázově, ale kontinuálně. Stejným způsobem probíhá i testing.

Pokud tápete ve správném přístupu k zajištění kvality softwarového řešení, podívejte se na si náš QA checklist.

Jaké jsou další benefity quality assurance?

Oproti testingu má quality assurance mnohem širší záběr, konkrétní rozdíly jsme pak vypsali v tomto článku. Nicméně mimo standardní prvky jako test management, testovací analýzu či reportování bugů zahrnuje také prevenci bugů, pracuje s klíčovými ukazateli výkonnosti a také nastavuje strategie, jak udržet kvalitu – od začátku až do konce.

Jako další nezpochybnitelné výhody QA je potřeba zmínit:

Snížení nákladů na vývoj. Podle IBM jsou náklady na opravu chyby nalezené během fáze implementace přibližně 6× vyšší než u  chyby, která byla identifikována během fáze návrhu. Pokud se bug vyskytne až po spuštění, náklady mohou být až stonásobné.

Kratší doba do uvedení na trh (time to market). Jelikož QA praktiky zefektivňují celkový vývojový proces, software se typicky může spustit dříve než v případě samotného testingu.

Zvýšená spokojenost zákazníků. Průzkum provedený americkým odborníkem na metodologii softwarového inženýrství, Capers Jonesem, potvrdil, že implementace QA v projektech zvyšuje spokojenost zákazníků o 10 %.

Zvýšená návratnost investic. Jelikož zajištění kvality přináší úspory při opravách chyb či údržbě, ROI projektů se může razantně zvyšovat oproti čistému testingu. 

Zlepšení spolehlivosti SW produktů. Quality assurance zajišťuje lepší funkčnost softwarových produktů, a to až o 30 %.

Zvýšená produktivita vývojových týmů. QA přináší jasně stanovená očekávání, a tak se v týmech snižuje frustrace spojená s odstraňováním bugů. 

Jak to může vypadat v praxi?

Představte si, že vyvíjíte e-shop s třístránkovou flow. Navrchu první stránky má být zobrazeno nejoblíbenější zboží, dole pak veškerý sortiment s možností zobrazit detail. Na druhé stránce je možné zboží objednat, na třetí se pak vyplňují veškeré údaje včetně způsobu doručení a platby.

Proces u projektu, kde se pouze testuje

Na začátku projektu analytik shromažďuje veškeré požadavky a vytváří zadávací dokumentaci. U každé funkcionality popisuje use case a ideálně také definuje akceptační kritéria. V dokumentaci nacházíte informaci o tom, že e-shop má fungovat primárně pro desktop a disponovat dostatečnou rychlostí.

V průběhu projektu do zadání přibývají obrazovky od UX/UI designera a během každého sprintu analytik představuje zadání, vy pak odhadujete pracnost a začínáte s vývojem. Vývojový tým má nastavenou code coverage, kterou dodržuje.

Během sprintů také tvoříte test analýzy a testujete. Nacházíte bug, zadáte ho a pak probíhá schůzka, kde ho s vývojovým analytickým týmem zkoumáte a ukazujete, jak jste k němu přišli. Vývojový tým ho pak odstraňuje a následně přichází řada na retest.

Když pak zadavateli prezentujete výsledek v pevné víře, že jej akceptuje, vrátí vám ho s tím, že neodpovídá jeho představám. Část projektu reklamuje s poznámkami, že:

• nejoblíbenější sortiment se nemá zobrazovat za celé období, ale poslední týden,
• načítání detailu produktu trvá příliš dlouho a klient nemá informaci o tom, co se děje – obrazovka je zamrznutá,
• při vyplňování údajů pro nákup je nejednoznačné, co je vyplněno špatně,
• na menším monitoru nejsou vidět některá tlačítka,
• v jiném prohlížeči, než je Chrome, aplikace není přehledná.

To vede k frustraci zadavatele – pokládá si otázku, co jste celou tu dobu dělali. Kvůli tomu pak musí tým pracovat přesčasy, je totiž potřeba dodržet jasně stanovený termín nasazení. Značnou část aplikace je nutné přepsat, protože není navržena pro jiné prohlížeče. Kód pak musíte refactorovat, aby došlo ke zrychlení aplikace, původně jste totiž předpokládali, že stačí plnit průměrné hodnoty.

Aplikaci upravujete a po schválení nasazujete na produkci. Zadavateli se však nedaří plnit konverzní poměr, který si naplánoval. Hledáte a analyzujete důvody, pak nasazujete metriky a čekáte na sběr dat. Ta pak vyhodnocujete a aplikaci optimalizujete.

Proces u projektu, kde se naplno zapojuje QA

Jak by scénář mohl probíhat, kdybyste následovali QA best practices?

QA oddělení dohlíží na to, aby se tým hned na začátku domluvil, jaké informace od zadavatele či analytika potřebuje pro svou práci. 

Následně zjišťujete od zadavatele, co pro něj znamená kvalitní aplikace. Pokládáte otázky, které ověřují úplnost funkčních i nefunkčních požadavků. Analytik sbírá data a sepisuje je do požadovaného formátu.

Zajištění kvality jako nutná součást moderního vývoje

Věnovat se pouze testingu, ale podceňovat komplexní QA přístup je v dnešní době samo o sobě chybou. Díky zajištění kvality se totiž razantně snižuje počet bugů, zkracuje se doba, kdy dojde k uvedení produktu na trh a navíc zadavatel není ničím překvapený.

V INVENTI díky QA perfektně naplňujeme naše standardy kvality a promítáme je do každého projektu, který nám přijde pod ruce. Chcete i vy zajistit maximální kvalitu vašeho softwaru? Kontaktujte nás – v rámci konzultace zdarma se rádi podíváme na to, jak vám můžeme být nápomocní!