Мени

Процес управљања недостацима: Како ефикасно управљати недостацима

  • Главни
  • Остало
  • Процес управљања недостацима: Како ефикасно управљати недостацима

defect management process

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

Увод у процес управљања недостацима:

Фокусиранији поступак и тестирање омогућиће мање софтвера са грешкама на тржишту.

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

Процес управљања недостацима

која је компанија тренутно лидер у услугама веб хостинга заснованих на облаку?

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

Циљеви процеса управљања недостацима (ДМП)

Доље су дати различити циљеви овог процеса:

  • Спречите дефект
  • Рано откривање
  • Минимализирајте утицај
  • Решење дефекта
  • Унапређење процеса

Пре истраживања процеса управљања недостацима, прво да схватимо шта је заправо квар или грешка?

Животни циклус управљања недостацима

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

Када тест тим изврши тест случајеве, наиђу на ситуацију да се стварни резултат теста разликује од очекиваног резултата. Ова варијација се назива а Дефецт .

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

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

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

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

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

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

Додатна литература:

Шта је животни циклус оштећења / грешака у тестирању софтвера? Водич за животни циклус оштећења

Белешка: Испод циклус се мало разликује од организације до организације.

Следећи животни циклус квара покрива све могуће статусе:

Дијаграм тока животног циклуса оштећења

  • Кад год тим за тестирање открије квар у апликацији, квар подигне са статусом „ НОВА ”.
  • Кад КА прегледа нови дефект и ако је квар валидан, статус квара би био „ Отвори ”И спреман је за додељивање развојном тиму.
  • Када КА водич додели квар одговарајућем програмеру, статус квара ће бити означен као „ Додељен ”. Програмер би у овој фази требало да почне да анализира и отклања квар.
  • Када програмер осети да квар није оригиналан или ваљан, тада одбацује квар. Статус квара је означен као „ Одбијен “И враћен натраг тиму за тестирање.
  • Ако се евидентирани дефект понови два пута или оба пријављена дефекта имају сличне резултате и кораке за репродукцију, тада се статус једног дефекта мења у „ Дупликат ”.
  • Ако у тренутном издању постоје неки проблеми или препреке за отклањање одређеног квара, тада ће се квар узети у наредна издања уместо у тренутном издању, а затим ће бити означен као „ Одложено ”Или„ Одложено ”.
  • Када програмер не може да репродукује квар корацима наведеним у одељку „Кораци до репродукције“, тим за тестирање, програмер може квар означити као „ Није поновљиво ” . У овој фази, тим за тестирање треба да обезбеди детаљне кораке репродукције програмеру.
  • Ако програмеру нису јасни кораци за репродукцију које обезбеђује КА за репродукцију недостатка, тада он / она то може означити као „ Требају вам додатне информације ”. У овом случају, тим за тестирање треба да пружи потребне детаље развојном тиму.
  • Ако је квар већ познат и тренутно је присутан у производном окружењу, квар се означава као „ Познати недостатак ”.
  • Када програмер изврши потребне промене, тада се квар означава као „ Фиксно ”.
  • Програмер сада прослеђује квар тиму за тестирање да би га верификовао, па програмер мења статус као „ Спремни за поновно тестирање ”.
  • Ако квар нема даљњих проблема и ако је правилно верификован, тестер означава квар као „ Затворено ”.
  • Током поновног тестирања квара ако га је испитивач утврдио, квар се и даље може поновити или делимично отклонити, тада би квар био означен као „ Поново отворен ”. Сада програмер мора поново истражити ову ману.

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

да ли постоје вр слушалице за кбок оне

Процес управљања недостацима

Процес управљања недостацима

Процес управљања дефектима је детаљно објашњен у наставку.

# 1) Спречавање недостатака:

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

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

Главни кораци у превенцији недостатака су следећи:

  • Утврдите критични ризик : Идентификујте критичне ризике у систему који ће имати већи утицај ако се појаве током тестирања или у каснијој фази.
  • Процените очекивани утицај : За сваки критични ризик израчунајте колики би био финансијски утицај ако би се ризик заиста појавио.
  • Смањите очекивани утицај : Једном када идентификујете све критичне ризике, преузмите највеће ризике који могу штетити систему ако се наиђу и покушајте да ризик смањите на минимум или елиминишете. За ризике који се не могу елиминисати, смањује вероватноћу појаве и њен финансијски утицај.

# 2) Исходни основ:

Када испорука (систем, производ или документ) достигне своју унапред дефинисану прекретницу, тада можете рећи да је испорука основна линија. У овом процесу, производ или испорука се пребацују из једне фазе у другу, а како се испорука пребацује из једне фазе у другу, постојећи недостаци у систему се такође преносе на следећу прекретницу или фазу.

На пример, размотрите сценарио кодирања, јединичног тестирања, а затим системског тестирања. Ако програмер врши кодирање и јединствено тестирање, тада тестирање система врши тим за тестирање. Овде је кодирање и јединствено тестирање једна прекретница, а системско тестирање је друга прекретница.

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

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

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

# 3) Откривање недостатака:

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

Кораци који су укључени у откривање недостатака су следећи:

  • Нађи дефект : Идентификујте недостатке пре него што постану главни проблем система.
  • Пријави недостатак : Чим тим за тестирање открије квар, њихова је одговорност да развојни тим освести да постоји идентификовани проблем који треба анализирати и решити.
  • Признајте дефект : Једном када испитни тим додели квар развојном тиму, његов развојни тим је одговоран да призна квар и настави даље да га отклања ако је то ваљани квар.

# 4) Решавање недостатака:

У горе наведеном процесу, тим за тестирање је утврдио недостатак и пријавио развојном тиму. Сада овде развојни тим треба да настави са решавањем квара.

Кораци који су укључени у решавање квара су следећи:

  • Дајте приоритет ризику : Развојни тим анализира квар и даје приоритет отклањању квара. Ако квар има већи утицај на систем, они поправљање квара постављају као висок приоритет.
  • Отклоните квар : На основу приоритета, развојни тим отклања квар, недостаци вишег приоритета прво се решавају, а на крају грешке нижег приоритета.
  • Пријави резолуцију : Одговорност развојног тима је да осигура да тим за тестирање зна када се недостаци желе поправити и како је недостатак отклоњен, тј. Променом једне од конфигурационих датотека или изменама кода. Ово ће бити корисно за испитни тим да разуме узрок квара.

# 5) Побољшање процеса:

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

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

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

Закључак

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

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

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

Приступи тестирању, процес прегледа итд., Би требало да буду изабрани на основу циља пројекта или организационог процеса.

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

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

^