Меню

Какво представлява жизнения цикъл на дефекти / грешки при тестване на софтуер? Урок за жизнения цикъл на дефекти

what is defect bug life cycle software testing

Опитайте Нашия Инструмент За Премахване На Проблемите

Въведение в жизнения цикъл на дефектите

В този урок ще говоря за жизнения цикъл на дефект, за да ви запозная с различните етапи на дефект, с който тестващият трябва да се справи, докато работи в среда за тестване.

Добавих и най-често задаваните въпроси за интервю за жизнения цикъл на дефектите. Това е важно да знаете за различните състояния на дефект, за да разберете жизнения цикъл на дефекта. Основното намерение на извършването на тестова дейност е да се провери дали продуктът има някакви проблеми / грешки.

Урок за жизнения цикъл на дефекти

По отношение на реалните сценарии грешките / грешките / грешките се наричат ​​грешки / дефекти и следователно можем да кажем, че основната цел на тестването е да се гарантира, че продуктът е по-малко податлив на дефекти (без дефекти е нереална ситуация ).

Сега възниква въпросът какво е Дефект?

Какво ще научите:

Какво е дефект?

Дефектът, с прости думи, е недостатък или грешка в приложение, което ограничава нормалния поток на приложение, като несъответства на очакваното поведение на приложението с действителното.

Дефектът възниква, когато дадена грешка е допусната от разработчик по време на проектирането или изграждането на приложение и когато този недостатък бъде открит от тестер, той се нарича дефект.

Отговорността на тестера е да извърши задълбочено тестване на приложение, за да открие възможно най-много дефекти, за да гарантира, че качествен продукт ще достигне до клиента.

Важно е да разберете жизнения цикъл на дефекта, преди да преминете към работния процес и различните състояния на дефекта.

Затова нека разберем повече за жизнения цикъл на дефектите.

Досега обсъждахме значението на дефекта и неговата връзка в контекста на тестващата дейност. Сега да преминем към жизнения цикъл на дефекта и да разберем работния процес на дефекта и различните състояния на дефекта.

Дефект на жизнения цикъл в детайли

Жизнен цикъл на дефектите, известен също като жизнен цикъл на бъгове, е цикъл на дефект, от който преминава през различни състояния през целия си живот. Това започва веднага след откриването на нов дефект от тестер и приключва, когато тестерът затвори този дефект, като гарантира, че няма да бъде възпроизведен отново.

Дефект на работния процес

Сега е време да разберете действителния работен процес на жизнения цикъл на дефектите с помощта на проста диаграма, както е показано по-долу.

Жизнен цикъл на дефекти

Дефектни държави

# 1) Ново :Това е първото състояние на дефект в жизнения цикъл на дефектите. Когато бъде открит нов дефект, той попада в състояние „Ново“ и валидирането и тестването се извършват на този дефект в по-късните етапи от жизнения цикъл на дефектите.

# 2) Възложено: На този етап новосъздаден дефект се възлага на екипа за разработка за работа по дефекта. Това се възлага от ръководителя на проекта или ръководителя на екипа за тестване на разработчик.

# 3) Отворено: Тук разработчикът започва процеса на анализ на дефекта и работи по отстраняването му, ако е необходимо. Ако разработчикът смята, че дефектът не е подходящ, той може да бъде прехвърлен в някое от по-долу посочените четири състояния Дублиран, отложен, отхвърлен или без грешка -базирано на конкретната причина.

След малко ще обсъдя тези четири състояния.

# 4) Фиксирана: Когато разработчикът завърши задачата за отстраняване на дефект чрез извършване на необходимите промени, тогава той може да маркира състоянието на дефекта като „Фиксиран“.

# 5) Изчакващо повторно тестване: След отстраняване на дефекта, разработчикът присвоява дефекта на тестера за повторно тестване на дефекта в техния край и докато тестерът работи по повторно тестване на дефекта, състоянието на дефекта остава в „Чакащо повторно тестване“.

# 6) Повторно тестване: В този момент тестващият започва задачата да работи по повторно тестване на дефекта, за да провери дали дефектът е фиксиран точно от разработчика според изискванията или не.

# 7) Отворете отново: Ако някакъв проблем продължава в дефекта, той ще бъде възложен на разработчика отново за тестване и състоянието на дефекта се променя на „Отвори отново“.

# 8) Проверено: Ако тестващият не открие проблем в дефекта, след като е бил възложен на разработчика за повторно тестване и той смята, че ако дефектът е бил отстранен точно, състоянието на дефекта се присвоява на „Проверено“.

# 9) Затворено: Когато дефектът не съществува вече, тестерът променя състоянието на дефекта на „Затворен“.

Още няколко:

  • Отхвърлено: Ако дефектът не се счита за истински дефект от разработчика, тогава той се отбелязва като „Отхвърлен“ от разработчика.
  • Дубликат: Ако разработчикът открие дефекта същия като всеки друг дефект или ако концепцията за дефекта съвпада с който и да е друг дефект, тогава състоянието на дефекта се променя на „Дублиране“ от разработчика.
  • Отложено: Ако разработчикът смята, че дефектът не е от особено важен приоритет и той може да бъде отстранен в следващите версии, или в такъв случай, той може да промени състоянието на дефекта като „Отложен“.
  • Не е грешка: Ако дефектът не оказва влияние върху функционалността на приложението, състоянието на дефекта се променя на „Не е грешка“.

The задължителни полета когато тестер регистрира всяка нова грешка са версия на компилация, подаване, продукт, модул, сериозност, резюме и описание за възпроизвеждане

В горния списък можете да добавите някои незадължителни полета ако използвате ръчен шаблон за подаване на грешки. Тези незадължителни полета включват име на клиента, браузър, операционна система, прикачени файлове или екранни снимки.

Следните полета остават или посочени, или празни:
Ако имате право да добавяте полета Състояние на грешка, Приоритет и „Присвоени на“, можете да посочите тези полета. В противен случай мениджърът на тестове ще зададе състояние, приоритет на грешката и ще присвои грешката на съответния собственик на модула.

Погледнете следния цикъл на дефекти

Жизнен цикъл на дефекти / бъгове

Горното изображение е доста подробно и когато обмислите важните стъпки в жизнения цикъл на грешките, ще получите бърза представа за него.

При успешно регистриране грешката се преглежда от мениджъра за разработка или тестване. Тестовият мениджър може да зададе състоянието на грешката като Отворено, може да присвои грешката на разработчика или грешката може да бъде отложена до следващото издание.

Когато грешка бъде възложена на разработчик и той / тя може да започне да работи по нея. Разработчикът може да зададе състоянието на грешката като не може да бъде поправено, не може да се възпроизведе, има нужда от повече информация или „Поправено“.

Ако състоянието на грешката, зададено от разработчика, е „Нуждаете се от повече информация“ или Поправено, тогава QA отговаря с конкретно действие. Ако грешката е коригирана, QA проверява грешката и може да зададе състоянието на грешката като проверено затворено или Отворено отново.

Насоки за прилагане на жизнения цикъл на дефекти

Някои важни насоки могат да бъдат приети, преди да започнете да работите с жизнения цикъл на дефектите.

Те са както следва:

  • Много е важно, преди да започнете да работите върху жизнения цикъл на дефектите, целият екип ясно разбира различните състояния на дефект (обсъдено по-горе).
  • Жизненият цикъл на дефектите трябва да бъде правилно документиран, за да се избегне объркване в бъдеще.
  • Уверете се, че всеки индивид, на когото е възложена някаква задача, свързана с жизнения цикъл на дефектите, трябва много ясно да разбере своята отговорност за по-добри резултати.
  • Всеки индивид, който променя състоянието на дефект, трябва да е наясно с него и трябва да предостави достатъчно подробности за състоянието и причината за поставянето му, така че всеки, който работи по този конкретен дефект, да разбере причината за такъв статус. на дефект много лесно.
  • С инструмента за проследяване на дефекти трябва да се работи внимателно, за да се поддържа последователност между дефектите и по този начин в работния процес на жизнения цикъл на дефектите.

След това нека обсъдим въпросите за интервюто въз основа на жизнения цикъл на дефектите.

Важни често задавани въпроси или въпроси за интервю за жизнения цикъл на грешките

В # 1) Какво представлява дефект в перспективата на софтуерното тестване?

Отговор: Дефект е всеки вид недостатък или грешка в приложението, който ограничава нормалния поток на приложение, като несъответства на очакваното поведение на приложението с действителното.

В # 2) Каква е основната разлика между Грешка, Дефект и Неизправност?

Отговор: Грешка: Ако разработчиците установят, че има несъответствие в действителното и очакваното поведение на приложение във фазата на разработка, те го наричат ​​Грешка.

Дефект: Ако тестерите открият несъответствие в действителното и очакваното поведение на приложение във фазата на тестване, те го наричат ​​като дефект.

Неуспех: Ако клиентите или крайните потребители открият несъответствие в действителното и очакваното поведение на приложение във фазата на производство, те го наричат ​​неуспех.

В # 3) Какво е състоянието на дефекта при първоначалното му откриване?

Отговор: Когато се открие нов дефект, той е в състояние „Ново“. Това е първоначалното състояние на новооткрит дефект.

В # 4) Какви са различните състояния на дефект в жизнения цикъл на дефекта, когато дефектът е одобрен и отстранен от разработчик?

Отговор: Различните състояния на дефект, в този случай, са New, Assigned, Open, Fixed, Pending Retest, Retest, Verified и Closed.

В # 5) Какво се случва, ако тестер все още открие проблем в дефекта, който е отстранен от разработчик?

Отговор: Изпитателят може да отбележи състоянието на дефекта като „Отвори отново“, ако все още открие проблем във фиксирания дефект и дефектът бъде възложен на разработчик за повторно тестване.

В # 6) Какво представлява производствен дефект?

Отговор: Дефект, който се появява многократно при всяко изпълнение и чиито стъпки могат да бъдат уловени при всяко изпълнение, тогава такъв дефект се нарича „произведен“ дефект.

В # 7) Какъв тип дефект е невъзпроизводим дефект?

Отговор: Дефект, който не се появява многократно при всяко изпълнение и се произвежда само в някои случаи и чиито стъпки като доказателство трябва да бъдат уловени с помощта на екранни снимки, тогава такъв дефект се нарича „невъзпроизводим“ дефект.

В # 8) Какво представлява доклад за дефект?

Отговор: Доклад за дефект е документ, който включва информация за дефект или недостатък в приложението, което причинява нормалния поток на приложението, отклонено от очакваното му поведение.

В # 9) Какви подробности са включени в доклад за дефект?

Отговор: Докладът за дефект се състои от следните подробности:

как да инсталирате subversion в eclipse -

Идентификатор на дефект, Описание на дефекта, Име на характеристика, Име на тестовия случай, Възпроизвеждащ се дефект или не, Състояние на дефект, Тежест и приоритет на дефект, Име на тестера, Дата на тестване на дефекта, Версия на компилация, в която е открит дефектът .

И Разработчикът, на когото е присвоен дефект, име на лицето, което е поправило дефекта, Снимки на дефект, изобразяващи потока от стъпки, Поправяне на датата на дефект и лицето, което е одобрило дефекта.

В # 10) Кога дефектът се променя в състояние на „отлагане“ в жизнения цикъл на дефекта?

Отговор: Когато откритият дефект не е от особено голямо значение и този, който може да бъде отстранен в по-късните версии, се премества в състояние „отложено“ в жизнения цикъл на дефектите.

Допълнителна информация за дефекти или грешки

  • Дефект може да се появи във всеки един момент от жизнения цикъл на разработката на софтуер.
  • По-рано дефектът бъде открит и отстранен, по-ниски ще бъдат общите разходи за качество.
  • Разходите за качество се свеждат до минимум, когато дефектът се отстрани в същата фаза, в която е бил въведен.
  • Статичното тестване открива дефекта, а не повреда. Разходите са сведени до минимум, тъй като отстраняването на грешки не е свързано.
  • При динамично тестване наличието на дефект се разкрива, когато причинява повреда.

Състояния на дефекти

S.No. Първоначално състояние Върната държава Държава за потвърждение
единСъберете информация за лицето, отговорно за възпроизвеждането на ДефектаДефектът се отхвърля или се иска повече информацияДефектът е отстранен и трябва да бъде тестван и затворен
двеЩатите са отворени или новиЩатите се отхвърлят или изясняват.Държавите са разрешени и проверка.

Невалиден и дублиран доклад за дефект

  • Понякога възниква дефект, не поради код, а поради тестова среда или неразбиране, такъв отчет трябва да бъде затворен като Невалиден дефект.
  • В случай на дублиран отчет, един се съхранява и един се затваря като дубликат. Някои невалидни отчети се приемат от мениджъра.
  • Тест мениджърът притежава цялостното управление на дефекти и процеса, а екипът от инструменти за управление на дефекти обикновено отговаря за управлението на отчетите.
  • Участниците включват мениджър на тестове, разработчици, премиер, мениджър на производството и други заинтересовани страни, които имат интерес.
  • Комитетът за управление на дефекти трябва да определи валидността на всеки дефект и да определи кога да се поправи или отложи. За да определите това, вземете предвид разходите, рисковете и ползите от неотстраняването на дефекти.
  • Ако дефектът трябва да бъде отстранен, трябва да се определи неговият приоритет.

Данни за дефекти

  • Име на лицето.
  • Вид тестване
  • Обобщение на проблема
  • Подробно описание на Дефект.
  • Стъпки за възпроизвеждане
  • Фаза на жизнения цикъл
  • Работен продукт, където е въведен Defect.
  • Тежест и приоритет
  • Подсистема или компонент, където е въведен дефектът.
  • Проектна дейност, възникваща при въвеждането на дефекта.
  • Метод за идентификация
  • Тип дефект
  • Проект и продукт, в който съществува проблем
  • Настоящ собственик
  • Текущо състояние на отчета
  • Работен продукт, където е възникнал дефект.
  • Въздействие върху проекта
  • Риск, загуба, възможност и ползи, свързани с отстраняване или не отстраняване на дефекта.
  • Дати, когато възникват различни фази на жизнения цикъл на дефекти.
  • Описание на начина на отстраняване на дефекта и препоръки за тестване.
  • Препратки

Способност на процеса

  • Информация за въвеждане, откриване и премахване -> Подобряване на откриването на дефекти и разходите за качество.
  • Въведение -> Преторски анализ на процеса, при който се въвежда най-голям брой дефекти, за да се намали общият брой дефекти.
  • Информация за корен на дефекти -> намерете подчертаните причини за дефекта, за да намалите общия брой дефекти.
  • Информация за дефектния компонент -> Извършване на анализ на клъстерни дефекти.

Заключение

Това е всичко за жизнения цикъл и управлението на дефектите.

Надявам се, че трябва да сте придобили огромни познания за жизнения цикъл на дефекта. Този урок от своя страна ще ви помогне, докато работите с дефектите в бъдеще по лесен начин.

Препоръчително четене

^