IT rekvalifikácia. Seniorní programátori zarábajú až 6 000 €/mesiac a rekvalifikácia je prvým krokom. Zisti, ako na to!

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

V predchádzajúcej lekcii, Statické testovanie , sme sa pozreli na testovanie údržby, základy statického testovania, vysvetlili sme si hodnotu statického testovania a porovnali sme si odlišnosti statického a dynamického testovania.

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

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. Pokiaľ nie je tím schopný dodať to, čo zainteresované 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:

Team spolupracujúci na projekte. - Testovanie softvéru podľa ISTQB - 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 a zabezpečiť, 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. Umožňuje im tiež zamerať sa na tie úžitkové vlastnosti, ktoré prinášajú zainteresovaným stranám najvyššiu pridanú hodnotu, a ktoré majú najviac pozitívny 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 pravidelne revidujú prototyp. 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 zapracujú spätnú väzbu a pridajú možnosť komentárov. Následne prebieha ďalšia revízia, kde projektoví manažéri overia, že 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, implementuje túto zmenu 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 proces revízie môže byť vykonaný opakovane:

Činnosti procesu revízie - Testovanie softvéru podľa ISTQB - 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 bolo všetko pripravené na revíziu. 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ý revidujúci 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. Napríklad jeden revidujúci si 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ť a 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 aké následné opatrenia sú vyžadované. Na uzatvorenie opatrení môže byť vyžadovaná ďalšia revízia. Napríklad počas schôdzky tím prejde jednotlivé nájdené anomálie, pričom u niektorých sa rozhodne, že nie sú defekty, ale skôr nejasnosti. Ďalšie anomálie, ako 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 opis a návrhy na opravy. 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 - 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 alebo je odborníkom na danú problematiku alebo aj 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álne a neskôr formálnejšie.

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 a firemná kultúra:

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

Informal review

Informal review (neformálna revízia) sa neriadi definovaným procesom a nevyžadujú 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ízie) 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 - Testovanie softvéru podľa ISTQB

Napríklad, moderátor 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 správne škálovateľné pri raste počtu transakcií.

Inspection

Vzhľadom na to, že inšpekcie (inšpekcie) sú 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, motivácia a podpora autorov v zlepšovaní. Sú zhromažďované metriky, ktoré sa používajú na zlepšovanie celého SDLC vrátane samotného procesu inspection. Pri inspections nemôže autor vystupovať ako vedúci revízie alebo zapisovateľ.

Faktory úspechu pri revízii

Existuje niekoľko faktorov kľúčových 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ú koncentráciu počas revízie alebo počas revíznych schôdzok.
  • 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 Decouter, Klaudia Dussa-Zieger, Jean-François Riverin, Arnika Hryszko, Martin Klonk, Michael Pilaeten, Meile Posthuma, Stuart Reid, Eric Riou du Cosquer (predseda) 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.


 

Predchádzajúci článok
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ý!
Aktivity