Врхунски водич за тестирање засновано на ризику: Управљање ризиком у тестирању софтвера

ultimate guide risk based testing

Врхунски водич за тестирање засновано на ризику, управљање ризиком и његов приступ са примерима:

Шта је испитивање засновано на ризику?

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

=> Кликните овде за комплетну серију водича за план испитивања

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

Другим речима, РБТ приступ је да се осигура да се тестирање врши на такав начин да чак и ако је корисник нађе бубу у производњи, то га не спречава да користи софтвер или не утиче на посао на озбиљан начин.

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

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

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

• Тестирање засновано на ризику и његов значај за агилне и развојне програмере
  • Приступ тестирања заснован на ризику
    • Када користимо РБТ приступ?
    • Пример РБТ приступа
  • Начини за спровођење анализе ризика
  • Поступак анализе ризика
  • Методологија анализе ризика
    • Корак # 1) Коришћење мреже 3Кс3
    • Корак # 2) Вероватноћа и утицај неуспеха
    • Корак # 3) Тестирање приоритетне мреже
    • Корак # 4) Детаљи тестирања
  • Како је РБТ релевантан за Агиле и ДевОпс?
  • Предности приступа тестирања заснованог на ризику
• Управљање ризиком током планирања теста
  • Процес управљања ризиком
    • # 1) Идентификација ризика
    • # 2) Процена ризика / Анализа утицаја на ризик
    • # 3) Ублажавање ризика
  • Закључак
• Управљање ризиком у фази извршења теста (са примером)
  • Управљање ризиком - са фокусом на АУТ
  • Како се одвија тестирање основа ризика?
  • Закључак
  • Препоручено читање

Тестирање засновано на ризику и његов значај за агилне и развојне програмере

Тристо сати утрошених на развој софтвера може се учинити бескорисним за само 30 секунди са једним недостатком утврђеним у производњи.

То заузврат може покварити сврху читавог производа, без друге могућности, већ само повлачењем са тржишта. И то је значај и потреба за „испитивањем квалитета“.

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

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

Често примећујемо да је чест проблем готово свих Тестера да буду под огромним притиском да им се прозор за тестирање стисне и да им се верзија у последњи час преда на тестирање. Нема довољно времена и ресурса да изврше све тестове које су осмислили, а покривеност аутоматизацијом није увек 100% и има своје изазове.

Временски оквир испоруке не може се пропустити, а истовремено не може бити нарушен и квалитет. Без обзира на план Б, додавање додатних ресурса за тестирање повлачењем из осталих тимова, не иде, план Ц, престаните да радите све остале активности и преусмерите напор само на ово, заправо не помаже. Колико год додавање ресурса за тестирање, на крају, не иде.

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

Па, како да одлучимо који је тест важан у овој фази? Шта год Тестер сматра важним, можда није стварно важно за купце. Из чије перспективе се одлучује о важности функције или функционалности? Ко ће одлучити који су важни тестови? И мноштво других питања се стално намећу.

Да би се одговорило на сва ова питања и ефикасно се решила наведена ситуација, позван је приступ тестирања „Испитивање засновано на ризику“ , кратко назван 'РБТ' , је постојао, где је тим јасно планирао и идентификовао сценарије испитивања на основу критеријума „Пројектни ризик“.

Иако КА тим има јасну слику о важним тестовима, РБТ је доказана метода идентификовања кључних и важних тестова из перспективе купаца и пословања кроз 'Анализа ризика' процедура .

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

Стога тренутни тренд „Принципа тестирања“ није само „идентификовање недостатака“, већ и

# 1) Усредсредите се на подручје производа где постоји велики утицај на пословање због неуспеха или велике вероватноће неуспеха у производњи.

#два) Са фокусом на идентификовање недостатака рано и омогућавање тиму да то поправи што је раније могуће, а самим тим и омогућавање софтвера / производа или функције „Фаил Фаст“.

# 3) Сада је најважнији аспект услуге КА тима фокусирање на купца у доношењу вредности за купца повећавањем фокуса на „Искуство крајњег купца“.

Приступ тестирања заснован на ризику

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

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

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

Стога, у овом случају, РБТ приступ игра кључну улогу у оптимизацији напора за осигурање квалитета и максимизирању користи од тестирања уз минималан пословни ризик.

Дакле, ако се усредсредимо на горњи аспект, рад КА-а ће бити знатно растерећен. Викенде не морају да спаљују у канцеларији, континуирано тестирајући софтвер и бринући се за све недостатке С4 (тежина 4) и П4 (приоритет 4) који произађу из тестирања.

Па, 4 се сматра најнижим приоритетом и тежином недостатака у испитивању. Они могу боље да уложе своје време у друге корисне аспекте пројекта.

Да резимирамо кључне покретаче приступа „тестирања заснованог на ризику“:

• Омогућити тестирање „онога што купци желе“ из пословне перспективе.
• Да се ​​испуни временски распоред са очекиваним квалитетом.
• Да би се напори за КА оптимизирали.

Када користимо РБТ приступ?

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

• РБТ приступ се може користити кад год постоји ограничење или ограничење времена, трошкова и ресурса пројекта и кад год постоји потреба за оптимизацијом ресурса.
• РБТ приступ се користи када је програм сложенији и прилагођава нову технологију, па стога укључује пуно изазова.
• Када је програм истраживачко-развојни пројекат и први је тип и у пројекту постоји низ непознаница и ризика.

Пример РБТ приступа

Неколико приступа анализи заснованих на ризику користи се у ИТ индустрији за превазилажење ризика са којима се суочава производња и њен утицај.

Доље је дат један такав приступ:

Овај приступ РБТ-а укључује идентификовање „виталних функционалности или кључних карактеристика“ производа и процену ризика којима се свака од ових функционалности излаже у производњи и примену одговарајућих мера ублажавања како би се ризик смањио.

Отуда РБТ приступ укључује испитивање функционалности које имају вероватноћу неуспеха и највећи утицај на пословање. Врсте кварова могу бити оперативне или пословне, техничке, спољне итд.

Начини за спровођење анализе ризика

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

Анализа ризика може се извршити на различитим пројектним ставкама како би се идентификовали ризици и применио РБТ приступ за анализу. Ти предмети укључују,

• Карактеристике
• Функционалности
• Приче корисника
• Захтеви
• Користите случајеве
• Тест случајева

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

Поступак анализе ризика

Анализа ризика укључује укључивање релевантних актера програма из „ Технички тим и пословни тим ’ , који укључује власника производа, менаџере производа, пословне аналитичаре, архитекте, тестере и представнике купаца.

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

Разни „пројектни документи“, као што су документ о захтевима, документи о техничким спецификацијама, документи о архитектури и дизајну, документ о пословном процесу, документ о случају коришћења итд., Постаће улаз за сесију можданих идеја.

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

Неколико других извора инпута такође може да укључи,

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

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

„Вероватноћа појаве ризика“ може бити последица:

• Лоше разумевање функције од стране тима за развој производа.
• Неправилна архитектура и дизајн.
• Недовољно времена за дизајн.
• Неспособност тима.
• Неадекватни ресурси - људи, алати и технологија.

„Утицај ризика“ је ефекат неуспеха на кориснике и пословање ако се догоди. Утицај би могао бити,

• Утицај трошкова, што резултира губитком.
• Утицај на пословање који резултира губитком посла или губитком удела на тржишту, судски поступци, губитак лиценце.
• Утицај на квалитет који резултира испуштањем неквалитетног или неспособног производа.
• Лоше корисничко искуство, што резултира незадовољством и губитком купца.

Подручје фокуса процене ризика неке функције или производа може бити,

• Подручје пословне критичности функционалности.
• Најчешће коришћене функције и важне функције.
• Подручја склона оштећењима
• Функционалност која има сигурносни и сигурносни утицај.
• Област сложеног дизајна и архитектуре.
• Промене извршене у односу на претходне верзије.

Методологија анализе ризика

Хајде да сада детаљно разумемо „методологију испитивања засновану на ризику“.

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

Отуда, РБТ приступ укључује рангирање тестова на основу озбиљности ризика како би се открило највише неисправно или ризично подручје неуспеха, што узрокује велики утицај на пословање.

Главни циљ анализе ризика је да направи разлику између 'Велика вредност' ставке попут карактеристика производа, функционалности, захтева, корисничке приче , и тест случајеви, и „ Ниска вредност' оне и стога касније да се више усредсредимо на тест случајеве „велике вредности“, мање фокусирајући се на тест случајеве „мале вредности“. Ово је почетни корак анализе ризика пре започињања тестирања заснованог на ризику.

Главни задатак категоризације или груписања тест случајева у високу и ниску вредност и додељивање вредности приоритета сваком од ових тест случајева укључује следеће кораке:

Корак # 1) Коришћење мреже 3Кс3

Анализа ризика се врши помоћу мреже 3Кс3, где тим заинтересованих страна процењује сваку функционалност, нефункционалност и с тим повезане тестове.Вероватноћанеуспеха “и„ Учинак неуспеха “.

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

најбоља мобилна шпијунска апликација за андроид

Слично томе, крајњи купац искуси „утицај неуспеха“ ових карактеристика и функционалности у производњи, ако група не тестира ' Пословни стручњаци “и сврстани су у категорије„ Мањи, видљиви и прекидни “дуж водоравне осе мреже.

Корак # 2) Вероватноћа и утицај неуспеха

Сви испитни случајеви постављени су у квадранте мреже 3 Кс 3 на основу идентификованих вредности вероватноће квара и утицаја квара који су приказани тачкама на доњој слици.

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

Корак # 3) Тестирање приоритетне мреже

На основу горњег позиционирања тест случајева у мрежи, тестови су приоритетни и обележени приоритетима 1,2,3,4 и 5 и означени су са сваким од њих. Најважнији тестови су постављени у 1^стмреже које су додељене са приоритетом 1 и слично мање важне рангиране су као 2, 3, 4 и 5.

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

Корак # 4) Детаљи тестирања

Следећи корак је одлучивање о нивоу детаља испитивања за дефинисани обим тестирања. Дубина опсега испитивања може се одредити на основу горњег рангирања према доњој мрежи.

Тестови високог приоритета са рангом 1 су тестирани „Темељито“ и сходно томе, стручњаци су ангажовани да тестирају ове функције високе критичности и с њима повезане случајеве испитивања. Слично томе, могу се донети и случајеви са приоритетима 2, 3 и 4. Одлука о одузимању карактеристика и тестова приоритета 5 на основу расположивог времена и ресурса.

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

Како је РБТ релевантан за Агиле и ДевОпс?

Сада, након разумевања приступа испитивања заснованог на ризику у спровођењу испитивања на основу утврђивања приоритета тестова у зависности од „ризика од неуспеха“ одређене функције и њеног „Утицаја на купца“ уживо, очигледно би се поставило питање значај приступа тестирања заснованог на ризику у агилним и ДевОпс праксама.

„Аутоматизуј све“, „Тестирај све“, „Континуирано тестирај“, „Тестирај више пута“ су кључни концепти ових пракси.

Сваки пут, када дође до промене кода или када дође до издања, сви дизајнирани тестови се покрећу аутоматизовано Континуирана интеграција (ЦИ) / Континуирана испорука (ЦД) цјевовода брзо и опетовано, без обзира на приоритет.

Каква је онда веза између РБТ-а и ДевОпс-а? Где би се РБТ уклопио и постао релевантан у Агиле и ДевОпс ???

# 1) Да, као што сам раније рекао, није да свака индустрија и сваки производ имају 100% покривеност аутоматизацијом за своја извршавања тестова. Дакле, ако тим уопште мора да одабере приоритет за извршење теста од избора ручних тест случајева и жели да поштеди енергију и напор ресурса теста за друге активности, онда је РБТ најбољи избор.

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

#два) КА тим може ефикасније да усвоји РБТ приступ током Анализе захтева у анализи захтева и пружању претходног извештаја о вероватним ризицима производа и карактеристика како би програмски тим могао проактивно да предузме одговарајуће акције да би их ублажио.

# 3) РБТ приступ се може ефикасно користити у дизајнирању тест случајева и сценарија заснованих на високоризичном, тако да се већи фокус може посветити високо ризичним карактеристикама и функционалностима.

# 4) Идентификовање подручја „високог ризика“ омогућава КА тиму да свој напор тестирања усмери на та подручја како би тестирао „детаљније“ помоћу „висококвалификованих тестера“.

# 5) „Фаил Фаст“, ​​као што сви знамо, концепт је „Агиле“ и „ДевОпс“, за који РБТ приступ помаже у препознавању подручја „високог ризика“ у софтверу, раном идентификовању недостатака и омогућавању брзог и неуспешног неуспеха прво и нека тим поправи.

# 6) Крајњи циљ Агиле / ДевОпс-а је „усредсређеност на купца“ и стога РБТ приступ омогућава КА-у да се усредсреди на искуство купаца него само на проналажење недостатака.

Предности приступа тестирања заснованог на ризику

Већ смо разумели сврху и употребу РБТ приступа анализи захтева, дизајнирању и извршавању сценарија тестирања. Постоји неколико предности РБТ-а.

Предности тестирања заснованог на ризику можемо консолидовати и навести као:

• Помаже у ефикаснијој и оптимизованијој употреби ресурса за тестирање.
• Помаже у олакшавању КА рада, тестирања, дизајна и развоја тестова и активности припреме теста давањем приоритета.
• Помаже у бољем управљању КА ресурсима додељивањем кључних ресурса према областима са високим фокусом.
• Помаже у ефикасном коришћењу ресурса и преусмерава њихово време и енергију на боље ствари у пројекту.
• Помаже КА тиму у планирању напора на тестирању на основу процене ризика и идентификације испарљивих и високо ризичних подручја.
• Помаже тиму да оптимизује тестове који ће се изводити у зависности од важности и тиме смањује обухват тестова мале вредности у договору са актерима.
• Свеукупно помаже у смањењу трошкова кроз оптимизоване и смањене активности тестирања.
• РБТ приступ омогућава КА тиму да прво тестира подручја са високим ризиком и омогућава производу да „брзо откаже“ и брзо га поправи.
• РБТ приступ помаже у увођењу јасности у „ Тест Цовераге ’ и „Опсег испитивања“ целој групи заинтересованих страна.
• Тим може повећати фокус на подручја високог ризика, а мање се фокусирати на подручја ниског ризика.
• РБТ омогућава тиму да унапред одлучи о примени најефикаснијег начина ублажавања ризика од производа.
• РБТ помаже у избегавању ефекта непримерене примене ублажавања.
• Тестирање засновано на ризику омогућава тиму да предузме одговарајуће мере или да ублажи или планира непредвиђене случајеве или да постави било које заобилазно решење како би се квар превазишао или смањио његов утицај ако се ризик појави у Ливе-у.
• РБТ помаже у смањењу резидуалног ризика при ослобађању.
• Помаже у постизању „побољшаног квалитета“ кроз јефтиније недостатке у производњи.
• На крају помаже у „Побољшаном искуству купаца“ и „Задовољном купцу“.

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

Управљање ризиком током планирања теста

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

Живот је пун ризика, као и софтверски пројекат. Све може погрешити било када. Увек смо на прстима да поправимо ствари - али шта је са тим да се побринемо да ништа не пође по злу и да када тачно знамо шта да радимо? Уђите у управљање ризиком - ово је део пројекта за тестирање софтвера који нас припрема за спречавање, разумевање, проналажење и превазилажење ризика.

Ризик је једноставно проблем који ће се вероватно догодити и када се догоди, изазваће губитак.

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

Тестирање засновано на ризику : Будући да смо КА заједница, останимо специфични за ризике и процесе повезане с тим искључиво у нашем КА свету. Ризици се процењују и њима се управља у две фазе Животни циклус тестирања софтвера . СТЛЦ се може сврстати у 3 фазе - планирање испитивања, пројектовање теста и извршавање теста.

Процес управљања ризиком одвија се два пута, током:

1. Планирање теста
2. Дизајн тест случаја (крај) или понекад у фази извршења теста

Обавезно је у случају 1, али у случају 2 то је више ситуација „на основу потреба“.

Дводелна серија чланака:

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

Овај одељак ће бити о „Управљање ризиком током планирања теста”.

Процес управљања ризиком

Генерички поступак за управљање ризиком укључује 3 важне фазе:

1. Идентификација ризика
2. Анализа утицаја ризика
3. Ублажавање ризика

Примери испитивања ризика и ублажавања:

# 1) Идентификација ризика

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

Главни исход овог корака је листа ризика.

Овај корак тестирања заснован на ризику обично води руководилац / менаџер / представник за контролу квалитета. Међутим, сам водећи човек неће моћи да изнесе целу листу - целокупни допринос КА тима има огроман утицај. Можемо рећи да је ово колективна активност коју предводи КА.

Такође, ризици који су идентификовани током фазе планирања теста су више „управљачки“ у оријентацији - што значи, погледаћемо све што би могло утицати на распоред, напор, буџет, промене инфраструктуре КА пројекта, итд. Фокус је овде не АУТ, већ начин на који ће КА фаза ићи даље.

Ризици током планирања теста: примери испитивања засновани на ризику

Следи узорак листе ризика који би могли бити наведени током фазе планирања теста. Имајте на уму да АУТ и његова функционалност нису овде у фокусу.

1. Распоред тестирања је строг. Ако је почетак тестирања одложен због пројектних задатака, тест се не може продужити даље од заказаног датума почетка УАТ-а.
2. Нема довољно ресурса, ресурси се укрцавају прекасно (процес траје око 15 дана.)
3. Дефекти се откривају у касној фази циклуса или у касној фази; до касно откривених недостатака највероватније долази због нејасних спецификација и њихово решавање је дуготрајно.
4. Обим није дефинисан у потпуности дефинисан
5. Природне катастрофе
6. Нерасположивост Индепендента Тест Енвиронмент и приступачност
7. Одложено тестирање због нових издања

У овом тренутку можете одабрати да будете темељни колико год желите, у зависности од расположивог времена.

Једном када су наведени сви ризици, прелазимо на процену ризика / анализу утицаја ризика.

# 2) Процена ризика / Анализа утицаја на ризик

Да ли је ваша Анализа ризика нешто попут овог? :)

Анализа ризика у тестирању софтвера : Сви ризици су квантификовани и дати им приоритет у овом кораку. Вероватноћа сваког ризика (шанса за настанак) и утицај (износ губитка који би проузроковао када се овај ризик оствари) утврђују се систематски.

Високо - средње ниско , вредности се додељују и вероватноћи и утицају сваког ризика. Прво се брину о ризицима са „великом“ вероватноћом и „великим“ утицајем, а затим следи редослед.

Табела анализе утицаја ризика:

алат за претварање видео записа у ИоуТубе

Следећи ове кораке, табела анализе утицаја за горе наведене ризике изгледала би отприлике овако (све вредности су хипотетичке и само у сврху разумевања):

# 3) Ублажавање ризика

Завршни корак у овом процесу тестирања на основу ризика (РБТ) је проналажење решења за планирање поступања у свакој од ових ситуација. Ови планови се могу разликовати од компаније до компаније, од пројекта до пројекта, па чак и од особе до особе.

Технике ублажавања ризика:

Ево примера у шта се претвара табела ризика када се заврши ова фаза:

Неколико напомена:

1. Што пре управљање ризиком започне у фази планирања КА пројекта, то боље.
2. Од сва 3 корака, Идентификација ризика је најважнија . Ако било шта није наведено и размотрено за даље кораке, ризик се не решава.
3. Покушајте да пронађете идеалан временски оквир за ову активност. Запамтите, превише планирања оставља премало времена за обављање.
4. Такође, након процеса управљања ризиком, ако се појави нова ситуација, план управљања ризиком може се изменити или ажурирати тако да одражава најновије стање.
5. Историјски подаци може бити веома корисно за успех овог процеса.

Закључак

Ово нас доводи до краја управљања ризиком у фази планирања теста. Иако су основни кораци и принципи слични, процес управљања ризиком је концентрисанији на АУТ када се то догоди у фази дизајнирања / извршења теста.

У следећем одељку ћемо покрити - Управљање ризиком у фази извршења теста.

Управљање ризиком у фази извршења теста (са примером)

Током нашег путовања ка разумевању процеса управљања ризиком, разговарали смо о томе како он иде искључиво у Фаза планирања испитивања тестирања заснованог на ризику . Такође смо разумели генерички процес који укључује - идентификацију ризика, процену ризика и план ублажавања ризика.

Како управљати ризиком у фази дизајнирања теста или извођења теста:

Постоји још један облик Управљање ризиком (такође се понекад назива, Испитивање засновано на ризику ) који се јавља током фазе дизајнирања теста или фазе извођења теста у зависности од ситуације. Сада, о којој ситуацији говоримо? Покушајмо то прво да схватимо.

Сви знамо да је наш рад на тестирању реактиван. Нема захтева (или опсега није дефинисано), не можемо да извршимо анализу изводљивости и напишемо сценарије испитивања или планирамо активности тестирања.

Слично томе, када код није спреман, немамо шта да тестирамо, без обзира на то колико припремних радњи смо можда били спремни у оквиру тест случајева, података о тестирању итд. Такође, тестирање је једини преостали корак пре него што производ крене уживо.

Управљање ризиком - са фокусом на АУТ

Хајде да ово боље разумемо на примеру:

Ако би тестирање требало да почне наведеног датума, 1. јануара^сти морао је да траје до 14. јануара^тх- када се тестирање заврши, датум покретања производа се обично утврђује одмах. Рецимо - 15. јануара^тхради једноставности. Сада би у савршеном свету ствари ишле тачно онако како је планирано. Али сви знамо стварност.

У овом случају, претпоставимо да тестирање из неког разлога није почело све до 7. јануара^тх, што значи да смо изгубили пола времена за тестирање. Али треба нам 14 дана да темељито тестирамо производ. Датум покретања могли бисмо померити даље за 7 дана - међутим; ово обично није опција. Јер се обећава да ће се производ појавити на тржишту одређеног датума, а кашњења нису добра за посао.

Зато обично тимови за тестирање морају да апсорбују кашњења, некако надокнаде, раде са расположивим временом и постарају се да је производ добро тестиран. Тежак посао, зар не?

Овде се поново примењује процес управљања ризиком.

• Сада ако кашњења се очекују пре времена пре него што чак и тестирање започне - процес се одвија у фази дизајнирања теста.
• Ако кашњења се дешавају током Фаза извршења теста који је почео нормално - процес се прати током фазе извршавања теста.
• Кораци и метода су исти без обзира на то у којој се фази догоди.

Који је процес?

Управљање ризиком се врши како би се утврдило на која подручја АУТ (Апликација у тестирању) требају бити максимално фокусирани. То су типично функционална подручја (модули или компоненте) која су пресудна за успех коначног производа и најосновнија су неуспеху.

Прочитајте такође=> Анализа режима неуспеха и ефеката (ФМЕА) је техника управљања ризиком

Ко то изводи?

Будући да се тиче АУТ-а, знање о њему није само са КА већ и са свим осталим тимовима - Дев, БА, Цлиент, пројектним тимовима итд. Стога је то колективни напор који покреће тим за тестирање.

Како се одвија тестирање основа ризика?

Корак 1) Идентификација ризика

Идентификујте сва функционална подручја АУТ. То ће једноставно укључивати прављење листе.

Корак 2) Процена ризика

Сви ризици су квантификовани и дати им приоритет у овом кораку. Квантификовање је једноставно додељивање броја сваком ризику на листи који ће дати назнаку приоритета са којим треба да се реши.

Одлучују се вероватноћа сваког ризика (шанса за настанак) и утицај (износ губитка који би проузроковао када се овај ризик оствари).

Типична метода је додељивање оцена. На пример, Вероватноћа може узети вредности од 1 до 5. 1 је вероватноћа да је појава мала (вероватно се уопште неће догодити), а 5 велика (то ће се сасвим сигурно догодити).

Слично томе, Импацт-у такође може бити додељена оцена 1-5. 1 је слаб утицај (чак и ако се овај ризик материјализује, губитак је минималан), а 5 велики утицај (огромни губици када се догоде).

Корак # 3)

Направите формат табеле и дистрибуирајте га свим представницима тимова - Дев, БА, Цлиент, ПМ, КА и свима осталим релевантним.

Корак # 4)

Упутите сваки тим да попуни вредности на основу оцене вероватноће и утицаја.

Пошто су вредности вероватноће и утицаја нумеричке, то ће олакшати израчунавање вредности „фактора ризика“.

Фактор ризика = Вероватноћа Кс Утицај. Што је већи фактор ризика, то је озбиљан проблем.

Пример:

Имајте на уму да је у овом тренутку ово једноставно резултат оцене једног тима. За пројекат у који је укључено 5 различитих тимова, КА тим би на крају имао 5 различитих табела.

Корак # 5)

Узмите просек вредности фактора ризика. На пример, ако постоји 5 тимова, за сваки модул додајте све вредности фактора ризика и поделите их са 5. Ово су коначне вредности са којима ћемо се позабавити. Рецимо, ово су просечни фактори ризика:

Што је већи фактор ризика, то више тај модул мора бити тестиран.

Дакле, модули 5 и 2 су најважнији за успех посла. Поделите резултате са свим тимовима.

Корак # 6)

План ублажавања ризика : Ово је корак који се мења од пројекта до пројекта. Утврдили смо да су модули 5 и 2 они на које се највише треба концентрирати.

Примериплана може бити:

1. Модули 5 и 2 ће се темељито тестирати тако што ће се осигурати да су тестирани сви тестови у вези са њима. Остали модули ће бити тестирани на истраживачкој основи.
2. Прво ће се тестирати модули 5 и 2, а затим ће се збринути остали, у зависности од расположивог времена.

Једном када се направи план, сви тимови постижу договор и следе га како би тестирали производ узимајући у обзир фактор ризика.

То је то!

Неколико важних тачака које треба напоменути:

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

Закључак

Приступ испитивања заснован на ризику јасно указује на то да фокус испитивача није само да настави да истражује недостатке, без обзира на тежину и приоритет. Сада су се ствари промениле и тестери морају да раде паметно и морају да разумеју јасну „Потребу купца и жеље корисника“.

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

Дакле, РБТ приступ јасно едукује 3 тестера да само тестирање свега или опсежно тестирање не значи да је тестирање завршено или да у производу нема недостатака. Ефикасно тестирање у предвиђеном року и осигуравање поништавања критичних и главних пословних утицаја, што је прилично важно за испитивача.

Стога је тестирање засновано на ризику најефикасније средство за КА тим за вођење учесника у пројекту на основу пројектних ризика. РБТ приступ помаже КА тиму у континуираној идентификацији ризика и његовом решавању који могу угрозити постизање укупних циљева и циљева пројекта и помаже у постизању крајњег циља КА групе.

П.С. Речи КА и Тестирање су наизменично коришћене у целом документу.

О аутору: Овај чланак је написало више чланова СТХ тима - Гаиатхри Субрахманиам и Свати С.

Гаиатхри је МСП са софтверским тестом са више од две деценије искуства у тестирању софтвера и увелико је усвојио приступ „Тестирање засновано на ризику“ као део Тест индустријализације у неколико ангажмана и увидео је корист од оптимизације ресурса за тестирање и тестирања квалитета.

Да ли вам је тестирање засновано на ризику било изазовно? Да ли имате неке занимљиве чињенице које бисте могли додати у наш водич? Слободно изразите своје мисли у одељку за коментаре испод !!

=> Посетите овде за комплетну серију водича за план испитивања

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

• Континуирани процес интеграције: Како побољшати квалитет софтвера и смањити ризик
• Анализа режима неуспеха и ефеката (ФМЕА) - Како анализирати ризике за бољи квалитет софтвера и задовољне купце!
• Врхунски водич за тестирање засновано на ризику: Управљање ризиком у тестирању софтвера
• 10 најбољих алата и техника за процену и управљање ризиком
• Врсте ризика у софтверским пројектима
• Нека занимљива питања за испитивање софтверског тестирања
• Одабир тестирања софтвера за вашу каријеру
• Повратне информације и прегледи курса за тестирање софтвера