defect management process
Въведение в процеса на управление на дефекти:
По-фокусираният процес и тестване ще позволят по-малко бъги софтуер на пазара.
Предотвратяване на дефекти е много по-ефикасен и ефективен за намаляване на броя на дефектите и също така е много рентабилен за отстраняване на дефектите, открити по време на ранния етап на софтуерния процес. Повечето от организациите провеждат Откриване на дефекти , Премахване на дефекти и тогава Подобряване на процеса което е общо известно като a Процес на управление на дефекти .
етапът на цикъла на разработване на софтуер, в който се провежда програмирането, е:
Какво ще научите:
- Цели на процеса за управление на дефекти (DMP)
- Жизнен цикъл на управление на дефекти
- Процес на управление на дефекти
- Заключение
- Препоръчително четене
Цели на процеса за управление на дефекти (DMP)
По-долу са дадени различните цели на този процес:
- Предотвратете дефекта
- Ранно откриване
- Минимизирайте въздействието
- Разрешаване на дефекта
- Подобряване на процеса
Преди да проучим процеса на управление на дефектите, нека първо разберем какво всъщност е дефект или грешка?
Жизнен цикъл на управление на дефекти
Когато системата дава различна продукция, различна от действителното бизнес изискване, т.е. когато има отклонение от действителното или оригиналното бизнес изискване, тогава можем да кажем, че има дефект в системата / софтуера.
Когато екипът за тестване изпълнява тестовите случаи, те попадат на ситуация, при която действителният резултат от теста е различен от очаквания резултат. Тази вариация се нарича а Дефект .
По принцип софтуерният дефект е състояние, което не отговаря на изискванията за софтуер. Дефектът е грешка или недостатък, който поражда неочаквано или неправилно поведение в системата.
За да се справите по подходящ начин с проектите, трябва да знаете как да се справите с разработката и пускането, но заедно с това трябва да знаете и как да се справите с дефектите.
Само си представете какво ще се случи, ако тестващият екип отчете дефектите устно и екипът за разработки също актуализира състоянието на дефекта устно? Процесът ще бъде по-сложен, тъй като тези дефекти включват всички дефекти като реално фиксирани и работещи според очакванията, фиксирани, но все още не работещи, отхвърлени, отложени и процесът продължава.
В горния случай, тъй като броят на дефектите се увеличава и комуникацията се извършва устно, ситуацията скоро ще бъде много лоша. За да контролирате и да се справите ефективно с дефекта, се нуждаете от подходящ жизнен цикъл на дефектите.
Дефектният жизнен цикъл гарантира, че процесът е еднороден и стандартизиран. Дефектът достига различни състояния в жизнения цикъл. След откриването на дефект, той преминава през различни етапи през целия си живот и е известен като Жизнен цикъл на дефекти .
Обикновено жизненият цикъл на дефектите започва от етапа, когато дефектът е открит или повдигнат от екипа за тестване и завършва, когато дефектът е затворен, като гарантира, че не може да бъде възпроизведен или е отхвърлен от екип за разработка. Броят на състоянията, през които дефектът преминава, варира от проект до проект.
Допълнителна информация:
Забележка: По-долу цикъл леко се различава от организация до организация.
Животният цикъл на дефекта по-долу обхваща всички възможни състояния:
- Винаги, когато екипът за тестване открие дефект в приложението, той повдига дефекта със статута на „ НОВО ”.
- Когато нов дефект се преглежда от QA проводник и ако дефектът е валиден, тогава състоянието на дефекта ще бъде „ Отворете ”И е готов да бъде възложен на екипа за разработка.
- Когато QA олово присвои дефекта на съответния разработчик, състоянието на дефекта ще бъде маркирано като „ Възложено ”. На този етап разработчикът трябва да започне да анализира и отстранява дефекта.
- Когато разработчикът смята, че дефектът не е истински или валиден, тогава той отхвърля дефекта. Състоянието на дефекта е отбелязано като „ Отхвърлено ”И се връща обратно на екипа за тестване.
- Ако регистрираният дефект се повтаря два пъти или и двата докладвани дефекта имат сходни резултати и стъпки за възпроизвеждане, тогава състоянието на един дефект се променя на „ Дубликат ”.
- Ако в текущата версия има някои проблеми или препятствия за отстраняване на определен дефект, тогава дефектът ще бъде взет в предстоящите версии вместо текущата версия и след това ще бъде маркиран като „ Отложено ' или ' Отложено ”.
- Когато разработчикът не е в състояние да възпроизведе дефекта чрез стъпките, споменати в „Стъпки за възпроизвеждане“ от тестващия екип, разработчикът може да маркира дефекта като „ Невъзпроизводимо ” . На този етап екипът за тестване трябва да предостави подробни стъпки за възпроизвеждане на разработчика.
- Ако разработчикът не е наясно относно стъпките за възпроизвеждане, предоставени от QA за възпроизвеждане на дефекта, тогава той / тя може да го маркира като „ Нуждаете се от повече информация ”. В този случай екипът за тестване трябва да предостави необходимите подробности на екипа за разработка.
- Ако дефектът вече е известен и в момента присъства в производствената среда, дефектът се отбелязва като „ Известен дефект ”.
- Когато разработчикът направи необходимите промени, тогава дефектът се отбелязва като „ Фиксирана ”.
- Разработчикът предава дефекта на тестващия екип за проверка, така че разработчикът променя състоянието като „ Готови за повторно тестване ”.
- Ако дефектът няма допълнителни проблеми и той е правилно проверен, тогава тестерът отбелязва дефекта като „ Затворено ”.
- Докато тества отново дефекта, ако изпитателят установи, че дефектът все още е възпроизводим или частично отстранен, тогава дефектът ще бъде маркиран като „ Отворено отново ”. Сега разработчикът трябва отново да разгледа този дефект.
Добре планираният и контролиран жизнен цикъл на дефектите дава общия брой дефекти, открити в дадено издание или във всички издания. Този стандартизиран процес дава ясна представа за това как е написан кодът, доколко правилно е проведено тестването, как дефектът или софтуерът са освободени и т.н. Това ще намали броя на дефектите в производството, като се открият дефектите при тестването самата фаза.
Процес на управление на дефекти
Процесът на управление на дефекти е обяснен подробно по-долу.
# 1) Предотвратяване на дефекти:
Предотвратяване на дефекти е най-добрият метод за отстраняване на дефектите в ранния етап на тестване, вместо да се открият дефектите в по-късния етап и след това да се отстранят. Този метод е и рентабилен, тъй като разходите, необходими за отстраняване на дефектите, открити в ранните етапи на тестване, са много ниски.
Въпреки това не е възможно да се отстранят всички дефекти, но поне можете да сведете до минимум въздействието на дефекта и разходите за отстраняването им.
c ++ изпълнение на двойно свързан списък
Основните стъпки, свързани с предотвратяването на дефекти, са следните:
- Идентифицирайте критичния риск : Идентифицирайте критичните рискове в системата, които ще повлияят повече, ако се появят по време на тестване или на по-късен етап.
- Оценка на очакваното въздействие : За всеки критичен риск изчислете колко би било финансовото въздействие, ако рискът действително е възникнал.
- Минимизирайте очакваното въздействие : След като идентифицирате всички критични рискове, поемете най-големите рискове, които могат да бъдат вредни за системата, ако се сблъскате, и се опитайте да минимизирате или елиминирате риска. За рискове, които не могат да бъдат елиминирани, това намалява вероятността от възникване и неговото финансово въздействие.
# 2) Достижимо изходно ниво:
Когато продуктът (система, продукт или документ) достигне предварително дефинирания си етап, можете да кажете, че резултатът е базова линия. В този процес продуктът или доставката се премества от един етап на друг и докато доставката се премества от един етап на друг, съществуващите дефекти в системата също се пренасят към следващия етап или етап.
Например, помислете за сценарий на кодиране, модулно тестване и след това системно тестване. Ако разработчикът извършва кодиране и модулно тестване, тестването на системата се извършва от екипа за тестване. Тук кодирането и единичното тестване са един основен момент, а системното тестване е друг крайъгълен камък.
Така че по време на модулно тестване, ако разработчикът открие някои проблеми, то не се извиква като дефект, тъй като тези проблеми се идентифицират преди срещата на крайния срок. След като кодирането и модулното тестване приключат, разработчикът предава кода за системно тестване и след това можете да кажете, че кодът е „В основата“ и е готов за следващия етап, тук, в този случай, това е „системно тестване“.
Сега, ако проблемите са идентифицирани по време на тестването, той се нарича дефект, тъй като е идентифициран след завършването на по-ранния етап, т.е. кодиране и модулно тестване.
По принцип резултатите се изходни, когато промените в резултатите са финализирани и всички възможни дефекти са идентифицирани и отстранени. След това същата доставка се предава на следващата група, която ще работи по нея.
# 3) Откриване на дефекти:
Почти е невъзможно да се премахнат всички дефекти от системата и да се направи система като дефектна. Но можете да идентифицирате дефектите рано, преди да станат по-скъпи за проекта. Можем да кажем, че откритият дефект означава, че той е официално уведомен от екипа за разработка и след анализ на този екип за разработка на дефекти също го е приел като дефект.
Стъпките, свързани с откриването на дефекти, са както следва:
- Намерете дефект : Идентифицирайте дефектите, преди да се превърнат в основен проблем за системата.
- Доклад за дефект : Веднага след като екипът за тестване открие дефект, тяхната отговорност е да информират екипа за разработка, че има идентифициран проблем, който трябва да бъде анализиран и отстранен.
- Признайте дефект : След като екипът за тестване присвои дефекта на разработчика, неговият екип на разработчика е да признае дефекта и да продължи да го отстранява, ако е валиден дефект.
# 4) Разрешаване на дефекти:
В горния процес екипът за тестване е идентифицирал дефекта и е докладвал на екипа за разработка. Сега тук екипът за разработка трябва да продължи да разрешава дефекта.
Стъпките, свързани с разрешаването на дефекти, са както следва:
- Приоритизирайте риска : Екипът за разработка анализира дефекта и дава приоритет на отстраняването на дефекта. Ако дефектът има по-голямо въздействие върху системата, тогава те определят дефекта с висок приоритет.
- Отстранете дефекта : Въз основа на приоритета, екипът за разработки поправя дефекта, дефектите с по-висок приоритет се решават първо, а дефектите с по-нисък приоритет се отстраняват в края.
- Отчетете резолюцията : Отговорността на екипа за разработки е да гарантира, че екипът за тестване е наясно кога дефектите ще бъдат отстранени и как дефектът е отстранен, т.е. чрез промяна на един от конфигурационните файлове или извършване на някои промени в кода. Това ще бъде полезно за екипа за тестване, за да разбере причината за дефекта.
# 5) Подобряване на процеса:
Въпреки че в процеса на разрешаване на дефекти дефектите са приоритетни и фиксирани, от гледна точка на процеса, това не означава, че дефектите с по-нисък приоритет не са важни и не оказват голямо влияние върху системата. От гледна точка на подобряването на процеса, всички идентифицирани дефекти са същите като критични дефекти.
Дори тези незначителни дефекти дават възможност да се научите как да подобрите процеса и да предотвратите появата на дефекти, които могат да повлияят на отказ на системата в бъдеще. Идентифицирането на дефект с по-слабо въздействие върху системата може да не е голяма работа, но появата на такъв дефект в самата система е голяма работа.
За подобряване на процеса, всеки в проекта трябва да погледне назад и да провери откъде е възникнал дефектът. Въз основа на това можете да правите промени в процеса на валидиране, основен документ, процес на преглед, който може да засече дефектите в началото на процеса, които са по-евтини.
Заключение
Процесът на управление на дефекти трябва да се следва по време на цялостния процес на разработване на софтуер, а не само за специфични дейности по тестване или разработка.
Ако дефект бъде открит във фазата на тестване, тогава може да се повдигне въпрос, че ако дефектът бъде уловен в тази фаза, какво ще кажете за останалите дефекти, които са живи в системата, които могат да причинят отказ на системата, ако възникне и все още не е открит.
Така че всички процеси като процес на преглед, статично тестване, проверка и т.н., трябва да се засилят и всички в проекта трябва да са сериозни в процеса и да допринасят, когато е необходимо. Висшият мениджмънт в организацията също трябва да разбира и подкрепя процеса на управление на дефектите.
Подходите за тестване, процесът на преглед и т.н. трябва да се избират въз основа на целта на проекта или организационния процес.
Надявам се тази информативна статия за Процеса за управление на дефекти да ви е от огромна помощ.
Препоръчително четене
- Какво е техника за изпитване на базата на дефекти?
- Процес на дефектна триация и начини за справяне с дефектната триажна среща
- Какво представлява жизнения цикъл на дефекти / грешки при тестване на софтуер? Урок за жизнения цикъл на дефекти
- Урок за Bugzilla: Ръчен урок за инструмент за управление на дефекти
- Методи и техники за предотвратяване на дефекти
- Урок за инструмента за управление на дефекти на IBM Rational Team Concert
- Как да възпроизведете невъзпроизводим дефект и да си заслужите усилията за тестване
- Софтуерното тестване е всичко за идеите (и как да ги генерирам)