defect severity priority testing with examples
V tomto tutoriále sa dozviete, čo je Závažnosť a Priorita defektov pri testovaní, ako nastaviť priority a závažnosť porúch pomocou príkladov, aby ste konceptu jasne porozumeli.
Ďalej sa podrobne zaoberáme tým, ako klasifikovať chyby podľa rôznych segmentov a ich významom v cykle Defect Life. Rozhodujúcej úlohe klasifikácie sa budeme venovať aj živým príkladom.
Evidencia chýb je veľmi neoddeliteľnou súčasťou súčasť životného cyklu testovania softvéru . Existuje definovaných niekoľko osvedčených postupov efektívne hlásenie chýb cez internet alebo v organizáciách.
Čo sa dozviete:
- Prehľad sledovania chýb
Prehľad sledovania chýb
Jedným z dôležitých aspektov životného cyklu chyby je sledovanie defektov. To je dôležité, pretože testovacie tímy otvárajú niekoľko chýb pri testovaní softvéru, ktorý sa znásobuje iba v prípade, že je konkrétny testovaný systém zložitý. V takomto scenári môže byť správa týchto defektov a analýza týchto defektov na ukončenie pohonu náročnou úlohou.
V súlade s procesmi údržby defektov, keď ktorýkoľvek tester zaznamená chybu - okrem metódy / popisu na reprodukciu zisteného problému, musí poskytnúť aj niektoré kategorické informácie, ktoré by pomohli nepresnej klasifikácii chyby. To by zase pomohlo pri efektívnych procesoch sledovania / údržby defektov a tiež by to tvorilo základ pre rýchlejšiu dobu na opravu defektov.
Dva hlavné parametre, ktoré tvoria základ pre efektívne sledovanie a riešenie chýb, sú:
- Priorita defektu pri testovaní
- Závažnosť chyby pri testovaní
Často ide o neprehľadný koncept a sú takmer zameniteľné nielen medzi testovacími tímami, ale aj vývojovými tímami. Medzi nimi je tenká hranica a je potrebné si uvedomiť, že medzi nimi skutočne existujú rozdiely.
Poďme si v krátkosti porozumieť teoretickým definíciám týchto dvoch parametrov.
Čo je závažnosť a priorita chyby?
Anglická definícia priority sa používa pri porovnávaní dvoch vecí alebo podmienok, keď sa jednej musí prikladať väčší význam ako iným (iným) a musí sa s ňou najskôr vyriešiť / vyriešiť, až potom sa treba venovať ďalším. Preto v kontexte vád by priorita vady naznačovala naliehavosť, s ktorou je potrebné ju napraviť.
Závažnosť podľa anglickej definície sa používa na opis závažnosti nežiaduceho výskytu. Pokiaľ teda ide o chyby, závažnosť chyby by naznačovala vplyv, ktorý má na systém z hľadiska jeho dopadu.
Kto ich definuje?
QA klasifikuje chybu podľa príslušnej závažnosti na základe zložitosti a kritickosti chýb.
Prioritu porúch definujú všetky zainteresované strany z oblasti podnikania vrátane projektových manažérov, obchodných analytikov a vlastníkov produktov.
Na nasledujúcom obrázku je znázornená rola, ktorá vlastní a klasifikuje závažnosť a závažnosť chýb.
Ako si zvoliť tieto úrovne?
Ako sme už diskutovali, parameter závažnosti hodnotí tester, zatiaľ čo prioritný parameter hodnotí hlavne produktový manažér alebo v zásade triediaci tím. Aj keď je to tak, závažnosť chyby je určite jedným z rozhodujúcich a ovplyvňujúcich faktorov pre určenie priority chyby. Preto je dôležité ako tester zvoliť správnu závažnosť, aby nedošlo k zámene s vývojovými tímami.
Rozdiel medzi závažnosťou a prioritou
Priorita je spojená s plánovaním a „závažnosť“ je spojená so štandardmi.
„Priorita“ znamená, že sa niečomu venuje alebo si zaslúži predchádzajúcu pozornosť; poradie podľa dôležitosti (alebo naliehavosti).
„Závažnosť“ je stav alebo kvalita závažnosti; prísne znamená dodržiavanie prísnych noriem alebo vysokých zásad a často naznačuje tvrdosť; závažné je poznačené alebo si vyžaduje prísne dodržiavanie prísnych noriem alebo vysokých zásad, Napríklad, prísny kódex správania.
Pri sledovaní chýb sa objavujú slová priorita a závažnosť.
K dispozícii je celý rad komerčných softvérových nástrojov na sledovanie a správu problémov. Tieto nástroje s podrobným vstupom inžinierov testujúcich softvér poskytujú tímu úplné informácie, aby vývojári mohli pochopiť chybu, získať predstavu o jej „závažnosti“, reprodukovať ju a opraviť.
Opravy sú založené na projekte „Priority“ a „Závažnosť“ chýb.
„Závažnosť“ problému je definovaná v súlade s hodnotením rizika zákazníka a zaznamenaná v jeho vybranom nástroji na sledovanie.
Buggy softvér môže „vážne“ ovplyvniť plány, čo môže naopak viesť k prehodnoteniu a opätovnému prerokovaniu „priorít“.
Čo je priorita?
Priorita, ako už názov napovedá, je o stanovení priority defektu na základe obchodných potrieb a závažnosti defektu. Priorita znamená dôležitosť alebo naliehavosť odstránenia chyby.
Pri otváraní chyby tester zvyčajne priraďuje prioritu spočiatku tomu, ako sa na produkt pozerá z pohľadu koncového používateľa. V súlade s nimi existujú rôzne úrovne:
Prioritu vád možno všeobecne klasifikovať takto:
Priorita č. 1) Okamžité / kritické (P1)
Toto musí byť opravené okamžite do 24 hodín. Spravidla k tomu dochádza v prípadoch, keď je zablokovaná celá funkčnosť a v dôsledku toho nemôže pokračovať žiadne testovanie. Alebo v určitých iných prípadoch, ak dôjde k významným únikom pamäte, potom sa chyba všeobecne klasifikuje ako priorita -1, čo znamená, že program / funkcia je v súčasnom stave nepoužiteľná.
Akákoľvek chyba, ktorá si vyžaduje okamžitú pozornosť a ktorá má vplyv na proces testovania, bude klasifikovaná do okamžitej kategórie
Všetko Kritická závažnosť chyby spadajú do tejto kategórie (pokiaľ podniky / zainteresované strany nedajú prioritu znova)
Priorita č. 2) Vysoká (P2)
Po odstránení kritických defektov je defekt s touto prioritou ďalším kandidátom, ktorý musí byť opravený pre každú testovaciu činnosť, aby zodpovedal kritériám „ukončenia“. Normálne, keď funkcia nie je použiteľná tak, ako má, kvôli chybe programu alebo napísaniu nového kódu alebo niekedy dokonca aj preto, že je potrebné prostredníctvom kódu vyriešiť nejaký problém so životným prostredím, môže mať chyba nárok na prioritu 2. .
Toto je chyba alebo problém, ktoré by sa mali vyriešiť pred vydaním. Tieto chyby by sa mali vyriešiť po vyriešení kritických otázok.
Všetko Major závažnosť chyby spadajú do tejto kategórie.
Priorita č. 3) Stredná (P3)
Poruchu s touto prioritou je potrebné opraviť, pretože by mohla riešiť aj problémy s funkčnosťou, ktoré nie sú podľa očakávania. Niekedy sa aj kozmetické chyby, ako napríklad očakávanie správneho chybového hlásenia počas poruchy, môžu kvalifikovať ako chyba priority 3.
Táto chyba by mala byť vyriešená po odstránení všetkých závažných chýb.
Keď už sú chyby Critical a High priority hotové, môžeme prejsť na chyby so strednou prioritou.
Všetko Menšie závažnosť chyby spadajú do tejto kategórie.
Priorita č. 4) Nízka (P4)
Porucha s nízkou prioritou naznačuje, že určite ide o problém, ale nemusí byť opravený, aby zodpovedal kritériám „ukončenia“. To však musí byť opravené pred vykonaním GA. Typicky by tu mohli byť kategorizované niektoré chyby pri písaní alebo dokonca kozmetické chyby, o ktorých sme hovorili vyššie.
Niekedy sa tiež otvárajú chyby s nízkou prioritou, aby sa navrhli určité vylepšenia existujúceho dizajnu alebo požiadavka na implementáciu malej funkcie na zlepšenie používateľského zážitku.
Táto chyba sa dá vyriešiť v budúcnosti a nevyžaduje okamžitú pozornosť a Nízka závažnosť chyby spadajú do tejto kategórie.
Ako už bolo spomenuté, priorita určuje, ako rýchlo musí byť doba na vykonanie závady. Ak sa vyskytne viac chýb, priorita rozhodne, ktorá chyba musí byť opravená a okamžite overená oproti ktorej poruchu je možné opraviť o niečo neskôr.
Čo je to závažnosť?
Závažnosť definuje rozsah, v akom by konkrétna chyba mohla mať vplyv na aplikáciu alebo systém.
Závažnosť je parameter označujúci implikáciu chyby na systém - aká závažná je chyba a aký je vplyv chyby na funkčnosť celého systému? Závažnosť je parameter nastavený testerom, keď otvára poruchu, a má hlavne kontrolu nad testerom. Rôzne organizácie majú opäť rôzne nástroje, ktoré sa dajú použiť pri chybách, ale na všeobecnej úrovni ide o tieto úrovne závažnosti:
Napríklad, Zvážte nasledujúce scenáre
- Ak sa používateľ pokúsi nakupovať online a aplikácia sa nenačíta alebo sa zobrazí správa o nedostupnosti servera.
- Používateľ vykoná pridanie položky do košíka, počet pridaných množstiev je nesprávny / nesprávny.
- Používateľ uskutoční platbu a po zaplatení zostane objednávka v košíku ako potvrdená namiesto rezervácie.
- Systém objednávku prijme, ale nakoniec z dôvodu akýchkoľvek problémov objednávku po pol hodine zruší.
- Systém akceptuje príkaz „Pridať do košíka“ iba dvojitým kliknutím, nie jediným kliknutím.
- Tlačidlo Pridať do košíka sa píše ako Pridať do košíka.
Aký by bol dojem používateľa, ak by sa mohol vyskytnúť niektorý z vyššie uvedených scenárov?
rozdiel medzi testovaním verzie alfa a beta
Poruchy možno v zásade klasifikovať takto:
# 1) Kritické (S1)
Porucha, ktorá úplne obmedzuje alebo blokuje testovanie produktu / funkcie, je kritickou chybou. Príkladom by mohol byť prípad testovania používateľského rozhrania, keď po prechode sprievodcom používateľské rozhranie iba visí na jednom paneli alebo nejde ďalej, aby spustilo funkciu. Alebo v niektorých iných prípadoch, keď samotná vyvinutá funkcia v zostavení chýba.
Z nejakého dôvodu, ak aplikácia havaruje alebo sa stane nepoužiteľnou / schopnou pokračovať ďalej, je možné chybu klasifikovať pod kritickú závažnosť.
Akékoľvek katastrofické poruchy systému by mohli viesť používateľa k nepoužiteľnosti aplikácií a mohli by byť klasifikované podľa závažnosti
Napríklad, V prípade poskytovateľa e-mailových služieb, ako je Yahoo alebo Gmail, po zadaní správneho používateľského mena a hesla systém namiesto prihlásenia zlyhá alebo vyhodí chybové hlásenie, táto chyba je klasifikovaná ako kritická, pretože spôsobuje, že celá aplikácia je nepoužiteľná.
Scenár uvedený v bode 1 by sa dal klasifikovať ako kritický nedostatok, pretože online aplikácia sa stáva úplne nepoužiteľnou.
# 2) Hlavné (S2)
Akákoľvek implementovaná hlavná funkcia, ktorá nespĺňa svoje požiadavky / prípady použitia a správa sa inak, ako sa očakávalo, je možné klasifikovať podľa závažnosti.
Hlavná chyba sa vyskytne, keď funkčnosť funguje hrubo mimo očakávaní alebo keď nerobí to, čo by mala robiť. Môže to byť napríklad: Povedzte, že na prepínači je potrebné nasadiť sieť VLAN a používate šablónu používateľského rozhrania, ktorá spúšťa túto funkciu. Keď táto šablóna na konfiguráciu VLAN na prepínači zlyhá, bude klasifikovaná ako nevýhoda závažnej funkčnosti.
Napríklad, Ak u poskytovateľa e-mailových služieb, ako je Yahoo alebo Gmail, nemôžete pridať do sekcie CC viac ako jedného príjemcu, táto chyba sa klasifikuje ako veľká chyba, pretože hlavná funkčnosť aplikácie nefunguje správne.
Očakávané správanie sekcie CC v pošte by malo používateľovi umožniť pridať viacerých používateľov. Ak teda hlavná funkčnosť aplikácie nefunguje správne alebo sa správa inak, ako sa očakávalo, jedná sa o závažnú chybu.
Scenáre uvedené v bodoch 2 a 3, ktoré sa diskutujú vyššie, by sa dali klasifikovať ako závažné chyby, pretože sa očakáva, že objednávka plynule prejde do ďalšej fázy životného cyklu objednávky, ale v skutočnosti sa líši v správaní.
Akákoľvek chyba, ktorá by mohla viesť k nesprávnemu pretrvávaniu údajov, problémom s údajmi alebo nesprávnemu správaniu aplikácie, by sa dala zhruba klasifikovať podľa závažnosti závažnosti.
# 3) Malé / Stredné (S3)
Akákoľvek implementovaná funkcia, ktorá nespĺňa svoje požiadavky / prípady použitia a správa sa odlišne, ako sa očakávalo, ale vplyv je do istej miery zanedbateľný alebo nemá zásadný vplyv na aplikáciu, je možné klasifikovať pod Menšiu závažnosť.
Mierna chyba sa vyskytne, keď produkt alebo aplikácia nespĺňa určité kritériá alebo sa stále vyznačuje neprirodzeným správaním. Nie je však ovplyvnená funkčnosť ako celok. Napríklad vo vyššie nasadenej šablóne VLAN by sa vyskytla stredná alebo normálna chyba, keď sa šablóna úspešne nasadí na prepínači, avšak používateľovi sa neposiela nijaká indikácia.
otázky na pohovor s mydlom a pokojnými webovými službami
Napríklad, V poskytovateľovi e-mailových služieb, ako je Yahoo alebo Gmail, existuje možnosť s názvom „Podmienky“ a v tejto možnosti bude niekoľko odkazov týkajúcich sa podmienok a webových stránok. Ak jeden z viacerých odkazov nefunguje, nazýva sa to ako menšia závažnosť, pretože ovplyvňuje iba malú funkčnosť aplikácie a nemá veľký vplyv na použiteľnosť aplikácie.
Scenár v bode 5, ktorý sme diskutovali vyššie, by sa dal klasifikovať ako menší nedostatok, pretože nedochádza k strate alebo zlyhaniu údajov v poradí toku systému, ale k miernym nepríjemnostiam, pokiaľ ide o skúsenosti používateľov.
Výsledkom týchto typov defektov je minimálna strata funkčnosti alebo skúsenosti používateľov.
# 4) Nízka (S4)
Akékoľvek kozmetické chyby vrátane pravopisných chýb alebo problémov so zarovnaním alebo veľkosť písma môžu byť klasifikované podľa stupňa závažnosti.
Menšia chyba závažnosti sa vyskytuje, keď nemá takmer žiadny vplyv na funkčnosť, ale stále ide o platný nedostatok, ktorý by sa mal opraviť. Príkladom toho môžu byť pravopisné chyby v chybových správach vytlačených používateľom alebo chyby na zlepšenie vzhľadu a dojmu funkcie.
Napríklad, U poskytovateľa e-mailových služieb, ako je Yahoo alebo Gmail, by ste si všimli „Licenčnú stránku“. Ak sa na stránke nachádzajú pravopisné chyby alebo nesprávne zarovnanie, je táto chyba klasifikovaná ako nízka.
Scenár v bode 6, ktorý sme diskutovali vyššie, by sa dal klasifikovať ako slabý, pretože tlačidlo Pridať sa zobrazuje v nesprávnych prípadoch. Tento druh chyby nebude mať žiadny vplyv na správanie systému alebo na prezentáciu údajov alebo na stratu alebo tok údajov alebo dokonca na dojem používateľa, ale bude veľmi kozmetický.
Ak to zhrnieme, nasledujúci obrázok zobrazuje širokú klasifikáciu defektov na základe závažnosti a priority:
Príklady
Ako už bolo spomenuté, keďže rôzne organizácie používajú rôzne druhy nástrojov na sledovanie chýb a súvisiace procesy, stáva sa z nich spoločný systém sledovania medzi rôznymi úrovňami riadenia a technickým personálom.
Pretože Závažnosť chyby je skôr v kompetencii funkčnosti, Testovací inžinier stanoví závažnosť chyby. Vývojári sa občas podieľajú na ovplyvňovaní závažnosti chyby, ale väčšinou to závisí od testera, ktorý hodnotí, ako veľmi môže konkrétna vlastnosť ovplyvniť celkové fungovanie.
Na druhej strane, pokiaľ ide o nastavenie priority defektu, hoci pôvodne určuje pôvodca chyby prioritu, v skutočnosti ju definuje produktový manažér, pretože má celkový prehľad o produkte a o tom, ako rýchlo treba konkrétnu chybu vyriešiť . Tester nie je ideálnou osobou na stanovenie priority defektu.
Ako sa to môže zdať šokujúce, existujú dva odlišné príklady, prečo:
Príklad č) Zvážte, že existuje situácia, keď používateľ zistí chybu v pomenovaní samotného produktu alebo nejaký problém s dokumentáciou používateľského rozhrania. Tester by za normálnych okolností otvoril malú / kozmetickú chybu a jeho odstránenie by bolo veľmi jednoduché, ale pokiaľ ide o vzhľad a dojem z produktu / dojem používateľa, mohlo by to spôsobiť vážny dopad.
Príklad č) Môžu sa vyskytnúť určité podmienky, za ktorých sa vyskytne konkrétna chyba, ktorá môže byť v prostredí zákazníka extrémne zriedkavá alebo nemusí byť vôbec zasiahnuteľná. Aj keď sa to z hľadiska funkčnosti môže testerovi javiť ako nedostatok s vysokou prioritou, vzhľadom na jeho zriedkavosť výskytu a vysoké náklady na jeho opravu - bude sa to klasifikovať ako nedostatok s nízkou prioritou.
Z tohto dôvodu je priorita defektu vo všeobecnosti nastavená produktovým manažérom na schôdzi s názvom „defect triage“.
Rôzne úrovne
Priorita a závažnosť majú medzi sebou určité klasifikácie, ktoré pomáhajú pri určovaní spôsobu riešenia chyby. Mnoho rôznych organizácií má rôzne nástroje na zaznamenávanie chýb , takže úrovne sa môžu líšiť.
Pozrime sa na rôzne úrovne pre prioritu aj závažnosť.
- Vysoká priorita, vysoká závažnosť
- Vysoká priorita, nízka závažnosť
- Vysoká závažnosť, nízka priorita
- Nízka závažnosť, nízka priorita
Nasledujúci obrázok zobrazuje klasifikáciu kategórií v jednom úryvku.
# 1) Vysoká závažnosť a vysoká priorita
Akékoľvek kritické alebo závažné zlyhanie obchodného prípadu sa automaticky postúpi do tejto kategórie.
Všetky chyby, kvôli ktorým nemôže testovanie za každú cenu pokračovať alebo nespôsobia vážne zlyhanie systému, spadajú do tejto kategórie. Napríklad, kliknutie na konkrétne tlačidlo nenačíta samotnú funkciu. Alebo vykonávanie konkrétnej funkcie spôsobí, že server bude dôsledne klesať a spôsobovať stratu údajov. Červené čiary na vyššie uvedenom obrázku označujú tieto druhy chýb.
Napríklad,
Systém zlyhá po vykonaní platby alebo keď nemôžete pridať položky do košíka, táto chyba je označená ako chyba vysokej závažnosti a vysokej priority.
Ďalší príklad by bola funkcia predajnej meny bankomatu, kde po zadaní správneho používateľského mena a hesla automat nevydáva peniaze, ale odpočítava prevedené prostriedky z vášho účtu.
# 2) Vysoká priorita a nízka závažnosť
Do tejto kategórie sa automaticky dostanú akékoľvek menšie chyby závažnosti, ktoré by mohli priamo ovplyvniť používateľskú skúsenosť.
Do tejto kategórie patria chyby, ktoré je potrebné opraviť, ale nemajú vplyv na aplikáciu.
Napríklad, očakáva sa, že funkcia zobrazí používateľovi konkrétnu chybu, pokiaľ ide o jej návratový kód. V takom prípade funkčne kód vyvolá chybu, ale správa bude musieť byť relevantnejšia pre vygenerovaný návratový kód. Modré čiary na obrázku označujú tieto druhy chýb.
Napríklad,
Logo spoločnosti na titulnej stránke je nesprávne, považuje sa za Vysoká priorita a nízka závažnosť vada .
Príklad 1) Ak je na webe Online nakupovanie nesprávne napísané logo FrontPage, napríklad namiesto Flipkartu je napísané ako Flipkart.
Príklad 2) V logu banky je namiesto ICICI napísaný ako ICCCI.
Z hľadiska funkčnosti to nič neovplyvňuje, takže môžeme označiť ako Nízku závažnosť, ale má to vplyv na užívateľskú skúsenosť. Tento druh defektu je potrebné opraviť s vysokou prioritou, aj keď má veľmi malý dopad na stránku aplikácie.
# 3) Vysoká závažnosť a nízka priorita
Do tejto kategórie sa automaticky dostane akýkoľvek nedostatok, ktorý funkčne nespĺňa požiadavky alebo nemá žiadny funkčný dopad na systém, ale ktorý je zainteresovaný stranami odsunutý na vedľajšiu koľaj, pokiaľ ide o obchodnú kritickosť.
Poruchy, ktoré musia byť odstránené, ale nie okamžite. Toto sa môže konkrétne vyskytnúť počas ad-hoc testovania. To znamená, že funkčnosť je ovplyvnená do značnej miery, ale je pozorovaná iba pri použití určitých neobvyklých vstupných parametrov.
Napríklad, konkrétnu funkcionalitu je možné použiť až v novšej verzii firmvéru, aby sa to overilo - tester skutočne zníži úroveň svojho systému a vykoná test a zistí závažný funkčný problém, ktorý je platný. V takom prípade budú chyby klasifikované v tejto kategórii označenej ružovými čiarami, pretože sa bežne očakáva, že koncoví používatelia budú mať vyššiu verziu firmvéru.
Napríklad,
Ak na stránkach sociálnych sietí vyjde beta verzia novej funkcie, ktorá od dnešného dňa túto funkciu nevyužíva veľa aktívnych používateľov. Akýkoľvek nedostatok zistený na tejto funkcii je možné klasifikovať ako nízku prioritu, pretože táto funkcia ustupuje z dôvodu obchodnej klasifikácie ako nepodstatnej.
Aj keď táto funkcia má funkčnú chybu, pretože nemá priamy vplyv na koncových zákazníkov, môže zúčastnená strana v podnikaní klasifikovať chybu pod nízku prioritu, hoci má závažný funkčný vplyv na aplikáciu.
Toto je chyba vysokej závažnosti, ale dá sa uprednostniť pred nízkou prioritou, pretože sa dá opraviť v nasledujúcom vydaní ako požiadavka na zmenu. Zainteresované subjekty v podnikaní tiež uprednostňujú túto funkciu ako zriedka používanú funkciu a neovplyvňujú žiadne ďalšie funkcie, ktoré majú priamy vplyv na používateľskú skúsenosť. Tento druh poruchy možno zatriediť pod Vysoká závažnosť, ale nízka priorita kategórie.
# 4) Nízka závažnosť a nízka priorita
Akékoľvek pravopisné chyby / veľkosť písma / nesprávna zarovnanie v odseku 3rdalebo 4thstránke aplikácie a nie na hlavnej alebo prednej strane / titule.
Tieto chyby sú klasifikované zelenými čiarami, ako je to znázornené na obrázku, a vyskytujú sa, keď nie je žiadny vplyv na funkčnosť, ale napriek tomu v malej miere nespĺňajú normy. Spravidla sú tu klasifikované kozmetické chyby alebo povedzme rozmery bunky v tabuľke používateľského rozhrania.
Napríklad,
Ak má politika ochrany osobných údajov webovej stránky pravopisnú chybu, táto chyba je nastavená ako Nízka závažnosť a nízka priorita.
Usmernenia
Ďalej uvádzame určité pokyny, ktoré sa musí každý tester snažiť dodržiavať:
- Najskôr dobre pochopte pojmy priorita a závažnosť. Vyvarujte sa zámene jedného s druhým a ich vzájomného používania. V súlade s tým postupujte podľa pokynov na zabezpečenie závažnosti zverejnených vašou organizáciou / tímom, aby boli všetci na jednej stránke.
- Úroveň závažnosti vždy vyberte na základe typu problému, pretože to ovplyvní jeho prioritu. Niektoré príklady:
- V prípade problému, ktorý je kritický, napríklad pri výpadku celého systému a nemožno nič robiť - táto závažnosť by sa nemala používať na riešenie chýb programu.
- V prípade problému, ktorý je zásadný, napríklad v prípadoch, keď funkcia nefunguje podľa očakávania - by sa táto závažnosť mohla použiť na riešenie nových funkcií alebo na zlepšenie súčasného fungovania.
Pamätajte, že výber správnej úrovne závažnosti bude mať za následok poruchu, je to náležitá priorita.
- Ako tester - porozumieť tomu, ako konkrétna funkcionalita postupuje ďalej - pochopiť, ako by konkrétny scenár alebo testovací prípad ovplyvnil koncového používateľa. To si vyžaduje veľa spolupráce a interakcie s vývojovým tímom, obchodnými analytikmi, architektmi, testovacím vedúcim a vývojovým vedením. Pri svojich diskusiách musíte brať do úvahy aj to, koľko času by trvalo odstránenie chyby, a to na základe jej zložitosti a času na jej overenie.
- Nakoniec , vždy je to produktový vlastník, ktorý má vetovacie právo na uvoľnenie, chyba by mala byť opravená. Pretože však relácie triedenia defektov obsahujú rôznych členov, ktorí prezentujú svoju perspektívu defektu na konkrétnom prípade, v prípade synchronizácie vývojárov a testerov to určite pomôže pri ovplyvňovaní rozhodnutia.
Záver
Pri otváraní defektov je zodpovednosťou testera, aby chybám určil správnu závažnosť. Nesprávna závažnosť, a teda mapovanie priorít, môže mať veľmi drastické dôsledky na celkový proces STLC a produkt ako celok. Na niekoľkých pracovných pohovoroch - existuje niekoľko otázok, ktoré sa pýtajú na prioritu a závažnosť, aby sa zabezpečilo, že ako tester budete mať tieto koncepty dokonale čisté vo svojej mysli.
Tiež sme videli živé príklady toho, ako klasifikovať chybu podľa rôznych segmentov závažnosti / priority. Teraz by som si prial, aby ste mali dostatok objasnenia o klasifikácii defektov v oboch stupňoch závažnosti / priority.
Dúfam, že tento článok je kompletným sprievodcom po porozumení úrovní priority a závažnosti defektov. Dajte nám vedieť svoje myšlienky / otázky v komentároch nižšie.
Odporúčané čítanie
- Čo je to technika testovania na základe chýb?
- Čo je životný cyklus chyby / chyby v testovaní softvéru? Výukový program pre poruchu životného cyklu
- Proces správy defektov: Ako efektívne riadiť defekty
- Ako reprodukovať nereprodukovateľný nedostatok a dosiahnuť, aby vaše testovacie úsilie stálo za to
- 7 princípov testovania softvéru: zhlukovanie defektov a Paretov princíp
- Metódy a techniky prevencie defektov
- Presný rozdiel medzi overením a overením pomocou príkladov
- 3 stratégie riešenia chyby blokátora