Menu

Proces správy defektov: Ako efektívne riadiť defekty

  • Hlavná
  • Iné
  • Proces správy defektov: Ako efektívne riadiť defekty

defect management process

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Úvod do procesu správy defektov:

Cielenejší proces a testovanie umožní na trhu menej chybného softvéru.

Prevencia defektov je oveľa efektívnejšie a efektívnejšie pri znižovaní počtu chýb a je tiež veľmi nákladovo efektívne opraviť chyby zistené v počiatočnej fáze softvérového procesu. Väčšina organizácií koná Zistenie chyby , Odstránenie chyby a potom Zlepšovanie procesu ktorá je súhrnne známa ako a Proces správy defektov .

Proces správy defektov

aplikácie na sťahovanie videí z youtube

Čo sa dozviete:

Ciele procesu správy defektov (DMP)

Ďalej sú uvedené rôzne ciele tohto procesu:

  • Zabráňte defektu
  • Včasná detekcia
  • Minimalizujte dopad
  • Uznesenie o vade
  • Zlepšovanie procesu

Pred preskúmaním procesu správy defektov nám najskôr porozumieme čo je to vlastne chyba alebo chyba?

Životný cyklus riadenia defektov

Keď systém poskytuje iný výstup ako skutočnú obchodnú požiadavku, t. J. Keď sa odchýli od skutočnej alebo pôvodnej obchodnej požiadavky, môžeme povedať, že došlo k chybe v systéme / softvéri.

Keď testovací tím vykoná testovacie prípady, narazia na situáciu, keď sa skutočný výsledok testu líši od očakávaného výsledku. Táto variácia sa nazýva a Porucha .

Softvérová chyba je v zásade stav, ktorý nespĺňa požiadavky na softvér. Poruchou je chyba alebo chyba, ktorá spôsobí neočakávané alebo nesprávne správanie v systéme.

Na správne zvládnutie projektov je potrebné vedieť, ako sa vysporiadať s vývojom a vydaním, ale zároveň s nimi musíte vedieť aj s chybami.

Len si predstavte, čo sa stane, ak testovací tím ústne nahlási chyby a vývojový tím tiež slovne aktualizuje stav chyby? Proces bude komplikovanejší, pretože tieto chyby zahŕňajú všetky chyby, ako sú skutočne opravené a fungujúce podľa očakávania, opravené, ale stále nefungujúce, odmietnuté, odložené a proces pokračuje.

V uvedenom prípade, keď sa zvýši počet chýb a komunikácia sa uskutoční ústne, bude situácia čoskoro veľmi najhoršia. Aby ste mohli poruchu efektívne kontrolovať a zvládnuť, potrebujete správny životný cyklus chyby.

Defektný životný cyklus zaručuje, že proces je jednotný a štandardizovaný. Porucha dosahuje rôzne stavy v životnom cykle. Po zistení poruchy prechádza počas svojej životnosti rôznymi fázami a je všeobecne známa ako Porucha životného cyklu .

Životný cyklus chyby spravidla začína fázou, keď je chyba zistená alebo vyvolaná testovacím tímom, a končí, keď je chyba odstránená buď zaistením, že nie je reprodukovateľná, alebo ju vývojový tím neodmietne. Počet stavov, ktorými porucha prechádza, sa v jednotlivých projektoch líši.

Ďalšie čítanie:

Čo je životný cyklus chyby / chyby v testovaní softvéru? Výukový program pre poruchu životného cyklu

Poznámka: Nižšie uvedený cyklus sa mierne líši od organizácie k organizácii.

Nasledujúci životný cyklus poruchy pokrýva všetky možné stavy:

Vývojový diagram defektu životného cyklu

  • Kedykoľvek testovací tím zistí chybu v aplikácii, upozorní ju na stav ako „ NOVÝ “.
  • Keď je nová chyba skontrolovaná vedúcim QA a ak je chyba platná, potom by stav chyby bol „ Otvorené “A je pripravený na pridelenie vývojovému tímu.
  • Keď vedúci QA priradí chybu príslušnému vývojárovi, stav chyby sa označí ako „ pridelených “. Developer by mal v tejto fáze začať s analýzou a opravou chyby.
  • Ak má vývojár pocit, že chyba nie je pravá alebo platná, potom chybu odmietne. Stav poruchy je označený ako „ Zamietnuté ”A pridelený späť testovaciemu tímu.
  • Ak sa zaznamenaná chyba opakuje dvakrát alebo majú obidve hlásené chyby podobné výsledky a kroky na reprodukciu, potom sa jeden stav chyby zmení na „ Duplikát “.
  • Ak v aktuálnom vydaní existujú nejaké problémy alebo prekážky týkajúce sa odstránenia konkrétnej chyby, potom by sa chyba brala v nasledujúcich vydaniach namiesto aktuálneho vydania a potom je označená ako „ Odložené “Alebo„ Odložené “.
  • Ak vývojár nie je schopný reprodukovať chybu podľa krokov uvedených v časti „Kroky na reprodukciu“ testovacieho tímu, môže vývojár chybu označiť ako „ Nereprodukovateľné “ . V tejto fáze by mal testovací tím poskytnúť vývojárovi podrobné kroky reprodukcie.
  • Ak vývojár nemá jasno v krokoch reprodukcie poskytovaných QA na reprodukciu chyby, môže ju označiť ako „ Potrebujete viac informácií “. V takom prípade musí testovací tím poskytnúť vývojovému tímu požadované podrobnosti.
  • Ak je vada už známa a momentálne sa vyskytuje v produkčnom prostredí, potom je vada označená ako „ Známa chyba “.
  • Keď vývojár vykoná potrebné zmeny, potom je chyba označená ako „ Opravené “.
  • Vývojár teraz odovzdá chybu testovaciemu tímu na overenie, takže vývojár zmení stav na „ Pripravené na opakované testovanie “.
  • Ak chyba nemá ďalšie problémy a je správne overená, potom ju tester označí ako „ Zatvorené “.
  • Ak tester zistí, že pri opätovnom testovaní chyby je chyba stále reprodukovateľná alebo čiastočne opravená, bude chyba označená ako „ Znovu otvorené “. Teraz musí vývojár znova preskúmať túto chybu.

Dobre naplánovaný a kontrolovaný životný cyklus defektov poskytuje celkový počet chýb zistených vo vydaní alebo vo všetkých vydaniach. Tento štandardizovaný proces poskytuje jasný obraz o tom, ako bol kód napísaný, ako správne bolo vykonané testovanie, ako bola vydaná chyba alebo softvér, atď. Znížením počtu chýb vo výrobe sa zistia chyby v testovaní. samotná fáza.

Proces správy defektov

Proces správy defektov

Proces správy defektov je podrobne vysvetlený nižšie.

# 1) Prevencia defektov:

Prevencia defektov je najlepšou metódou na odstránenie chýb v počiatočnej fáze testovania, namiesto toho, aby sa chyby našli v neskoršej fáze a potom sa opravili. Táto metóda je tiež nákladovo efektívna, pretože náklady na odstránenie chýb zistených v počiatočných fázach testovania sú veľmi nízke.

Nie je však možné odstrániť všetky chyby, ale môžete minimalizovať ich vplyv a náklady na ich odstránenie.

Hlavné kroky spojené s prevenciou defektov sú tieto:

  • Identifikujte kritické riziko : Identifikujte kritické riziká v systéme, ktoré budú mať väčší dopad, ak k nim dôjde počas testovania alebo v neskoršej fáze.
  • Odhadovaný očakávaný dopad : Pre každé kritické riziko vypočítajte, aký veľký bude finančný dopad, ak by sa riziko skutočne vyskytlo.
  • Minimalizujte očakávaný vplyv : Akonáhle identifikujete všetky kritické riziká, vezmite najvyššie riziká, ktoré môžu byť pre systém škodlivé, ak sa vyskytnú, a pokúste sa riziko minimalizovať alebo vylúčiť. Pre riziká, ktoré nie je možné vylúčiť, znižuje pravdepodobnosť výskytu a jeho finančný dopad.

# 2) Východisková hodnota dodávky:

Keď produkt (systém, produkt alebo dokument) dosiahne svoj vopred definovaný míľnik, môžete povedať, že produkt je základnou líniou. V tomto procese sa produkt alebo produkt premiestňuje z jednej fázy do druhej a keď sa produkt premiestňuje z jednej fázy do druhej, existujúce chyby v systéme sa prenesú aj do ďalšieho míľnika alebo etapy.

Napríklad, zvážte scenár kódovania, testovania jednotiek a potom testovania systému. Ak vývojár vykonáva kódovanie a testovanie jednotiek, potom testovanie systému vykonáva testovací tím. Tu je kódovanie a testovanie jednotiek jedným míľnikom a testovanie systému ďalším míľnikom.

Ak teda počas testovania jednotky vývojár zistí nejaké problémy, potom sa to nepovažuje za chybu, pretože tieto problémy sa zistia pred dosiahnutím stanoveného termínu. Po dokončení programovania a testovania jednotiek vývojár odovzdá kód na testovanie systému a potom môžete povedať, že kód je „Baselined“ a pripravený na ďalší míľnik, v tomto prípade ide o „testovanie systému“.

Teraz, ak sa problémy zistia počas testovania, nazýva sa to defektom, ktorý sa zistí po dokončení predchádzajúceho míľnika, tj. Kódovania a testovania jednotiek.

Dodávky sú v zásade stanovené, keď sú zmeny v dodávkach dokončené a všetky možné chyby sú identifikované a opravené. Potom ten istý produkt prejde na ďalšiu skupinu, ktorá na tom bude pracovať.

# 3) Zistenie chyby:

Je takmer nemožné odstrániť všetky chyby zo systému a vytvoriť systém bezchybný. Môžete však identifikovať chyby skôr, ako sa stanú pre projekt nákladnejšie. Môžeme povedať, že zistená chyba znamená, že je formálne upozornená vývojovým tímom a po analýze vývojový tím chyby ju tiež prijal ako chybu.

Pri zisťovaní defektov sú potrebné tieto kroky:

  • Nájdite chybu : Identifikujte chyby skôr, ako sa stanú hlavným problémom systému.
  • Nahlásiť chybu : Hneď ako testovací tím zistí chybu, jeho zodpovednosťou je informovať vývojový tím o tom, že existuje identifikovaný problém, ktorý je potrebné analyzovať a opraviť.
  • Potvrdiť chybu : Akonáhle testovací tím pridelí chybu vývojovému tímu, jeho zodpovednosťou je vývojový tím uznať chybu a pokračovať v jej odstraňovaní, ak ide o platnú chybu.

# 4) Riešenie chyby:

V rámci vyššie uvedeného procesu testovací tím identifikoval chybu a nahlásil ju vývojovému tímu. Teraz tu musí vývojový tím pokračovať v riešení chyby.

Kroky spojené s riešením chyby sú tieto:

  • Stanovte prioritu riziku : Vývojový tím analyzuje chybu a dáva prednosť jej odstráneniu. Ak má chyba väčší vplyv na systém, potom má jej odstránenie vysokú prioritu.
  • Opravte chybu : Na základe priority vývojový tím chybu opraví, chyby s vyššou prioritou sa vyriešia ako prvé a chyby s nižšou prioritou sa opravia na konci.
  • Nahlásiť uznesenie : Zodpovednosť vývojového tímu za zabezpečenie toho, aby si testovací tím bol vedomý, kedy sa chyby chystajú na opravu a ako bola chyba opravená, t. J. Zmenou jedného z konfiguračných súborov alebo vykonaním niektorých zmien kódu. To pomôže testovaciemu tímu pochopiť príčinu poruchy.

# 5) Vylepšenie procesu:

Aj keď v procese riešenia defektov sú defekty uprednostňované a opravené, z hľadiska procesu to neznamená, že defekty s nižšou prioritou nie sú dôležité a nemajú na systém veľký dopad. Z hľadiska zlepšenia procesu sú všetky zistené chyby rovnaké ako kritické.

na čo sa dnes používa c ++

Aj tieto menšie chyby poskytujú príležitosť naučiť sa, ako vylepšiť proces a zabrániť výskytu akýchkoľvek nedostatkov, ktoré môžu v budúcnosti ovplyvniť zlyhanie systému. Identifikácia chyby, ktorá má menší vplyv na systém, nemusí byť veľkým problémom, ale výskyt takejto chyby v systéme samotnom je veľkým problémom.

Aby sa zlepšil proces, musí sa každý v projekte obzrieť a skontrolovať, odkiaľ chyba pochádzala. Na základe toho môžete vykonať zmeny v procese overovania, v dokumente základnej podšívky, v procese kontroly, ktorý môže včas zachytiť chyby, ktoré sú lacnejšie.

Záver

Proces správy defektov by sa mal dodržiavať počas celého procesu vývoja softvéru, nielen pri konkrétnych testovacích alebo vývojových činnostiach.

Ak sa vyskytne chyba vo fáze testovania, je možné si položiť otázku, že ak sa chyba v tejto fáze zachytí, čo potom s ostatnými defektmi, ktoré sú v systéme živé a ktoré môžu spôsobiť zlyhanie systému, ak sa vyskytne a ešte sa neodhalí.

Je teda potrebné posilniť všetky procesy, ako je proces kontroly, statické testovanie, inšpekcia atď., A všetci v projekte by to mali myslieť vážne a v prípade potreby by mali prispieť. Vrcholový manažment v organizácii by mal tiež rozumieť a podporovať proces správy defektov.

Testovacie prístupy, proces preskúmania atď. By sa mali vyberať na základe cieľov projektu alebo organizačného procesu.

Dúfam, že vám tento informačný článok o procese správy chýb bude nesmierne nápomocný.

Odporúčané čítanie

^