7. diel - Proces spätnej väzby a revízie Nové

V predchádzajúcom kvíze, Kvíz - DevOps, úrovne testovania a statické testovanie, sme si overili nadobudnuté skúsenosti z predchádzajúcich lekcií.

V dnešnej lekcii sa dozvieme niečo o činnostiach procesu spätnej väzby a revízie, vysvetlíme si role a zodpovednosti pri revíziách a pozrieme sa na typy revízií a faktory ich úspechu.

Proces spätnej väzby a revízie

Včasná a častá spätná väzba pomáha s odhalením potenciálnych problémov s kvalitou. Ak sa zainteresované strany zapájajú do vývoja nedostatočne, vyvíjaný produkt nemusí spĺňať ich pôvodné alebo súčasné predstavy. Ak nie je tím schopný dodať to, čo zúčastnené strany chcú, hrozí riziko viacnákladov na prepracovanie, zmeškaných termínov, vzájomného obviňovania, a dokonca môže dôjsť k úplnému zlyhaniu projektu.

Tím spolupracujúci na projekte. - Testovanie softvéru podľa ISTQB

Častá spätná väzba od zainteresovaných strán počas SDLC môže zabrániť nedorozumeniam pri definícii požiadaviek. Tiež zabezpečí, aby zmeny požiadaviek boli správne a včas pochopené a implementované. To pomáha vývojovému tímu lepšie porozumieť tomu, čo vyvíja. Spätná väzba tiež vývojárom umožňuje zamerať sa na tie úžitkové vlastnosti, ktoré prinášajú zúčastneným stranám najvyššiu pridanú hodnotu a ktoré majú najpozitívnejší vplyv na zistené riziká.

Praktický príklad

Predstavme si vývoj webovej aplikácie pre internú správu projektov vo firme. Tím vývojárov vytvorí prvý prototyp aplikácie, ktorá má umožniť sledovanie pracovných úloh a ich termínov. Zainteresované strany, ako projektoví manažéri, prototyp pravidelne revidujú. Poskytnú spätnú väzbu, že potrebujú funkciu na pridávanie komentárov k jednotlivým úlohám, čo v pôvodných požiadavkách nebolo. Vývojári okamžite spätnú väzbu zapracujú a pridajú možnosť komentárov. Následne prebieha ďalšia revízia, kedy projektoví manažéri overia, či nová funkcia spĺňa ich očakávania. Po niekoľkých ďalších iteráciách spätnej väzby si zainteresované strany uvedomia, že potrebujú aj automatické upozornenie na blížiace sa termíny úloh. Vývojový tím vďaka častým revíziám rýchlo zareaguje, túto zmenu implementuje a predíde tak neskorším drahým úpravám alebo nespokojnosti užívateľov.

Činnosti procesu revízie

Norma ISO/IEC 20246 definuje všeobecný proces revízie a popisuje štruktúrovaný, ale flexibilný rámec, z ktorého môže byť daný proces revízie prispôsobený konkrétnej situácii. Čím vyšší je požadovaný stupeň formálnosti revízie, tým vyšší je počet úloh počas rôznych činností. Mnohé pracovné produkty sú tak rozsiahle, že ich nemožno pokryť iba jedinou revíziou a jej proces môže byť vykonaný opakovane:

Činnosti procesu revízi - Testovanie softvéru podľa ISTQB

Plánovanie

Počas fázy plánovania sa stanoví rozsah revízie obsahujúci definíciu účelu a revidovaného pracovného produktu, kvalitatívne charakteristiky pre vyhodnotenie, oblasti záujmu, výstupné kritériá, doplňujúce informácie, prácnosť a časový rámec celej revízie. Pri plánovaní sa napríklad tím rozhodne vykonať revíziu špecifikácií pre nový modul e-shopu. Určí, že hlavným účelom revízie je overiť, či špecifikácie jasne popisujú všetky požiadavky a či sú správne definované rozhrania. Revízia má byť dokončená počas jedného týždňa.

Začatie revízie

Počas začatia revízie je cieľom zabezpečiť, aby k nej bolo všetko pripravené. To okrem iného vyžaduje, aby mal každý účastník prístup k revidovanému pracovnému produktu, rozumel svojej úlohe a zodpovednostiam a dostal všetko potrebné na vykonanie revízie. Pred začatím revízie teda každý člen tímu dostane prístup k dokumentácii, ktorú bude revidovať. Účastníci sú oboznámení so svojimi rolami, zodpovednosťami a so zoznamom vecí, na ktoré sa majú zamerať.

Individuálna revízia

Každý účastník reviduje definovaný pracovný produkt individuálne s cieľom posúdiť jeho kvalitu a identifikovať anomálie, odporúčania a otázky pomocou jednej alebo viacerých techník revízie. Revidujúci zaznamenáva všetky zistené anomálie, odporúčania a otázky. Pri individuálnej revízii teda napríklad každý člen tímu samostatne prejde špecifikácia modulu a zaznamená všetky nezrovnalosti, ako nejasné požiadavky alebo chýbajúce časti. Jeden z revidujúcich účastníkov si napríklad všimne, že chýba definícia pre jeden kľúčový parameter.

Komunikácia a analýza

Nie každá anomália identifikovaná počas revízie musí byť nutne defekt. Preto je nutné všetky takéto anomálie analyzovať a prediskutovať. Pri každej by sa malo rozhodnúť o jej stave, vlastníctve a požadovaných opatreniach. To sa zvyčajne vykonáva pri revíznom stretnutí, počas ktorého účastníci tiež diskutujú o úrovni kvality každého revidovaného pracovného produktu a o tom, aké následné opatrenia sú vyžadované. Na uzatvorenie opatrení môže byť vyžadovaná ďalšia revízia. Tím napríklad počas schôdzky prejde jednotlivé nájdené anomálie, pričom o niektorých rozhodne, že nie sú defekty, ale skôr nejasnosťami. Ďalšie anomálie, napr. chýbajúca časť špecifikácie, sú označené ako defekty a je dohodnuté, kto ich opraví.

Opravy a reportovanie

Aby bolo možné vykonať nápravu, mal by byť pre každý defekt vytvorený report o defekte. Pri splnení daných výstupných kritérií môže byť pracovný produkt akceptovaný a výsledky revízie sú reportované. Takže napríklad pre všetky identifikované defekty je vytvorený report, ktorý obsahuje ich popis a návrhy opráv. Po opravách sú špecifikácie revidované znova, a pokiaľ spĺňajú výstupné kritériá, je revízia úspešne uzavretá a výsledky sú reportované vedeniu projektu.

Úloha a zodpovednosti pri revíziách

Revíziu môžu vykonávať rôzni ľudia a môžu zastávať rôzne role:

Úloha - Testovanie softvéru podľa ISTQB

Hlavné úlohy a ich povinnosti sú:

  • Manažér - rozhoduje o tom, čo má byť revidované a aké zdroje budú využité (vrátane ľudí a času).
  • Autor – vytvára a opravuje revidovaný pracovný produkt.
  • Moderátor (niekedy aj facilitátor) – zaisťuje efektívny priebeh revíznych schôdzok vrátane využitia mediácie. Okrem iného dohliada na dodržanie časového rámca a zabezpečenie komfortného prostredia, v ktorom môže každý slobodne vyjadriť svoj názor.
  • Zapisovateľ – zhromažďuje anomálie od revidujúcich a zaznamenáva ďalšie informácie z revízie, ako napr. rôzne rozhodnutia alebo nové anomálie zistené počas revízneho stretnutia.
  • Revidujúca – vykonáva revíziu. Revidujúcim môže byť niekto, kto pracuje na projekte, je odborníkom na danú problematiku alebo ktorákoľvek iná zainteresovaná strana.
  • Vedúci revízie – preberá celkovú zodpovednosť za revíziu a organizáciu toho, kedy a kde sa bude revízia konať. Popis ďalších možných rolí možno nájsť v norme ISO/IEC 20246.

Typy revízií

Existuje mnoho typov revízií, od neformálnych až po veľmi formálne. Požadovaná úroveň formálnosti závisí od faktorov, ako je použitý SDLC, vyspelosť procesu vývoja, kritickosť a zložitosť revidovaného pracovného produktu, právne alebo regulačné požiadavky a potreba doloženia záznamov pre prípadný audit. Rovnaký pracovný produkt môže byť revidovaný rôznymi typmi revízií, napr. najprv neformálnymi a neskôr formálnejšími.

Výber správneho typu revízie je kľúčový pre dosiahnutie požadovaných cieľov revízie. Výber je ale založený na ďalších faktoroch, ako sú potreby projektu, dostupné zdroje, typ pracovného produktu, typ rizika, biznisová doména či firemná kultúra:

Typy revízií - Testovanie softvéru podľa ISTQB

Informal review

Informal review (neformálna revízia) sa neriadi definovaným procesom a nevyžaduje formálny dokumentovaný výstup. Hlavným cieľom je odhaľovanie anomálií. Predstavme si vývoj softvérového systému na spracovanie bankových transakcií. Vývojár požiada kolegu, aby si rýchlo prezrel nový kód na validáciu bankových transakcií. Kolega si kód prejde a neformálne navrhne niekoľko zmien na zvýšenie čitateľnosti a bezpečnosti, napríklad lepšiu kontrolu vstupných dát.

Walkthrough

Walkthrough (predvedenie) môže slúžiť mnohým cieľom, ako je hodnotenie kvality a budovanie dôvery v pracovný produkt, vzdelávanie revidujúcich, dosiahnutie dohody, generovanie nových nápadov, motivácia a podpora autora s cieľom zlepšovať pracovný produkt a odhaľovať anomálie. Revidujúci môžu pred walkthrough vykonať individuálnu revíziu. Ako príklad si môžeme uviesť stretnutie, kde autor kódu pre správu účtov predvedie logiku svojho riešenia zvyšku tímu. Tím dáva spätnú väzbu, kladie otázky, generuje nápady na zlepšenie a potvrdzuje, že kód zodpovedá požiadavkám a štandardom firmy.

Technical review

Technical review (technická revízia) vykonávajú odborne kvalifikovaní revidujúci a vedie ju moderátor. Cieľom technical review je primárne dosiahnuť zhodu a urobiť rozhodnutie týkajúce sa nejakého technického problému, ale tiež odhaliť anomálie, vyhodnotiť kvalitu, vybudovať dôveru v pracovný produkt, generovať nové nápady, motivovať autorov a podporiť ich v zlepšovaní.

Moderátor technickej revízie. - Testovanie softvéru podľa ISTQB

Moderátor napríklad vedie technical review, kde odborníci hodnotia efektivitu algoritmu na spracovanie platobných operácií. Cieľom je dosiahnuť zhodu ohľadom optimalizácie kódu a zaistenie, že riešenie bude pri raste počtu transakcií správne škálovateľné.

Inspection

Vzhľadom na to, že inspection (inšpekcia) je najformálnejším typom revízie, riadi sa komplexným všeobecným procesom. Hlavným cieľom je nachádzať maximálny počet anomálií. Ďalšími cieľmi sú hodnotenie kvality, budovanie dôvery v pracovný produkt a motivácia či podpora autorov v zdokonaľovaní. Sú zhromažďované metriky, ktoré sa používajú na zlepšovanie celého SDLC, vrátane samotného procesu inspection. Pri inspection nemôže autor vystupovať ako vedúci revízie alebo zapisovateľ.

Faktory úspechu pri revízii

Existuje niekoľko kľúčových faktorov pre úspech procesu revízie:

  • Sú definované jasné ciele a merateľné výstupné kritériá. Nie sú hodnotení účastníci revízie, ale revidovaný pracovný produkt.
  • Je vybraný taký typ revízie, ktorý je vhodný na dosiahnutie daných cieľov, pre typ pracovného produktu, pre účastníkov revízie a pre potreby a kontext projektu.
  • Revízie sú vykonávané po malých častiach, takže revidujúci nestrácajú počas revízie alebo počas revíznych schôdzok koncentráciu.
  • Zainteresovaným stranám a autorom je poskytovaná spätná väzba z revízií tak, aby mohli zlepšovať produkt a svoje činnosti.
  • Účastníci majú dostatok času na prípravu.
  • Management podporuje proces revízie.
  • Revízie sú súčasťou firemnej kultúry s cieľom podporovať učenie a zlepšovanie procesov.
  • Je poskytnuté vhodné odborné školenie pre všetkých účastníkov tak, aby vedeli, ako plniť svoju úlohu v procese.
  • Schôdzky sú správne riadené.

Zdrojom tejto lekcie sú Učebné osnovy – Certifikovaný tester základnej úrovne ver. 4.0. Copyright © 2023 autori verzie 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 (predseda), Adam Roman, Lucjan Stapp, Stephanie Ulrich (podpredseda), Eshraka Zakaria

V budúcej lekcii, Testovacia analýza a návrh testov, si ukážeme prehľad testovacích techník a potom sa zameriame na techniky testovania čiernej skrinky.


 

Ako sa ti páči článok?
Pred uložením hodnotenia, popíš prosím autorovi, čo je zleZnakov 0 z 50-500
Predchádzajúci článok
Kvíz - DevOps, úrovne testovania a statické testovanie
Všetky články v sekcii
Testovanie softvéru podľa ISTQB
Preskočiť článok
(neodporúčame)
Testovacia analýza a návrh testov
Článok pre vás napísala Jana Zimčíková
Avatar
Užívateľské hodnotenie:
Ešte nikto nehodnotil, buď prvý!
Autorka se věnuje IT a technologiím. Ovládá Javu, Spring Boot, SQL i frontend a chce pomáhat lidem objevit svůj potenciál v IT světě.
Aktivity