Autor: .cCuMiNn. | 9.2.2016 |
Řízení kvality softwaru, které je samo o sobě velice rozsáhlým a složitým tématem, není hlavní náplní této příručky. Omezím se proto pouze na nezbytně nutné minimum, jímž se budu snažit čtenáře uvést do této problematiky. Zájemce o detailní informace věnované řízení kvality softwaru odkáži například na skvělou knihu Petra Roudenského a Anny Havlíčkové Řízení kvality softwaru: Průvodce testováním, kterou v roce 2013 vydal Computer Press, případně na veřejně dostupný text stejné autorky Testování webových aplikací.
Pod pojmem řízení kvality softwaru, který je znám také pod termínem Quality Assurance (QA) si můžete představit souhrn pravidel a postupů vedoucích ke zvýšení kvality vyvíjených systémů a aplikací. Kvalitou je v tomto kontextu myšleno například intuitivní a přehledné uživatelské rozhraní, rychlá odezva, očekávané chování a výstupy programu, běh bez havárií, správné zotavování a v neposlední řadě také bezpečnost.
Ve větších společnostech se proto často nachází také oddělení kvality, které je za kvalitu zodpovědné. Toto oddělení přitom nemá na starosti pouze samotné testování, ale i jeho plánování, řízení zdrojů, tvorbu reportů a jeho měření. Dříve, než se však podíváme na samotné testování a jeho jednotlivé metody, pojďme nahlédnout na životní cyklus vývoje aplikace. Ten se chtě nechtě stává nedílnou součástí vývoje každé aplikace a poskytne nám tak dobrý odrazový můstek pro popis toho, jaké (bezpečnostní) testy je vhodné v jeho jednotlivých fázích provést.
Stejně jako lze do několika fází rozdělit život člověka: narození, dětství, dospívání, dospělost, stáří a smrt, lze do konkrétních fází rozčlenit také vývoj softwaru. Sled několika po sobě jdoucích kroků, které je nutné pro vývoj aplikace uskutečnit, označujeme anglickým výrazem System Development Life Cycle (SDLC), který v překladu zní životní cyklus vývoje aplikace. SDLC metodiky vznikaly v posledních desetiletích proto, aby sjednotily pravidla a postupy používané během vývoje softwaru. Cílem těchto metodik tedy je napomoci společnostem vyvíjejícím software vnést díky jasně definovaným a popsaným postupům do životního cyklu vývoje určitý řád. SDLC metodiky proto konkrétně popisují jednotlivé fáze vývojového cyklu, počínaje zjištěním vstupních požadavků uživatelů, přes rozbor a návrh systému až po jeho testování, implementaci, provoz a údržbu.
Standardizovaných SDLC metodik vzniklo velké množství, přičemž každá z nich se hodí na něco trochu jiného a do jiného prostředí. Tradičním způsobem programování a tedy nejstarším a současně asi i nejznámějším modelem vývojového cyklu je metodika zvaná vodopád. Při jejím využití navazují jednotlivé fáze životního cyklu bezprostředně za sebou, případně se někdy mohou i překrývat. Výstup jedné fáze se tedy stává vstupem pro fázi následující a mnohdy tak není možné bez ukončení jedné fáze přejít k dalším krokům. Celý proces je do detailu naplánován a zdokumentován již na samém začátku vývoje, a jak si můžete všimnout na následujícím schématu, jedná se o jednosměrný postup směřující pouze vpřed, respektive dolů. Jakékoliv budoucí odchylky od plánu a případné změny ve funkčnosti výsledného softwaru celý proces značně komplikují a při jejich výskytu se bohužel musí často začínat znovu od samého začátku.
Díky uvedené skutečnosti je dnes cyklus vodopád využíván spíše u menších projektů, kdežto u robustnějších se často uchylujeme k iterativním (spirála) nebo agilním metodám (extrémní programování, Scrum). Při nich je celý proces rozdělen do menších částí (interací), které se navrhují, implementují a testují jako samostatné celky. U agilních metodik je pak důraz kladem hlavně na komunikaci mezi členy týmu a ne na úvodní specifikace a dokumentaci. Ta je v těchto případech často dostupná pouze v minimálním možném rozsahu.
Tradiční vývojový cyklus vodopád nám ale díky svému intuitivnímu pojetí vhodně poslouží pro popis jednotlivých fází vývojového cyklu. Mezi běžně zahrnutými kroky najdeme analýzu, návrh, implementaci, testování, nasazení, provoz a údržbu.
Základem každého projektu je shromáždění požadavků cílového uživatele. Tyto požadavky mohou být funkčního charakteru, což znamená, že definují, jaké výstupy má aplikace vrátit na základě konkrétních vstupů, nebo mohou být také mimofunkční. Ty specifikují například vzhled uživatelského rozhraní, rychlost odezvy aplikace, nebo její možné zatížení.
Ve fázi analýzy se také snažíme o vytvoření seznamu známých problémů a návrhů jejich řešení. Nezřídka se vytváří případy užití známé pod výrazem use case, které je možné zapisovat ve formě textu nebo častěji pomocí use case diagramů. Pomocí případů užití je možné srozumitelně, ale současně bez zabíhání do přílišných detailů popsat, jaké funkčnosti jsou od aplikace vyžadovány. Nezabýváme se tím, jak bude aplikace určité věci dělat, ale soustředíme se pouze na zodpovězení otázky, co by měla umět. Následující UC diagram zachycuje případy užití pro jednoduchou aplikaci webové diskuze.
Zájemce o bližší informace vztahující se k analýze a k případům užití odkáži na některou z mnoha dostupných knih věnujících se jazyku UML, jenž se při analýze a návrhu aplikací využívá asi nejčastěji.
Na základě shromážděných požadavků dochází k posouzení realizovatelnosti, odhadu rozsahu systému, ekonomické efektivnosti a návratnosti investice. Mimo to se definují také zdroje nutné k řešení (finance, personál, SW, HW a podobně).
Výstupem z této fáze se stává dokument, který specifikuje účel požadovaného softwaru. Identifikuje budoucí uživatele včetně jejich hlavních požadavků, definuje jednotlivé části systému, vstupy, výstupy a procesy. Součástí je také hrubý odhad požadovaných prostředků včetně nákladů.
Během fáze návrhu dochází k postupnému upřesňování základních požadavků. Projekt se případně dělí na menší části a subprojekty. Dochází k modelování funkcí a objektů, navrhuje se datový model a rozhraní. Nejprve je vytvořen hrubý návrh, který je následně podroben opětovnému rozboru, během něhož se jednotlivé součásti systému definují do co nemenších detailů.
Výstupem této části jsou dokumenty, které detailně popisují návrh budoucího softwaru včetně jeho datového modelu a funkcí. Podrobně popisují toky dat, požadavky na SW, HW, postupy při testování, nasazování do ostrého provozu a servisní služby.
Fází implementace rozumíme samotnou práci programátorů, kteří na základě specifikací vzniklých v předchozích fázích vývoje vytváří výsledný funkční kód aplikace. Budují databázovou strukturu a jednotlivé objekty, které následně spojují do funkčního celku. Výstupem z této fáze je tedy funkční software, který splňuje všechny požadavky cílových uživatelů. Součástí výsledného produktu je také jeho kompletní dokumentace.
Ve fázi testování dochází k verifikaci správného chování vytvořené aplikace. Ověřuje se, zda aplikace vrací na konkrétní vstupy očekávané výstupy. Fáze testování zahrnuje jednak manuální testy, ale také unit testy, nebo testy pomocí automatizovaných nástrojů. Vedle funkčních požadavků je testováno také uživatelské rozhraní a jsou prováděny zátěžové testy. V ideálním případě je v tomto kroku také důkladně prověřena bezpečnost aplikace revizí jejího kódu a provedením penetračních testů.
Během zavádění nového softwaru do provozu dochází k jeho instalaci u zákazníka a ke školení cílových uživatelů. Součástí je také počáteční podpora, dohled nad zkušebním provozem a případné odstraňování chyb.
Údržbou rozumíme zajištění provozu běžícího softwaru a jeho rozvoj na základě nových požadavků od jeho uživatelů. Během této fáze dochází často k optimalizaci, nebo ke změnám, které mohou být funkčního, provozního, ale i organizačního charakteru.
Nejlépe vše pochopíme, pokud si uvedeme velice jednoduchý příklad, který nás bude provázet i po zbytek této části, jenž je věnovaná řízení kvality. Představte si následující zadání: Zákazník si žádá vytvoření velice jednoduché kalkulačky, která by byla přístupná přes webové rozhraní. Pojďme si na tomto příkladu projít celým SDLC procesem, abychom si následně na stejném příkladu ukázali také to, co vše je potřeba otestovat.