defect severity priority testing with examples
В този урок ще научите какво е Тежест на дефектите и Приоритет при тестване, как да зададете нива на приоритет и степен на дефект с примери, за да разберете ясно концепцията.
Също така ще разгледаме подробно как да класифицираме дефектите в различни групи и тяхната значимост в цикъла на дефекти. Също така ще покрием решаващата роля на класификацията с редица примери на живо.
Дефектите при подаване са много неразделна част част от жизнения цикъл на софтуерното тестване . Има няколко най-добри практики, определени за ефективно докладване за дефекти по интернет или в организации.
Какво ще научите:
- Преглед на проследяването на дефекти
Преглед на проследяването на дефекти
Един от важните аспекти на жизнения цикъл на дефектите на общо ниво включва проследяване на дефекти. Това е важно, тъй като тестовите екипи откриват няколко дефекта при тестване на софтуер, който се умножава само ако конкретната тествана система е сложна. При такъв сценарий управлението на тези дефекти и анализът на тези дефекти за затваряне на задвижването може да бъде обезсърчаваща задача.
В съответствие с процесите за поддръжка на дефекти, когато някой тестер подаде дефект - освен метода / описанието, за да възпроизведе видяния проблем, той трябва да предостави и някои категорична информация, която би помогнала за неточна класификация на дефекта. Това от своя страна би помогнало за ефективни процеси за проследяване / поддръжка на дефекти и също така би формирало основата за по-бързо време за изпълнение на дефектите.
Двата основни параметъра, които формират основата за ефективно проследяване и разрешаване на дефекти, са:
- Приоритет на дефекти при тестване
- Тежест на дефекта при тестване
Те често са объркваща концепция и почти се използват взаимно като не само тестови екипи, но и екипи за разработка. Между тях има тънка граница и е важно да се разбере, че между тях наистина има разлики.
Нека разберем накратко теоретичните дефиниции на двата параметъра в следващия раздел.
Какво е сериозност и приоритет на дефектите?
Приоритетът от английската дефиниция се използва при сравняване на две неща или условия, при които на едното трябва да се отдаде по-голямо значение от другото (ите) и първо трябва да се реши / разреши, преди да се пристъпи към следващото (ите). Следователно в контекста на дефектите приоритетът на дефекта би посочил спешността, с която той трябва да бъде отстранен.
Тежестта по английската дефиниция се използва за описание на тежестта на нежеланото събитие. Следователно, когато става въпрос за грешки, тежестта на грешка би показала ефекта, който тя има върху системата по отношение на нейното въздействие.
Кой ги определя?
QA класифицира дефекта под подходяща тежест въз основа на сложността и критичността на дефектите.
Всички заинтересовани страни в бизнеса, включително ръководителите на проекти, бизнес анализаторите, собствениците на продукти, определят приоритета на дефектите.
Фигурата по-долу изобразява ролята, която притежава и класифицира критичността и тежестта на дефектите.
Как да изберем тези нива?
Както вече обсъдихме, параметърът на тежестта се оценява от тестера, докато параметърът за приоритет се оценява главно от продуктовия мениджър или основно от екипа за триаж. Дори и да е така, тежестта на дефекта определено е един от управляващите и влияещи фактори за определяне на приоритета на дефекта. Следователно е важно като тестер да изберете правилната тежест, за да избегнете объркване с екипите за разработка.
Разлика между тежестта и приоритета
Приоритетът е свързан с планирането, а „тежестта“ е свързана със стандартите.
„Приоритет“ означава, че нещо се предоставя или заслужава предварително внимание; приоритет, установен по важност (или спешност).
„Тежест“ е състоянието или качеството на сериозността; строгият предполага спазване на строги стандарти или високи принципи и често предполага грубост; тежката е белязана или изисква стриктно спазване на строги стандарти или високи принципи, Например, строг кодекс на поведение.
Думите приоритет и тежест се появяват при проследяването на грешки.
Предлагат се разнообразни търговски софтуерни инструменти за проследяване / управление на проблеми. Тези инструменти, с подробно въвеждане на инженери за тестване на софтуер, дават на екипа пълна информация, така че разработчиците да могат да разберат грешката, да получат представа за нейната „сериозност“, да я възпроизведат и поправят.
Поправките се основават на проект „Приоритети“ и „Тежест“ на грешки.
„Тежестта“ на проблема се определя в съответствие с оценката на риска на клиента и се записва в избрания от тях инструмент за проследяване.
Софтуерът за бъги може да „повлияе сериозно“ на графиците, което от своя страна може да доведе до преоценка и предоговаряне на „приоритетите“.
Какво е приоритет?
Приоритетът, както подсказва името, е да се приоритизира дефект въз основа на бизнес нуждите и тежестта на дефекта. Приоритетът означава важността или спешността на отстраняването на дефект.
Докато отваря дефект, изпитателят обикновено придава приоритет първоначално, докато разглежда продукта от гледна точка на крайния потребител. В съответствие с тях има различни нива:
Най-общо Приоритетът на дефектите може да бъде класифициран, както следва:
Приоритет # 1) Незабавен / критичен (P1)
Това трябва да бъде коригирано незабавно в рамките на 24 часа. Това обикновено се случва в случаите, когато цяла функционалност е блокирана и в резултат на това не може да продължи тестване. Или в някои други случаи, ако има значителни течове на памет, тогава дефектът обикновено се класифицира като приоритет -1, което означава, че програмата / функцията е неизползваема в текущото състояние.
Всеки дефект, който се нуждае от незабавно внимание, който оказва влияние върху процеса на тестване, ще бъде класифициран под непосредствената категория
Всички Критична тежест дефектите попадат в тази категория (освен ако не са приоритизирани от бизнеса / заинтересованите страни)
Приоритет # 2) Висока (P2)
След като бъдат отстранени критичните дефекти, дефектът с този приоритет е следващият кандидат, който трябва да бъде коригиран за всяка тестова дейност, за да отговаря на критериите за „излизане“. Обикновено, когато дадена функция не е използваема, както се предполага, поради дефект на програмата или че трябва да се напише нов код или понякога дори поради това, че чрез кода трябва да се обработи някакъв екологичен проблем, дефектът може да отговаря на приоритет 2 .
Това е дефектът или проблемът, който трябва да бъде разрешен преди издаването. Тези дефекти трябва да бъдат отстранени, след като бъдат решени критичните проблеми.
Всички Майор тежест дефекти попадат в тази категория.
Приоритет # 3) Среден (P3)
Дефект с този приоритет трябва да бъде в конфликт, за да бъде отстранен, тъй като би могъл да се справи и с функционални проблеми, които не са според очакванията. Понякога дори козметични грешки, като например очакване на правилното съобщение за грешка по време на повредата, могат да се окачествят като дефект с приоритет 3.
Този дефект трябва да бъде отстранен след отстраняване на всички сериозни грешки.
След като бъдат приключени критичните и високоприоритетните грешки, можем да се насочим към грешки със среден приоритет.
Всички Незначителен тежест дефекти попадат в тази категория.
Приоритет # 4) Нисък (P4)
Дефект с нисък приоритет показва, че определено има проблем, но не е задължително да се коригира, за да отговаря на критериите „изход“. Това обаче трябва да се поправи, преди да се направи GA. Обикновено тук могат да бъдат категоризирани някои грешки при въвеждане или дори козметични грешки, както беше обсъдено по-рано.
Понякога се откриват и дефекти с нисък приоритет, за да се предложат някои подобрения в съществуващия дизайн или заявка за внедряване на малка функция за подобряване на потребителското изживяване.
Този дефект може да бъде разрешен в бъдеще и не се нуждае от непосредствено внимание и Ниска тежест дефекти попадат в тази категория.
Както вече беше обсъдено, приоритетът определя колко бързо трябва да бъде времето за изпълнение на дефекта. Ако има множество дефекти, приоритетът решава кой дефект трябва да бъде отстранен и проверен незабавно, спрямо дефекта, който може да бъде отстранен малко по-късно.
Какво е сериозност?
Тежестта определя степента, до която даден дефект може да създаде въздействие върху приложението или системата.
unix примери за скриптове за черупки за начинаещи
Тежестта е параметър, който обозначава въздействието на дефекта върху системата - колко критичен е дефектът и какво е въздействието на дефекта върху функционалността на цялата система? Тежестта е параметър, зададен от тестера, докато той отваря дефект и главно контролира тестера. Отново различните организации имат различни инструменти за използване при дефекти, но на общо ниво това са следните нива на сериозност:
Например, Обмислете следните сценарии
- Ако потребителят се опита да направи онлайн пазаруване и приложението не се зареди или изскача съобщение за недостъпност на сървъра.
- Потребителят извършва добавяне на артикул в количката, броят на добавените количества е неправилен / добавя се грешен продукт.
- Потребителят извършва плащането и след плащането, поръчката остава в количката, както е запазена, вместо това е потвърдена.
- Системата приема поръчката, но накрая я анулира след половин час поради проблеми.
- Системата приема „Добавяне в кошницата“ само с двойно щракване, вместо с едно щракване.
- Бутонът Добавяне в кошницата се изписва като Добавяне в кошницата.
Какво би било потребителското изживяване, ако някой от горните сценарии може да се случи?
Най-общо дефектите могат да бъдат класифицирани, както следва:
# 1) Критично (S1)
Дефект, който напълно затруднява или блокира тестването на продукта / характеристиката, е критичен дефект. Пример може да бъде в случай на тестване на потребителски интерфейс, когато след преминаване през съветник, потребителският интерфейс просто виси в един прозорец или не отива по-нататък, за да задейства функцията. Или в някои други случаи, когато самата разработена функция липсва в компилацията.
По някаква причина, ако приложението се срине или стане неизползваемо / не може да продължи по-нататък, дефектът може да бъде класифициран под критична тежест.
Всякакви катастрофални откази на системата могат да доведат потребителя до неизползваемост на приложенията, могат да бъдат класифицирани под критичната тежест
Например, В доставчика на имейл услуги като Yahoo или Gmail, след като въведете правилното потребителско име и паролата, вместо да влезете, системата се срива или изхвърля съобщението за грешка, този дефект е класифициран като критичен, тъй като този дефект прави цялото приложение неизползваемо.
Обсъденият по-горе сценарий по точка 1 може да бъде класифициран като критичен дефект, тъй като онлайн приложението става напълно неизползваемо.
# 2) Основни (S2)
Всяка основна функция, внедрена, която не отговаря на нейните изисквания / случаи на употреба и се държи по различен начин от очакваното, може да бъде класифицирана като сериозна сериозност.
Основен дефект възниква, когато функционалността функционира грубо далеч от очакванията или не прави това, което трябва да прави. Пример може да бъде: Кажете, че на комутатора трябва да бъде разположена VLAN и използвате шаблон на потребителски интерфейс, който задейства тази функция. Когато този шаблон за конфигуриране на VLAN не успее на превключвателя, той се класифицира като сериозен недостатък на функционалността.
Например, В доставчика на имейл услуги като Yahoo или Gmail, когато нямате право да добавяте повече от един получател в секцията CC, този дефект се класифицира като основен дефект, тъй като основната функционалност на приложението не работи правилно.
Какво се очаква поведението на секцията CC в пощата, то трябва да позволи на потребителя да добави множество потребители. Така че, когато основната функционалност на приложението не работи правилно или когато се държи по различен начин от очакваното, това е основен дефект.
Обсъдените по-горе сценарии по точки 2 и 3 могат да бъдат класифицирани като основни дефекти, тъй като се очаква поръчката да премине плавно към следващата фаза от жизнения цикъл на поръчката, но в действителност тя варира в поведението.
как да отворите apk файл на windows
Всеки дефект, който може да доведе до неправилна трайност на данните, проблеми с данните или погрешно поведение на приложенията, може да бъде класифициран широко под основната тежест.
# 3) Малки / средни (S3)
Всяка внедрена функция, която не отговаря на своите изисквания / случай (и) и се държи по различен начин от очакваното, но въздействието е незначително до известна степен или не оказва значително въздействие върху приложението, може да бъде класифицирана като незначителна сериозност.
Умерен дефект възниква, когато продуктът или приложението не отговаря на определени критерии или все още проявява някакво неестествено поведение, но функционалността като цяло не е засегната. Например при разгръщането на шаблона на VLAN по-горе, ще възникне умерен или нормален дефект, когато шаблонът бъде разположен успешно на превключвателя, но няма индикация, изпратена до потребителя.
Например, В доставчика на имейл услуги като Yahoo или Gmail има опция, наречена „Правила и условия“ и в тази опция ще има множество връзки относно условията и условията на уебсайта. Когато една от множеството връзки не работи добре, тя се нарича Малка сериозност, тъй като засяга само незначителна функционалност на приложението и няма голямо влияние върху използваемостта на приложението.
Сценарият по точка 5, обсъден по-горе, може да бъде класифициран като незначителен дефект, тъй като няма загуба или повреда на данните в реда на потока на системата, но леко неудобство, когато става въпрос за потребителски опит.
Тези видове дефекти водят до минимална загуба на функционалност или потребителски опит.
# 4) Ниско (S4)
Всички козметични дефекти, включително правописни грешки или проблеми с подравняването или корпуса на шрифта, могат да бъдат класифицирани под Ниска степен на сериозност.
Незначителна грешка с ниска степен на сериозност възниква, когато няма почти никакво въздействие върху функционалността, но все пак е валиден дефект, който трябва да бъде коригиран. Примерите за това могат да включват правописни грешки в съобщения за грешки, отпечатани на потребителите, или дефекти за подобряване на външния вид и усещането на дадена функция.
Например, При доставчика на имейл услуги като Yahoo или Gmail, бихте забелязали „Страница с лиценза“, ако в страницата има правописни грешки или несъответствия, този дефект е класифициран като Нисък.
Сценарият по точка 6, обсъден по-горе, може да бъде класифициран като Low Defect, тъй като бутонът Add е показан в грешен корпус. Този вид дефект няма да окаже влияние върху поведението на системата или представянето на данни или загубата на данни или потока от данни или дори за потребителския опит, но ще бъде много козметичен.
За да обобщим, следващата фигура изобразява общата класификация на дефектите, базирана на тежестта и приоритета:
Примери
Както вече споменахме, тъй като различните организации използват различни видове инструменти за проследяване на дефекти и свързаните с тях процеси - това се превръща в обща система за проследяване между различни нива на управление и техническия персонал.
Тъй като сериозността на дефектите е по-скоро в рамките на функционалността, тестовият инженер определя тежестта на дефекта. Понякога разработчиците участват в влиянието върху тежестта на дефекта, но най-вече това зависи от тестера, тъй като той оценява доколко дадена функция може да повлияе на цялостното функциониране.
От друга страна, когато става въпрос за определяне на приоритет на дефектите, въпреки че първоначално създателят на дефекти определя приоритета, той всъщност се определя от Продуктовия мениджър, тъй като той има цялостен поглед върху продукта и колко бързо трябва да бъде отстранен определен дефект . Изпитателят не е идеалният човек, който да зададе приоритет на дефекта.
Колкото и шокиращо да изглежда това, има два различни примера защо:
Пример # 1) Помислете, че има ситуация, при която потребителят намира грешка в наименуването на самия продукт или някакъв проблем с документацията за потребителския интерфейс. Тестерът обикновено отваря незначителен / козметичен дефект и може да бъде много лесен за отстраняване, но що се отнася до външния вид и усещане на продукта / потребителския опит, това може да причини сериозно въздействие.
Пример # 2) Възможно е да има определени условия, при които възниква определен дефект, който може да бъде изключително рядък или да няма възможност да се удари в клиентската среда. Въпреки че по отношение на функционалността това може да изглежда като дефект с висок приоритет за тестера, като се има предвид неговата рядкост на възникване и висока цена за отстраняване - това би било класифицирано като дефект с нисък приоритет.
Следователно на практика приоритетът на дефектите обикновено се задава от продуктовия мениджър при среща „триаж на дефекти“.
Различни нива
Приоритет и сериозност имат някои класификации сред тях, които помагат при определянето на начина, по който дефектът трябва да бъде обработен. Много различни организации имат различни инструменти за регистриране на дефекти , така че нивата могат да варират.
Нека да разгледаме различните нива както за приоритет, така и за тежест.
- Висок приоритет, висока тежест
- Висок приоритет, ниска тежест
- Висока тежест, нисък приоритет
- Ниска тежест, нисък приоритет
Следващата фигура изобразява класификацията на категориите в един фрагмент.
# 1) Висока тежест и висок приоритет
Всеки отказ от критичен / голям бизнес случай автоматично се повишава в тази категория.
Всички дефекти, поради които тестването не може да продължи на всяка цена или причинява сериозен отказ на системата, попадат в тази категория. Например, кликването върху определен бутон не зарежда самата функция. Или изпълнението на определена функция срива последователно сървъра и причинява загуба на данни. Червените линии на горната фигура показват този вид дефекти.
Например,
Системата се срива, след като сте извършили плащането или когато не можете да добавите артикулите в количката, този дефект е означен като дефект с висока степен на сериозност и висок приоритет.
Друг пример ще бъде функция за валута на банкомат, при която след въвеждане на правилното потребителско име и парола, машината не разпределя пари, а приспада прехвърлените от вашата сметка.
# 2) С висок приоритет и ниска тежест
Всички незначителни дефекти, които могат пряко да повлияят на потребителското изживяване, автоматично се повишават в тази категория.
Дефектите, които трябва да бъдат отстранени, но не засягат приложението, попадат в тази категория.
Например, функцията се очаква да показва конкретна грешка на потребителя по отношение на неговия код за връщане. В този случай функционално кодът ще изведе грешка, но съобщението ще трябва да бъде по-подходящо за генерирания код за връщане. Сините линии на фигурата показват този вид дефекти.
Например,
Логото на компанията на първата страница е грешно, счита се за такова С висок приоритет и ниска тежест дефект .
Пример 1) В уебсайта за онлайн пазаруване, когато логото на FrontPage е изписано погрешно, например вместо Flipkart се изписва като Flipkart.
Пример 2) В логото на банката вместо ICICI е написано като ICCCI.
По отношение на функционалността, това не засяга нищо, така че можем да маркираме като Ниска тежест, но има влияние върху потребителския опит. Този вид дефекти трябва да бъдат коригирани с висок приоритет, въпреки че те имат много по-малко въздействие върху страната на приложението.
# 3) Висока тежест и нисък приоритет
Всеки дефект, който функционално не отговаря на изискванията или има някакви функционални последици за системата, но е отстранен от задните места от заинтересованите страни, когато става въпрос за бизнес критичност, автоматично се повишава в тази категория.
Дефекти, които трябва да бъдат отстранени, но не веднага. Това може конкретно да се случи по време на ad-hoc тестване. Това означава, че функционалността е засегната до голяма степен, но се наблюдава само когато се използват определени необичайни входни параметри.
Например, определена функционалност може да се използва само в по-нова версия на фърмуера, така че за да провери това - тестващият всъщност понижава системата си и извършва теста и наблюдава сериозен проблем с функционалността, който е валиден. В такъв случай дефектите ще бъдат класифицирани в тази категория, обозначена с розови линии, тъй като обикновено се очаква крайните потребители да имат по-висока версия на фърмуера.
Например,
В сайт за социални мрежи, ако бе пусната бета версия на нова функция с не много активни потребители, които използват това средство към днешна дата. Всеки дефект, открит на тази функция, може да бъде класифициран като нисък приоритет, тъй като характеристиката се връща назад поради класификацията на бизнеса като не важна.
Въпреки че тази функция има функционален дефект, тъй като не засяга пряко крайните клиенти, заинтересованата страна в бизнеса може да класифицира дефекта под нисък приоритет, въпреки че има сериозно функционално въздействие върху приложението.
Това е грешка с висока степен на сериозност, но може да бъде приоритизирана към нисък приоритет, тъй като може да бъде коригирана със следващото издание като заявка за промяна. Заинтересованите страни в бизнеса също приоритизират тази функция като рядко използвана функция и не засягат други функции, които имат пряко въздействие върху потребителското изживяване. Този вид дефект може да бъде класифициран под Висока тежест, но нисък приоритет категория.
# 4) Ниска тежест и нисък приоритет
Всички правописни грешки / корпус на шрифта / грешно подравняване в параграфа на 3rdили 4тистраница на приложението, а не в основната или първа страница / заглавие.
Тези дефекти са класифицирани в зелените линии, както е показано на фигурата и се появяват, когато няма въздействие върху функционалността, но все пак не отговарят на стандартите в малка степен. Обикновено козметичните грешки или да кажем размерите на клетката в таблица на потребителския интерфейс са класифицирани тук.
Например,
Ако политиката за поверителност на уебсайта има правописна грешка, този дефект е зададен като Ниска тежест и нисък приоритет.
Насоки
По-долу са определени насоки, които всеки тестер трябва да се опита да спазва:
- Първо, разберете добре концепциите за приоритет и тежест. Избягвайте да бъркате едното с другото и да ги използвате взаимозаменяемо. В съответствие с това, следвайте указанията за сериозност, публикувани от вашата организация / екип, така че всички да са на една и съща страница.
- Винаги избирайте нивото на сериозност въз основа на вида на проблема, тъй като това ще повлияе на неговия приоритет. Някои примери са:
- За проблем, който е критичен, като например, че цялата система пада и нищо не може да се направи - тази тежест не трябва да се използва за отстраняване на програмни дефекти.
- За проблем, който е основен, например в случаите, когато функцията не работи според очакванията - тази сериозност може да се използва за адресиране на нови функции или подобряване на текущата работа.
Не забравяйте, че изборът на правилното ниво на сериозност от своя страна ще даде дефекта, това е дължимият приоритет.
- Като тестер - разберете как определена функционалност, по-скоро разглеждане по-нататък - разберете как даден сценарий или тестов случай би повлиял на крайния потребител. Това включва много сътрудничество и взаимодействие с екипа за разработка, бизнес анализатори, архитекти, ръководител на теста, ръководител на разработката. В дискусиите си трябва също да вземете предвид колко време ще отнеме да се поправи дефекта въз основа на неговата сложност и време, за да се потвърди този дефект.
- Накрая , винаги собственикът на продукта притежава правото на вето на освобождаването, дефектът трябва да бъде отстранен. Въпреки това, тъй като сесиите за сортиране на дефекти съдържат различни членове, за да представят своята гледна точка за дефекта за всеки отделен случай, в такъв момент, ако разработчиците и тестерите са синхронизирани, това със сигурност помага за въздействието върху решението.
Заключение
Докато отваря дефекти, отговорността на тестера е да присвои правилната тежест на дефектите. Неправилната тежест и следователно картографирането на приоритетите може да има много драстични последици за цялостния процес на STLC и продукта като цяло. В няколко интервюта за работа - има няколко въпроса, които се задават относно приоритета и тежестта, за да сте сигурни, че като тестер имате тези идеи безупречно ясни в ума си.
Също така бяхме виждали примери на живо как да класифицираме дефекта в различни сегменти за сериозност / приоритет. Досега бих искал да имате достатъчно разяснения относно класификацията на дефектите както по сегменти за тежест / приоритет.
Надявам се, че тази статия е пълно ръководство за разбиране на приоритета на дефекта и нивата на тежест. Споделете вашите мисли / въпроси в коментарите по-долу.
Препоръчително четене
- Какво е техника за изпитване на базата на дефекти?
- Какво представлява жизнения цикъл на дефекти / грешки при тестване на софтуер? Урок за жизнения цикъл на дефекти
- Процес на управление на дефекти: Как да управляваме ефективно дефекта
- Как да възпроизведете невъзпроизводим дефект и да си заслужите усилията за тестване
- 7 принципа на софтуерното тестване: Клъстериране на дефекти и принцип на Парето
- Методи и техники за предотвратяване на дефекти
- Точна разлика между проверката и проверката с примери
- 3 стратегии за справяне с блокиращ дефект