Lekce 7 - Proces zpětné vazby a revize

V předchozím kvízu, Kvíz - DevOps, úrovně testování a statické testování, jsme si ověřili nabyté zkušenosti z předchozích lekcí.

V dnešní lekci se dozvíme něco o činnostech procesu zpětné vazby a revize, vysvětlíme si role a odpovědnosti při revizích a podíváme se na typy revizí a faktory jejich úspěchu.

Proces zpětné vazby a revize

Včasná a častá zpětná vazba pomáhá s odhalením potenciálních problémů s kvalitou. Pokud se zainteresované strany zapojují do vývoje nedostatečně, vyvíjený produkt nemusí splňovat jejich původní nebo současné představy. Není-li tým schopen dodat to, co zúčastněné strany chtějí, hrozí riziko vícenákladů na přepracování, zmeškaných termínů, vzájemného obviňování, a dokonce může dojít k úplnému selhání projektu.

Častá zpětná vazba od zainteresovaných stran během SDLC může zabránit nedorozuměním při definici požadavků. Také zajistí, aby změny požadavků byly správně a včas pochopeny a implementovány. To pomáhá vývojovému týmu lépe porozumět tomu, co vyvíjí. Zpětná vazba také vývojářům umožňuje zaměřit se na ty užitné vlastnosti, které přinášejí zúčastněným stranám nejvyšší přidanou hodnotu a které mají nejpozitivnější dopad na zjištěná rizika.

Praktický příklad

Představme si vývoj webové aplikace pro interní správu projektů ve firmě. Tým vývojářů vytvoří první prototyp aplikace, která má umožnit sledování pracovních úkolů a jejich termínů. Zainteresované strany, jako projektoví manažeři, prototyp pravidelně revidují. Poskytnou zpětnou vazbu, že potřebují funkci pro přidávání komentářů k jednotlivým úkolům, což v původních požadavcích nebylo. Vývojáři okamžitě zpětnou vazbu zapracují a přidají možnost komentářů. Následně probíhá další revize, kdy projektoví manažeři ověří, zda nová funkce splňuje jejich očekávání. Po několika dalších iteracích zpětné vazby si zainteresované strany uvědomí, že potřebují i automatické upozornění na blížící se termíny úkolů. Vývojový tým díky častým revizím rychle zareaguje, tuto změnu implementuje a předejde tak pozdějším drahým úpravám nebo nespokojenosti uživatelů.

Činnosti procesu revize

Norma ISO/IEC 20246 definuje obecný proces revize a popisuje strukturovaný, ale flexibilní rámec, ze kterého může být daný proces revize přizpůsoben konkrétní situaci. Čím vyšší je požadovaný stupeň formálnosti revize, tím vyšší je počet úkolů během různých činností. Mnohé pracovní produkty jsou tak rozsáhlé, že je nelze pokrýt pouze jedinou revizí a její proces může být proveden opakovaně:

Plánování

Během fáze plánování se stanoví rozsah revize obsahující definici účelu a revidovaného pracovního produktu, kvalitativní charakteristiky pro vyhodnocení, oblasti zájmu, výstupní kritéria, doplňující informace, pracnost a časový rámec celé revize. Při plánování se například tým rozhodne provést revizi specifikací pro nový modul e-shopu. Určí, že hlavním účelem revize je ověřit, zda specifikace jasně popisují všechny požadavky a zda jsou správně definována rozhraní. Revize má být dokončena během jednoho týdne.

Zahájení revize

Během zahájení revize je cílem zajistit, aby k ní bylo vše připraveno. To mimo jiné vyžaduje, aby měl každý účastník přístup k revidovanému pracovnímu produktu, rozuměl své roli a odpovědnostem a obdržel vše potřebné k provedení revize. Před zahájením revize tedy každý člen týmu obdrží přístup k dokumentaci, kterou bude revidovat. Účastníci jsou seznámeni se svými rolemi, odpovědnostmi a se seznamem věcí, na které se mají zaměřit.

Individuální revize

Každý účastník reviduje definovaný pracovní produkt individuálně s cílem posoudit jeho kvalitu a identifikovat anomálie, doporučení a otázky pomocí jedné nebo více technik revize. Revidující zaznamenává všechny zjištěné anomálie, doporučení a otázky. Při individuální revizi tedy například každý člen týmu samostatně projde specifikace modulu a zaznamená všechny nesrovnalosti, jako nejasné požadavky nebo chybějící části. Jeden z revidujících účastníků si například všimne, že chybí definice pro jeden klíčový parametr.

Komunikace a analýza

Ne každá anomálie identifikovaná během revize musí být nutně defekt. Proto je nutné všechny takové anomálie analyzovat a prodiskutovat. U každé by mělo být rozhodnuto o jejím stavu, vlastnictví a požadovaných opatřeních. To se obvykle provádí při revizní schůzce, během níž účastníci také diskutují o úrovni kvality každého revidovaného pracovního produktu a o tom, jaká následná opatření jsou vyžadována. K uzavření opatření může být vyžadována další revize. Tým například během schůzky projde jednotlivé nalezené anomálie, přičemž o některých rozhodne, že nejsou defekty, ale spíše nejasnostmi. Další anomálie, např. chybějící část specifikace, jsou označeny jako defekty a je dohodnuto, kdo je opraví.

Opravy a reportování

Aby bylo možné provést nápravu, měl by být pro každý defekt vytvořen report o defektu. Při splnění daných výstupních kritérií může být pracovní produkt akceptován a výsledky revize jsou reportovány. Takže například pro všechny identifikované defekty je vytvořen report, který obsahuje jejich popis a návrhy oprav. Po opravách jsou specifikace revidovány znovu, a pokud splňují výstupní kritéria, je revize úspěšně uzavřena a výsledky jsou reportovány vedení projektu.

Role a odpovědnosti při revizích

Revizi mohou provádět různí lidé a mohou zastávat různé role:

Hlavní role a jejich povinnosti jsou:

• Manažer – rozhoduje o tom, co má být revidováno a jaké zdroje budou využity (včetně lidí a času).
• Autor – vytváří a opravuje revidovaný pracovní produkt.
• Moderátor (někdy také facilitátor) – zajišťuje efektivní průběh revizních schůzek včetně využití mediace. Mimo jiné dohlíží na dodržení časového rámce a zajištění komfortního prostředí, ve kterém může každý svobodně vyjádřit svůj názor.
• Zapisovatel – shromažďuje anomálie od revidujících a zaznamenává další informace z revize, jako např. různá rozhodnutí nebo nové anomálie zjištěné během revizní schůzky.
• Revidující – provádí revizi. Revidujícím může být někdo, kdo pracuje na projektu, je odborníkem na danou problematiku nebo kterákoli jiná zainteresovaná strana.
• Vedoucí revize – přebírá celkovou odpovědnost za revizi a organizaci toho, kdy a kde se bude revize konat. Popis dalších možných rolí lze nalézt v normě ISO/IEC 20246.

Typy revizí

Existuje mnoho typů revizí, od neformálních až po velmi formální. Požadovaná úroveň formálnosti závisí na faktorech, jako je použitý SDLC, vyspělost procesu vývoje, kritičnost a složitost revidovaného pracovního produktu, právní nebo regulatorní požadavky a potřeba doložení záznamů pro případný audit. Stejný pracovní produkt může být revidován různými typy revizí, např. nejprve neformálními a později formálnějšími.

Výběr správného typu revize je klíčový pro dosažení požadovaných cílů revize. Výběr je ale založen na dalších faktorech, jako jsou potřeby projektu, dostupné zdroje, typ pracovního produktu, typ rizika, byznysová doména či firemní kultura:

Informal review

Informal review (neformální revize) se neřídí definovaným procesem a nevyžaduje formální dokumentovaný výstup. Hlavním cílem je odhalování anomálií. Představme si vývoj softwarového systému pro zpracování bankovních transakcí. Vývojář požádá kolegu, aby si rychle prohlédl nový kód pro validaci bankovních transakcí. Kolega si kód projde a neformálně navrhne několik změn pro zvýšení čitelnosti a bezpečnosti, například lepší kontrolu vstupních dat.

Walkthrough

Walkthrough (předvedení) může sloužit mnoha cílům, jako je hodnocení kvality a budování důvěry v pracovní produkt, vzdělávání revidujících, dosažení dohody, generování nových nápadů, motivace a podpora autora s cílem zlepšovat pracovní produkt a odhalovat anomálie. Revidující mohou před walkthrough provést individuální revizi. Jako příklad si můžeme uvést setkání, kde autor kódu pro správu účtů předvede logiku svého řešení zbytku týmu. Tým dává zpětnou vazbu, klade otázky, generuje nápady na zlepšení a potvrzuje, že kód odpovídá požadavkům a standardům firmy.

Technical review

Technical review (technická revize) provádějí odborně kvalifikovaní revidující a vede ji moderátor. Cílem technical review je primárně dosáhnout shody a učinit rozhodnutí týkající se nějakého technického problému, ale také odhalit anomálie, vyhodnotit kvalitu, vybudovat důvěru v pracovní produkt, generovat nové nápady, motivovat autory a podpořit je ve zlepšování.

Moderátor například vede technical review, kde odborníci hodnotí efektivitu algoritmu pro zpracování platebních operací. Cílem je dosáhnout shody ohledně optimalizace kódu a zajištění, že řešení bude při růstu počtu transakcí správně škálovatelné.

Inspection

Vzhledem k tomu, že inspection (inspekce) je nejformálnějším typem revize, řídí se komplexním obecným procesem. Hlavním cílem je nacházet maximální počet anomálií. Dalšími cíli jsou hodnocení kvality, budování důvěry v pracovní produkt a motivace či podpora autorů ve zdokonalování. Jsou shromažďovány metriky, které se používají ke zlepšování celého SDLC, včetně samotného procesu inspection. Při inspection nemůže autor vystupovat jako vedoucí revize nebo zapisovatel.

Faktory úspěchu při revizi

Existuje několik klíčových faktorů pro úspěch procesu revize:

• Jsou definovány jasné cíle a měřitelná výstupní kritéria. Nejsou hodnoceni účastníci revize, ale revidovaný pracovní produkt.
• Je vybrán takový typ revize, který je vhodný pro dosažení daných cílů, pro typ pracovního produktu, pro účastníky revize a pro potřeby a kontext projektu.
• Revize jsou prováděné po malých částech, takže revidující neztrácejí během revize nebo během revizních schůzek koncentraci.
• Zainteresovaným stranám a autorům je poskytována zpětná vazba z revizí tak, aby mohli zlepšovat produkt a své činnosti.
• Účastníci mají dostatek času na přípravu.
• Management podporuje proces revize.
• Revize jsou součástí firemní kultury s cílem podporovat učení a zlepšování procesů.
• Je poskytnuto vhodné odborné školení pro všechny účastníky tak, aby věděli, jak plnit svou roli v procesu.
• Schůzky jsou správně řízené.

Zdrojem této lekce jsou Učební osnovy – Certifikovaný tester základní úrovně ver. 4.0. Copyright © 2023 autoři verze 4.0: Renzo Cerquozzi, Wim Decoutere, Klaudia Dussa-Zieger, Jean-François Riverin, Arnika Hryszko, Martin Klonk, Michaël Pilaeten, Meile Posthuma, Stuart Reid, Eric Riou du Cosquer (předseda), Adam Roman, Lucjan Stapp, Stephanie Ulrich (místopředseda), Eshraka Zakaria

V příští lekci, Testovací analýza a návrh testů, si ukážeme přehled testovacích technik a poté se zaměříme na techniky testování černé skříňky.