Жизнен цикъл на дефекти / грешки при тестване на софтуер

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

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

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

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

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

Ново: Когато се регистрира и публикува нов дефект за първи път. Присвоен му е статус НОВ.
Възложено: След като грешката бъде публикувана от тестера, водачът на тестера одобрява грешката и я възлага на екипа на разработчика
Отворено : Разработчикът започва да анализира и работи върху отстраняването на дефекта
Поправено : Когато разработчикът направи необходимата промяна на кода и потвърди промяната, той или тя може да направи състояние на грешка като „Поправено“.
Изчакващо повторно тестване : След като дефектът бъде отстранен, разработчикът дава определен код за повторно тестване на кода на тестера. Тъй като тестването на софтуера остава в очакване от края на тестерите, присвоеният статус е „в очакване на повторен тест“.
Повторно тестване: Тестерът прави повторно тестване на кода на този етап, за да провери дали дефектът е отстранен от разработчика или не и променя състоянието на „Повторен тест“.

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

Обяснен жизнен цикъл на дефекти

Тестерът открива дефекта
Състояние, присвоено на дефект - Ново
Дефектът се изпраща на мениджъра на проекта за анализ
Ръководителят на проекта решава дали дефектът е валиден
Тук дефектът не е валиден - получава се статус „Отхвърлен“.
И така, мениджърът на проекти присвоява статус отхвърлен . Ако дефектът не бъде отхвърлен, следващата стъпка е да проверите дали е в обхват. Да предположим, че имаме друга функция - функционалност по имейл за същото приложение и вие откривате проблем с това. Но това не е част от текущата версия, когато такива дефекти се присвояват като отложен или отложен статус.
След това мениджърът проверява дали подобен дефект е бил повдигнат по-рано. Ако отговорът е да, на дефекта се присвоява дубликат на състоянието .
Ако дефектът не е присвоен на разработчика, който започва да поправя кода. По време на този етап на дефекта се присвоява статус в ход.
След като кодът е фиксиран. Дефект се определя статус фиксирана
След това тестерът ще тества повторно кода. В случай, че тестовият случай премине дефектът е затворен. Ако тестовите случаи се провалят отново, дефектът се отваря отново и се възлага на разработчика.
Помислете за ситуация, при която по време на 1-вото освобождаване на Flight Reservation е открит дефект в реда на факс, който е бил фиксиран и му е бил присвоен статус затворен. По време на второто освобождаване на надстройката същият дефект отново се появи отново. В такива случаи затворен дефект ще бъде отворен отново.