Мени

Озбиљност и приоритет у испитивању са примерима и разликама

defect severity priority testing with examples

Испробајте Наш Инструмент За Елиминисање Проблема

У овом упутству ћете научити шта су озбиљност и приоритет оштећења у тестирању, како поставити приоритете и ниво озбиљности недостатака са примерима да бисте јасно разумели концепт.

Такође ћемо детаљно објаснити како класификовати недостатке у различите сегменте и њихову важност у циклусу оштећења. Такође ћемо покрити пресудну улогу класификације живим низом примера.

Дефекти у архивирању су врло битни део животног циклуса тестирања софтвера . Постоји неколико најбољих пракси дефинисаних за ефикасно извештавање о недостацима преко Интернета или у организацијама.

Тежина и приоритет недостатака

Шта ћете научити:

Преглед праћења кварова

Један од важних аспеката животног циклуса оштећења на генеричком нивоу укључује праћење недостатака. Ово је важно јер тест тимови отварају неколико недостатака приликом тестирања софтверског дела који се множи само ако је одређени систем који се тестира сложен. У таквом сценарију, управљање овим недостацима и њихова анализа са циљем затварања може бити застрашујући задатак.

У складу са процесима одржавања квара, када било који испитивач пријави квар - осим методе / описа како би репродуковао уочени проблем, он мора да пружи и неке категоричне информације које би помогле нетачној класификацији квара. То би, пак, помогло у ефикасном процесу праћења / одржавања квара и такође би представљало основу за брже време отклањања квара.

Два главна параметра која чине основу за ефикасно праћење и решавање недостатака су:

  • Приоритет недостатака у испитивању
  • Тежина оштећења у испитивању

То су често збуњујући концепт и готово се наизменично користе не само међу испитним тимовима већ и међу развојним тимовима. Између њих постоји танка линија и важно је схватити да заиста постоје разлике између њих двоје.

Хајде да укратко разумемо теоријске дефиниције два параметра у следећем одељку.

Шта је озбиљност и приоритет недостатака?

Приоритет према енглеској дефиницији користи се у поређењу две ствари или услова, где се једном мора дати већа важност од другог (их) и прво се мора решити / решити пре него што се пређе на следећи (е). Стога би у контексту недостатака приоритет квара указивао на хитност којом би га требало отклонити.

Озбиљност се према енглеској дефиницији користи за описивање тежине нежељене појаве. Дакле, када је реч о грешкама, озбиљност грешке би указала на њен ефекат на систем у смислу његовог утицаја.

Ко их дефинише?

КА класификује дефект под одговарајућу тежину на основу сложености и критичности дефеката.

Сви заинтересовани за пословање, укључујући руководиоце пројеката, пословне аналитичаре, власника производа, дефинишу приоритет недостатака.

Доња слика приказује улогу ко је власник и класификује критичност и тежину недостатака.

СЕВЕРНОСТ И ПРИОРИТЕТ

шта је ВиФи безбедносни кључ

Како одабрати ове нивое?

Као што смо већ разговарали, испитивач процењује параметар озбиљности, док параметар приоритета углавном процењује менаџер производа или у основи тим за тријажу. Иако је то случај, тежина дефекта је дефинитивно један од водећих и утицајних фактора за одређивање приоритета дефекта. Отуда је важно као тестера одабрати праву тежину како би се избегла забуна са развојним тимовима.

Разлика између тежине и приоритета

Приоритет је повезан са заказивањем, а „озбиљност“ је повезана са стандардима.

„Приоритет“ значи да се нешто приушћује или заслужује претходну пажњу; првенство утврђено према редоследу важности (или хитности).

„Озбиљност“ је стање или квалитет озбиљности; озбиљан подразумева придржавање ригорозних стандарда или високих принципа и често сугерише грубост; озбиљан је обележен или захтева строго поштовање ригорозних стандарда или високих принципа, На пример, тешки кодекс понашања.

Речи приоритет и озбиљност појављују се у праћењу грешака.

Доступни су разни комерцијални софтверски алати за праћење и управљање проблемима. Ови алати, уз детаљан унос инжењера за тестирање софтвера, дају тиму потпуне информације како би програмери могли да разумеју грешку, стекну представу о њеној „озбиљности“, репродукују је и исправе.

Исправке се заснивају на пројекту „Приоритети“ и „Озбиљност“ грешака.

„Тежина“ проблема је дефинисана у складу са проценом ризика купца и евидентирана у одабраном алату за праћење.

Бугги софтвер може „озбиљно“ утицати на распореде, што заузврат може довести до поновне процене и поновног преговарања о „приоритетима“.

Шта је приоритет?

Приоритет је, као што и само име говори, приоритет одређивању квара на основу пословних потреба и тежине квара. Приоритет означава важност или хитност отклањања недостатка.

Док отвара квар, испитивач обично у почетку додељује приоритет док производ гледа из перспективе крајњег корисника. У складу са њима постоје различити нивои:

Опћенито, приоритет оштећења може се класификовати на сљедећи начин:

Приоритет бр. 1) Непосредан / критичан (П1)

Ово се мора поправити одмах у року од 24 сата. То се обично дешава у случајевима када је целокупна функционалност блокирана и као резултат тога не може се наставити тестирање. Или у одређеним другим случајевима ако постоје значајна цурења меморије, тада је квар генерално класификован као приоритет -1 што значи да је програм / функција неупотребљива у тренутном стању.

Било који недостатак којем је потребна непосредна пажња и који утиче на поступак испитивања класификоваће се у непосредну категорију

Све Критична тежина недостаци спадају у ову категорију (осим ако их предузећа / заинтересоване стране не одреде по приоритету)

Приоритет # 2) Висок (П2)

Једном када се отклоне критични кварови, квар који има овај приоритет је следећи кандидат који мора бити отклоњен за било коју тест активност да би одговарао критеријумима „изласка“. Обично када карактеристика није употребљива онаква каква би требало да буде због програмске неисправности или због тога што се нови код мора написати или понекад чак и због тога што се кроз код мора решити неки еколошки проблем, квар се може квалификовати за приоритет 2 .

Ово је квар или проблем који би требало решити пре издавања. Ове недостатке треба решити када се реше критична питања.

Све Главни озбиљности дефекти спадају у ову категорију.

Приоритет бр. 3) Средњи (П3)

Неисправност са овим приоритетом мора бити спорна да би се отклонила, јер би се могла бавити и проблемима с функционалношћу који нису према очекивањима. Понекад се чак и козметичке грешке, попут очекивања праве поруке о грешци током неуспеха, могу квалификовати као приоритетна 3 грешка.

Овај квар треба отклонити након што се отклоне све озбиљне грешке.

Једном када се заврше критичне грешке и грешке високог приоритета, можемо се одлучити за грешке средњег приоритета.

Све Минор озбиљности дефекти спадају у ову категорију.

Приоритет # 4) Низак (П4)

Квар са ниским приоритетом указује на то да сигурно постоји проблем, али не мора бити отклоњен да би одговарао критеријумима „изласка“. Међутим, ово се мора поправити пре него што се изврши ГА. Овде се обично могу категорисати неке грешке у куцању или чак козметичке грешке о којима је раније било речи.

Понекад се отварају и недостаци са ниским приоритетом да би се предложила нека побољшања у постојећем дизајну или захтев за примену мале функције за побољшање корисничког искуства.

Овај квар се може решити у будућности и не треба му непосредна пажња Ниска озбиљност дефекти спадају у ову категорију.

Као што је већ речено приоритет одређује колико брзо мора бити време отклањања квара. Ако постоји више недостатака, приоритет одлучује који недостатак мора бити отклоњен и одмах верификован наспрам тога који се недостатак може отклонити нешто касније.

Нивои приоритета и тежине недостатака

Шта је озбиљност?

Озбиљност дефинише у којој мери би одређени недостатак могао створити утицај на апликацију или систем.

Озбиљност је параметар који означава импликацију квара на систем - колико је квар критичан и какав је утицај квара на функционалност целог система? Озбиљност је параметар који поставља тестер док он отвара квар и углавном контролише тестера. Опет, различите организације имају различите алате за употребу код недостатака, али на генеричком нивоу то су следећи нивои озбиљности:

На пример, Размотрите следеће сценарије

  • Ако корисник покуша да изврши куповину на мрежи, а апликација се не учита или се појави порука о недоступности сервера.
  • Корисник врши додавање предмета у корпу, број додатих количина је нетачан / додаје се погрешан производ.
  • Корисник врши уплату, а након уплате, наруџба остаје у колицима онако како је резервисана, а потврђена.
  • Систем прихвата поруџбину, али коначно, отказује је након пола сата због било каквих проблема.
  • Систем прихвата „Додај у корпу“ само двоструким кликом уместо једним кликом.
  • Дугме Додај у корпу пише се као Додај у корпу.

Какво би било корисничко искуство ако би се могао догодити било који од горе наведених сценарија?

Широко се недостаци могу класификовати на следећи начин:

# 1) Критично (С1)

Квар који у потпуности отежава или блокира тестирање производа / карактеристике је критичан недостатак. Пример би могао бити у случају тестирања корисничког интерфејса, када након проласка кроз чаробњак, кориснички интерфејс само виси у једном окну или не иде даље да покреће функцију. Или у неким другим случајевима, када карактеристика која је сама развијена недостаје у изради.

Из било ког разлога, ако се апликација сруши или постане неупотребљива / не може даље да се креће, квар се може класификовати под критичном тежином.

Било који катастрофални квар на систему могао би довести корисника до неупотребљивости апликација и могао би се класификовати под критичну тежину

На пример, У добављачу услуга е-поште попут Иахоо-а или Гмаил-а, након уношења тачног корисничког имена и лозинке, систем се, уместо пријављивања, сруши или баци поруку о грешци, а овај квар је класификован као критичан, јер овај квар чини целу апликацију неупотребљивом.

Горе разматрани сценарио о тачки 1 могао би се класификовати као критични недостатак, јер мрежна апликација постаје потпуно неупотребљива.

# 2) Мајор (С2)

Било која главна карактеристика која је примењена и која не испуњава своје захтеве / случајеве употребе и понаша се другачије од очекиваног, може се класификовати под озбиљност озбиљности.

Главни недостатак се јавља када функционалност функционише далеко од очекивања или не ради оно што би требало да ради. Пример би могао бити: Рецимо да ВЛАН треба да се примени на прекидачу и да користите УИ образац који покреће ову функцију. Када овај предложак за конфигурисање ВЛАН-а не успе на прекидачу, он се класификује као озбиљан недостатак функционалности.

На пример, Када добављач услуга е-поште попут Иахоо-а или Гмаил-а не сме да дода више од једног примаоца у одељак ЦЦ, овај квар је класификован као Главни квар јер главна функционалност апликације не ради исправно.

Оно што се очекује од понашања ЦЦ одељка у пошти, требало би да омогући кориснику да дода више корисника. Дакле, када главна функционалност апликације не ради исправно или се понаша другачије од очекиваног, то је главни недостатак.

Горе поменути сценарији у тачкама 2 и 3 могли би се класификовати као главни недостаци, јер се очекује да ће се ред глатко пребацити у следећу фазу животног циклуса налога, али у стварности се разликује у понашању.

Било који недостатак који би могао довести до нетачне постојаности података, проблема са подацима или погрешног понашања апликације могао би се широко класификовати под главном тежином.

# 3) Мало / средње (С3)

Свака примењена карактеристика која не испуњава своје захтеве / случајеве употребе и понаша се другачије од очекиваног, али је утицај донекле занемарљив или нема већи утицај на апликацију, може се класификовати у категорију Мала тежина.

Умерени недостатак се јавља када производ или апликација не испуњава одређене критеријуме или још увек показује неприродно понашање, међутим, то не утиче на функционалност у целини. На пример, у горенаведеној примени ВЛАН предлошка, дошло би до умерене или нормалне грешке када се предложак успешно примени на прекидачу, међутим, нема индикације која се шаље кориснику.

На пример, У добављачу услуга е-поште попут Иахоо-а или Гмаил-а постоји опција која се назива „Услови и одредбе“ и у тој опцији ће бити више веза у вези са условима и условима веб локације. Када једна од више веза не ради добро, назива се мањом озбиљношћу, јер утиче само на мању функционалност апликације и нема велики утицај на употребљивост апликације.

Горе разматрани сценарио из тачке 5 могао би се класификовати као Мањи недостатак, јер нема губитка или неуспеха података у редоследу тока система, али је мало непријатности када је реч о корисничком искуству.

Ове врсте кварова резултирају минималним губитком функционалности или корисничког искуства.

# 4) Низак (С4)

Било који козметички недостаци, укључујући правописне грешке или проблеме са поравнавањем или кућиште фонта, могу се класификовати под категорију Ниска тежина.

До мање грешке мале озбиљности долази када готово да нема утицаја на функционалност, али свеједно је то ваљани квар који треба исправити. Примери овога могу да укључују правописне грешке у порукама о грешкама које се штампају корисницима или недостатке ради побољшања изгледа и осећаја функције.

На пример, У добављачу услуга е-поште попут Иахоо-а или Гмаил-а, приметили бисте „страницу са лиценцом“. Ако на страници постоје правописне грешке или неусклађеност, овај квар је класификован као низак.

Горе описани сценарио из тачке 6 могао би се класификовати као Лов Дефецт, јер је дугме Адд приказано у погрешном кућишту. Ова врста квара неће имати утицаја на понашање система или презентацију података или губитак података или проток података, па чак ни на корисничко искуство, али ће бити врло козметичка.

Приоритет и тежина недостатака

Да резимирамо, следећа слика приказује широку класификацију дефеката засновану на тежини и приоритету:

Класификација дефеката

Примери

Као што је већ поменуто, будући да различите организације користе различите врсте алата за праћење кварова и с њима повезане процесе, то постаје уобичајени систем праћења између различитих нивоа менаџмента и техничког особља.

Будући да је озбиљност недостатака више у делокругу функционалности, инжењер за испитивање поставља тежину недостатка. Понекад програмери учествују у утицају на тежину квара, али углавном то зависи од тестера док процењује колико одређена карактеристика може утицати на целокупно функционисање.

С друге стране, што се тиче постављања приоритета квара, иако у почетку извор дефекта поставља приоритет, менаџер производа га заправо дефинише јер он има целокупан поглед на производ и колико брзо се одређени квар мора отклонити . Испитивач није идеална особа за постављање приоритета квара.

Колико год ово изгледало шокантно, постоје два различита примера зашто:

Пример # 1) Узмите у обзир да постоји ситуација када корисник пронађе грешку у именовању самог производа или неки проблем са УИ документацијом. Испитивач би обично открио мању / козметичку ману и могао би бити врло једноставан за отклањање, али када је реч о изгледу и осећају производа / корисничком искуству, то би могло да изазове озбиљан утицај.

Пример # 2) Могу постојати одређени услови под којима се дешава одређена неисправност која може бити изузетно ретка или нема могућности да се погоди у окружењу купца. Иако се функционално ово тестеру може чинити као квар високог приоритета, с обзиром на реткост појављивања и високу цену отклањања - ово би било класификовано као квар ниског приоритета.

Стога у ствари приоритет квара генерално поставља менаџер производа на састанку „тријаже квара“.

Различити нивои

Приоритет и тежина имају неке класификације које помажу у одређивању начина на који се дефект мора решити. Много различитих организација има различити алати за евидентирање кварова , тако да се нивои могу разликовати.

Погледајмо различите нивое и приоритета и озбиљности.

  • Високи приоритет, велика озбиљност
  • Високи приоритет, мала тежина
  • Висока тежина, низак приоритет
  • Ниска тежина, низак приоритет

Следећа слика приказује класификацију категорија у једном исечку.

класификација категорија

# 1) Висока тежина и висок приоритет

Било који критични / велики неуспех у пословном случају аутоматски се унапређује у ову категорију.

У ову категорију спадају сви кварови због којих испитивање не може да се настави по сваку цену или узрокује озбиљан квар система. На пример, клик на одређено дугме не учитава саму функцију. Или извођење одређене функције доследно руши сервер и узрокује губитак података. Црвене линије на горњој слици указују на ове врсте недостатака.

На пример,

Систем се сруши након што извршите уплату или када не будете могли да додате ставке у корпу, овај недостатак је означен као дефект високе озбиљности и високог приоритета.

који је најбољи иоутубе у мп3 претварач

Други пример била би функција валутне аутомате за продају на банкомату у којој након уноса тачног корисничког имена и лозинке машина не даје новац већ одузима пренесени са вашег рачуна.

# 2) Високи приоритет и мала тежина

Све мање озбиљне грешке које би могле директно утицати на корисничко искуство аутоматски се унапређују у ову категорију.

У ову категорију спадају недостаци који се морају отклонити, али не утичу на апликацију.

На пример, очекује се да ће функција приказати одређену грешку кориснику у вези са повратним кодом. У овом случају, функционално ће код избацити грешку, али порука мора бити релевантнија за генерисани повратни код. Плаве линије на слици указују на ове врсте недостатака.

На пример,

Лого компаније на насловној страни је погрешан, сматра се да је Високи приоритет и мала тежина дефект .

Пример 1) На веб локацији за онлајн куповину када је погрешно написан логотип ФронтПаге, на пример уместо Флипкарт, пише се као Флипкарт.

Пример 2) У логотипу банке, уместо ИЦИЦИ, записано је као ИЦЦЦИ.

У погледу функционалности, то не утиче ни на шта, тако да га можемо означити као Ниску озбиљност, али има утицаја на корисничко искуство. Ову врсту квара треба поправити са високим приоритетом, иако они имају веома мали утицај на страну апликације.

# 3) Висока озбиљност и низак приоритет

Било који недостатак који функционално не испуњава захтеве или има било каквих функционалних импликација на систем, али га заинтересоване стране по страни постављају на стражње место када је пословна критичност у питању, аутоматски се промовише у ову категорију.

Кварови који се морају отклонити, али не одмах. Ово се посебно може десити током ад-хоц тестирања. То значи да је функционалност погођена у великој мери, али се примећује само када се користе одређени неуобичајени улазни параметри.

На пример, одређена функционалност се може користити само на новијој верзији фирмвера, па да би то могао да провери - тестер заправо смањује свој систем и изводи тест и уочава озбиљан проблем који је валидан. У том случају, кварови ће бити класификовани у ову категорију означени ружичастим линијама, јер се обично очекује да крајњи корисници имају вишу верзију фирмвера.

На пример,

На веб локацији за друштвене мреже, ако бета верзија нове функције буде објављена са мало активних корисника који користе ту могућност од данас. Било који недостатак који се пронађе на овој функцији може се класификовати као низак приоритет, јер се функција враћа на друго место због пословне класификације као неважне.

Иако ова карактеристика има функционални недостатак, јер не утиче директно на крајње купце, пословни субјект може класификовати недостатак под низак приоритет, иако има озбиљан функционални утицај на апликацију.

Ово је грешка велике озбиљности, али се може дати приоритет ниском приоритету, јер се са следећим издањем може поправити као захтев за промену. Учесници у послу такође дају ову функцију приоритету као ретко коришћену функцију и не утичу на било које друге функције које имају директан утицај на корисничко искуство. Ова врста дефекта може се класификовати под Висока тежина, али низак приоритет категорија.

# 4) Ниска озбиљност и низак приоритет

Све правописне грешке / слово фонта / неусклађеност у параграфу 3рдили 4тхстраници апликације, а не на главној или насловној страници / наслову.

Ови недостаци су класификовани у зелене линије као што је приказано на слици и јављају се када нема утицаја на функционалност, али ипак не испуњавају стандарде у малој мери. Овде су класификоване козметичке грешке или рецимо димензије ћелије у табели на корисничком интерфејсу.

На пример,

Ако у политици приватности веб странице постоји правописна грешка, овај недостатак се поставља као Мала озбиљност и низак приоритет.

Смернице

Испод су одређене смернице којих се сваки тестер мора трудити да следи:

  • Прво, добро разумите концепте приоритета и озбиљности. Избегавајте да мешате једно са другим и не користите их наизменично. У складу са овим, следите смернице за озбиљност које је објавила ваша организација / тим тако да сви буду на истој страници.
  • Увек одаберите ниво озбиљности на основу врсте издања, јер ће то утицати на приоритет. Неки примери су:
    • За проблем који је критичан, попут целог система и ништа се не може учинити - ова тежина се не сме користити за решавање програмских недостатака.
    • За главно питање, на пример у случајевима када функција не ради како се очекивало - ова тежина би се могла користити за адресирање нових функција или побољшање тренутног рада.
      Имајте на уму да ће одабир правог нивоа озбиљности заузврат дати недостатак, то је дужни приоритет.
  • Као тестер - разумети како одређена функционалност, радије детаљно анализирајући - разумети како би одређени сценарио или тест случај утицао на крајњег корисника. То укључује пуно сарадње и интеракције са развојним тимом, пословним аналитичарима, архитектама, тестним руководиоцем, развојним вођом. У својим дискусијама такође треба да узмете у обзир колико би времена било потребно да се недостатак отклони на основу његове сложености и времена да бисте га утврдили.
  • Коначно , увек је власник производа онај који има право вета на ослобађање, а недостатак треба отклонити. Међутим, с обзиром да сесије тријаже дефеката садрже различите чланове да изнесу своју перспективу о дефекту на основу случаја, у таквом тренутку ако су програмери и тестери синхронизовани, то сигурно помаже у утицају на одлуку.

Закључак

Док отвара недостатке, испитивач је одговоран за додељивање праве тежине недостацима. Нетачна тежина и, према томе, мапирање приоритета могу имати врло драстичне импликације на целокупан СТЛЦ процес и на производ у целини. На неколико разговора за посао - поставља се неколико питања о приоритету и озбиљности како би се осигурало да вам као тестеру ови концепти буду беспрекорно јасни.

Такође, видели смо примере уживо како класификовати квар под различите секције озбиљности / приоритета. До сада бих волео да имате довољно разјашњења о класификацији грешака и у сегментима озбиљности / приоритета.

Надам се да је овај чланак потпун водич за разумевање приоритета и нивоа озбиљности квара. Јавите нам своје мисли / питања у коментарима испод.

Препоручено читање

^