what are iq oq pq 3 q s software validation process
Увод у ИК-ОК-ПК:
ИК, ОК и ПК чине 3К процеса валидације софтвера.
Као тестери, сви знамо да Тим за развој софтвера интерно развија софтвер у складу са Спецификацијом софтверских захтева (СРС), функционалном спецификацијом, а касније и тим за тестирање верификује примену на различитим нивоима тестирања у различитим окружењима за тестирање, од најједноставнијих до најновијих. хигх енд, што на тај начин пресликава производно окружење.
Овим приступом СДЛЦ-а, тим за развој софтвера генерално пере руке предајући завршени софтвер (развијен и верификован) оперативном тиму. Даље, Оперативни тим (који се обично назива Опс тим) брине се о његовом распоређивању у производно окружење и спремању за употребу од стране крајњих корисника.
Сада је овде стварни изазов за Оперативни тим да софтвер учини функционалним у производном окружењу, јер су се током фаза развоја софтвера развој и верификација радили у симулираном окружењу, а врло ретко у близини живог окружења, само у случај доступности података и конфигурација производног окружења.
Овде се валидација софтвера уклапа у слику. Након што се верификација заврши и софтвер одјави тим програма, Опс тим ће извршити низ активности пре него што прихвати софтвер који ће се применити у производњи, како би доказао да се софтвер понаша онако како се очекивало, што није ништа друго до активности валидације.
Шта ћете научити:
Верификација у односу на валидацију
Овде ћемо јасно разумети разлику између активности „Верификација“ и „Валидација“. ' Верификација ’Је да процени софтвер с обзиром на задати скуп захтева и спецификација, што га програмери и тестери обављају на локацији за развој софтвера.
Док „ Валидација ’Је скуп провера осигурања квалитета које спроводе спољни купци, власници, продавци производа који им се испоручује како би проверили подобност пре прихватања или куповине производа. Активности валидације се углавном спроводе на месту производње.
Стога, у случају развоја апликација, Опс тим врши активности валидације софтвера.
Такође прочитајте:
хттпс://ввв.софтваретестингхелп.цом/дифференце-бетвеен-верифицатион-вс-валидатион/
Фазе процеса валидације
Генерално, поступак валидације било ког производа односи се на целокупан животни циклус производа од развоја кроз употребу и одржавање. И стога је поступак валидације подељен на 5 фаза.
5 фаза процеса валидације су:
Овај петофазни приступ поступку валидације слиједи се у многим индустријама као што су производња, медицина, фармација итд. Овде ће валидацију извршити крајњи купац прије куповине машина, опреме или производа.
Састав активности валидације софтвера је да се докаже да је „софтвер спреман за употребу од стране корисника“ и да се углавном верификује успешна инсталација софтвера праћена функционалношћу и оперативношћу.
Приступ 3К-а: ИК-ОК-ПК
Међутим, у контексту софтвера, 3К-ов приступ, ИК-ОК-ПК прати се као део валидације, а извршиће га оперативни тим, који је на крају одговоран за примену софтвера у производњу.
Даље је дат дијаграм тока процеса валидације:
Предложак, план и било који други документ који је уложен за извршење 3К-а, Софтверски тим ће припремити за њихов софтвер и укључује детаљан приступ, задатке / активности / тестове који ће се спроводити као део ових квалификација са резултатима испитивања.
Збирни извештаји биће предати Опс тиму током примопредаје софтвера, заједно са бинарним датотекама и осталим испорученим резултатима.
На високом нивоу,
Све у свему, сврха извођења ИК, ОК и ПК је да се осигура да се софтвер може успешно применити и да се све функционалности могу користити без уских грла.
Идеално је да су ИК, ОК и ПК секвенцијалне активности које треба извршити по редоследу. Ако се инсталација не заврши, функционалност софтвера не може бити верификована и уколико функција није доказана, нема смисла мерити перформансе. Понекад због временског ограничења, ПК може започети паралелно са ОК, након што се утврде кључни аспекти ОК.
Хајде сада да детаљније разумемо сваку од ове 3 фазе.
Квалификација инсталације (ИК)
Квалификација за инсталацију такође се назива „ИК“ , је поступак валидације да ли се испоручени софтвер (бинарни фајлови, скрипте итд.) може успешно инсталирати у одређено окружење са наведеним конфигурацијама и да се провери како су ови кораци инсталације забележени у документу под називом „Водич за инсталацију“.
Следеће ставке испоручује Развојни тим заједно са испорученим софтверским пакетом, а Опс тим их користи за спровођење ИК-а.
1) Документ „Водич за инсталацију“ који документује кораке инсталације у одабраним окружењима.
два) Документ „Водич за конфигурацију“ за подешавање софтвера који се може конфигурисати. Понекад овај документ постаје део самог водича за инсталацију.
3) Софтверски пакет и скрипте за инсталацију, по могућности аутоматизоване скрипте.
Фаза квалификације за инсталацију софтвера сматра се најважнијом и обично има много проблема отворен током ове фазе.
Јер:
до) Развојно окружење неће имати на располагању стопостотно окружење у стварном времену за верификацију проблема са инсталацијом, па стога разлика у окружењу доприноси неколико проблема.
б) Из различитих разлога, можда неће бити довољно сарадње и координације између Развојног и Оперативног тима током почетних фаза развоја софтвера за решавање проблема који су пред нама.
ц) Могуће је да постоје неки проблеми са документовањем током снимања стварних корака инсталације у документу, који се можда не подударају у производном окружењу.
Ових дана цео поступак инсталације софтвера биће аутоматизован што је више могуће кроз низ скрипти. Ако постоје било какви проблеми с инсталацијом, аутоматска инсталација не успије због неусклађености у конфигурацијама и потребна је ручна интервенција за рјешавање тих проблема.
Како Опс тим проводи ИК строго слиједећи упутства која је Софтверски тим дао у упутству за инсталацију, врло је важно и такође је одговорност софтверског тима да осигура да „Водич за инсталацију“ буде написан на такав начин да кораци инсталације се подударају са окружењем у реалном времену.
А на тестерима је одговорност да осигурају да се поступак „инсталације“ верификује интерно, заједно са верификацијом докумената, ради потпуности и да идентификују евентуалне пропусте са стварним корацима које треба покренути у систему у односу на документоване кораке у Упутство за инсталацију.
Следеће тачке треба имати на уму приликом писања Водича за инсталацију и њихове интерне провере како би се смањили проблеми током инсталације софтвера у производњи.
| СНО | Тачке водича за инсталацију |
|---|---|
| 7 | Уобичајено време потребно за инсталацију софтвера треба поменути у Водичу за инсталацију за Опс тим како би имали идеју о приближном времену инсталације како би у складу са тим планирали своје активности. |
| 1 | Главно и крајње, „Водич за инсталацију“ треба да буде написан на једноставном језику који се лако прати. |
| два | Потребно је осигурати да не залази дуго, више од 5 страница. Требало би да буде кратко и уредно. |
| 3 | Треба да наведете серијске бројеве за сваки корак извршења како бисте пратили његов статус. |
| 4 | Аутоматизујте кораке што је више могуће и обједините све у једну скрипту. |
| 5 | За писање поступка инсталације треба користити стандардни образац. |
| 6 | Потребно је јасно навести предуслове да би се избегао пропуст и морају се обезбедити кораци за њихову проверу. Ако постоји пропуст у мечу, треба пружити упутства за њихово довођење на очекивани ниво или за инсталирање тих пакета. |
| 8 | Услуге које треба срушити током инсталације, како их срушити, утицај њиховог обарања морају бити јасно наведени у водичу. |
| 9 | Треба избегавати давање веза до других докумената и прелазак са једног на други документ. Све потребне информације треба да буду доступне у истом документу. Ако треба упутити додатне документе, доставите их заједно са софтверским пакетом, а заузврат их треба упутити у главне документе. |
| 10 | Потребно је осигурати да назив скрипте наведен у документу буде исти као и онај који је упакован заједно са бинарном датотеком. |
| Једанаест | Требало би осигурати да се све скрипте наведене у документу Водича за инсталацију испоручују заједно са бинарним датотекама. |
| 12 | Уверите се да су сви конфигурацијски параметри јасно наведени у Водичу за инсталацију / Водич за конфигурацију, заједно са подразумеваним вредностима и осталим подржаним вредностима. |
| 13 | Требало би доставити аутоматизоване тестове за спровођење тестова верификације састава након завршетка инсталације софтвера. Морају бити минимални и важни да би се верификовало да ли је верзија успешно инсталирана. |
| 14 | Потребно је доставити „тестове дима“ како би се осигурало да је крајња повезаност система савршена и да све компоненте система разговарају како се очекује. |
| петнаест | У случају неуспеха инсталације софтвера, заједно са пакетом испоручују се скрипте за враћање, а поступак враћања је јасно написан у Водичу за инсталацију како би се извршило враћање и систем успешно обновио. |
Уз све горње тачке које треба водити рачуна, најбоља је пракса аутоматизовати поступак инсталације софтвера уз минималну људску интервенцију како би се избегле људске грешке.
Ако се утврде било какви проблеми током фазе валидације ИК-а, тада ће се то пријавити софтверском тиму, након чијег решавања, испитивања дима и тестова провере градње извршиће се ради провере успеха инсталације софтвера.
Отуда фаза ИК укључује инсталирање софтверског пакета, праћено верификацијом израде и тестовима дима.
Дакле, успешан завршетак ИК фазе је веома важан, јер успешна и исправна инсталација софтвера осигурава да се већина проблема који се односе на кварове функционалности негирају.
Оперативна квалификација (ОК)
Оперативна квалификација, такође се назива и ШТА је следећа активност процеса валидације софтвера након успешног завршетка ИК.
Активност оперативне квалификације укључује т тестира да се изврши како би се потврдило да ли је софтвер оперативно способан за примену код потрошача. Идеално је да су кључне функционалности софтвера верификоване као део овог процеса валидације.
Софтверски тим (тестери) треба да припреми ОК план за спровођење ОК валидације који треба да обухвати све аспекте ОК тестирања које треба извршити, укључујући детаље попут бр. тестова, распоред испитивања, методологија, алати, утицај на услугу, редослед извођења тестова, начин извештавања о проблемима и СЛА за њихово решавање, приступ Дефецт Триаге итд.,
Тестове оперативне квалификације, који се изводе као део ОК-а, поново пружа Софтверски тим заједно са софтверским испорукама. Ови тестови оперативне квалификације представљају скуп важних тестова који су дизајнирани на основу документа „Спецификација функционалних захтева“ како би се осигурало да цео системски систем функционише у складу са очекивањима.
Овај документ о спецификацији ОК теста припремају инжењери за испитивање према документу о спецификацији функционалних захтева. Често је овај документ подскуп документа спецификације системског теста припремљеног и верификованог током фазе системског тестирања СДЛЦ-а.
Тестови се могу изменити или ажурирати у складу са захтевима Оперативног тима и условима локације на којој ће се извршити.
Стога би требало бити пажљив при одабиру тестова који су део ОК-а како би се осигурало да су све кључне функционалности и главни пословни токови рада укључени као део ове верификације.
Следе савети за тестере током припреме документа о спецификацији ОК теста.
| Сно | Савети за тестере током припреме документа о спецификацији ОК теста |
|---|---|
| 7 | Не морају бити укључени тест случајеви који се односе на граничну вредност, чиме се верификују екстремне вредности, већ се као улаз користе где се свакодневно користе најчешће вредности. |
| 1 | Уверите се да су кључни тестови функционалности који доказују да су софтверске функције како су очекиване изабрани и укључени, а самим тим и потребна следљивост за сваки од писаних случајева примера доступна је у документу ОК Тест Спец. |
| два | Уверите се да су тестови уредно написани корак по корак, да су самообјашњиви и да их обичан човек може разумети. |
| 3 | Немојте се што више позивати или избегавати употребу било каквих техничких израза у тест случајевима, јер корисник овог документа можда не зна за те терминологије.е да коришћени тест подаци већ не постоје у систему. Наведите више скупова података, у случају да корисник жели да изврши тест случајеве више пута. |
| 4 | Јасно наведите обавезне и необавезне предуслове за сваки од тестова. |
| 5 | Укључите већину позитивних тестова како бисте верификовали функционалност. |
| 6 | Укључите врло мало негативних тест случајева како бисте осигурали да понашање софтвера буде очекивано у случају небитног уноса и да систем може успешно да реши негативне случајеве. |
| 8 | Наведите вредности конфигурације које треба поставити ако их треба променити са подразумеваних вредности. |
| 9 | Наведите аутоматизоване тест случајеве који ће се покретати, где год су доступни. Уверите се пре тога да се те скрипте за аутоматизацију могу покретати на систему где се планира ОК. |
| 10 | Уверите се да сваки тест пример има јасне резултате „Очекивани“ и „Стварни“ као референцу. И додајте коментаре ако је потребно да бисте објаснили стварни резултат. |
| Једанаест | Такође је неопходно укључити „критеријуме прихватљивости“ за сваки од тест случајева. Критеријуми за прихватање могу бити статус система након извршења тест случајева. |
| 12 | Наведите „Подаци о тестирању“ који ће се тачно користити за сваки од тестова. Покушајте да доставите најчешће податке уживо. И такође неколико изузетних података, како би се осигурало да систем може да обрађује и изузетне случајеве. Уверите се да коришћени тест подаци већ не постоје на систему. Наведите више скупова података, у случају да корисник жели да изврши тест случајеве више пута. |
| 13 | Ако више оперативних корисника паралелно изводи тестове са различитих локација, наведите упутства да се тестирање изврши у складу са различитим скупом података. |
| 14 | Наведите контролне листе тамо где је икад потребно како би се осигурало да су све конфигурације, предуслови постављени како се очекује пре покретања тестова. |
| петнаест | Наставите да надгледате евиденције, када су тестови покренути, ако је систем доступан. |
| 16 | Ако је могуће и потребно, пружите подршку извршењу оперативним корисницима током извршавања ових тест случајева. |
| 17 | Објасните начин извештавања о проблемима пронађеним током извршења. Боље је користити алатку за праћење грешака да бисте пратили проблеме. Пажљиво пратите свако издање и однесите га на затварање у складу са договореним СЛА. |
| 18 | Покрените „Дефектне тријаже“ који укључују одговарајуће заинтересоване стране да би разумели критичне и озбиљне проблеме и често пружали ажурирања о тим проблемима. |
| 19 | Наведите коначни образац „Резиме извештаја о извршењу ОК теста“ да бисте објавили коначне резултате након завршетка извршења. |
Тако припремљени ОК план и спецификација теста треба да буду детаљно прегледани и потписани од стране релевантних заинтересованих страна како би се углавном осигурало да покривеност није ни мања или превелика и да су покривене све кључне функционалности.
Успешан завршетак ОК-а показује да ће софтвер функционисати у складу са својим оперативним спецификацијама у одабраном окружењу и представља главну капију у кретању софтвера ка његовој производњи и сигнал је да се крене са следећом активношћу процеса валидације која је ПК .
Квалификација перформанси (ПК)
Након осигурања успешног ИК, завршетка ОК-а, следећа активност у процесу валидације је осигурати да ли производ / софтвер доследно испуњава одређене аспекте перформанси под очекиваним оптерећењем, без изазивања уских грла у производном окружењу.
Кључни аспект ПК-а је осигурати да софтвер, када се инсталира на очекивани систем, може да поднесе оптерећење под напоном и испуни очекивано време одзива и не пада под највећим оптерећењима и стресом док рукује истовременим корисницима.
Отуда је ПК углавном да обезбеди да ли су наведени критеријуми перформанси софтвера постигнути током одређеног временског периода (можда недељу дана) на поузданој основи са различитим условима оптерећења, као што је то образац уживо. Стога се ови тестови морају изводити свакодневно како би се надзирало понашање софтверског система, па ће ПК-у требати неко вријеме док се не осигура да систем буде доказан за своје перформансе.
У идеалном случају, ПК валидација се врши након завршетка ОК, где је функционалност софтвера осигурана и може наставити са верификовањем аспекта перформанси производа или софтвера. Понекад због временског ограничења, ПК може започети паралелно са ОК, на основу поузданости у проценту завршетка ОК.
Идеално је извршити ове тестове перформанси на живом систему са потпуно оптерећеним системом или у условима сличним животном и осигурати да нема уских грла на аспектима перформанси.
Следећи тестови се углавном изводе у оквиру квалификације за перформансе. А избор тестова варира од софтвера до софтвера.
# 1) Тест доступности: Да би се осигурало да је софтвер непрекидно доступан без пада или пада.
# 2) Тест приступачности: Да бисте осигурали да је софтвер без проблема доступан са свих локација са очекиваном брзином перформанси.
# 3) Тест оптерећења: За мерење понашања система под очекиваним свакодневним оптерећењем, као и условима вршног оптерећења.
# 4) Тест стреса: За мерење тачке прекида система под екстремним условима оптерећења.
# 5) Тест перформанси пропусности: Мерење времена одзива система и мерење ТПС-а (трансакције у секунди)
# 6) Испитивање скалабилности: Систем се може прилагодити тако да може да поднесе очекиване истовремене кориснике.
Сценарији испитивања перформанси и одговарајуће аутоматизоване скрипте припремају се на основу захтева у вези са перформансама наведених у документима „Спецификација захтева корисника“.
Као сличан ОК Плану, детаљан ПК план који јасно наводи приступ тестирања, стратегију, план и распоред, заједно са алатима, треба припремити и извршити са извршиоцима ПК.
Алат за испитивање и праћење перформанси мора бити инсталиран у окружењу у којем се врши ПК да би се мериле и извештавале метрике перформанси.
Следе савети тестера како би омогућили Оперативном тиму да успешно изврши ПК.
| Сно | Савети за тестере како би омогућили Оперативни тим |
|---|---|
| 7 | Водите, подржите и обучите Оперативни тим за спровођење испитивања перформанси система. |
| 1 | Припремите кључне пословне специфичне сценарије за спровођење тестирања перформанси заснованих на УРС-у. |
| два | Обавезно укључите тестове како би се доказало да систем испуњава очекивања времена одзива, брзине, скалабилности и стабилности под различитим условима оптерећења. |
| 3 | Уверите се да је одређено оптерећење доступно или да су начин и алати за генерисање потребног оптерећења јасно наведени у одговарајућим тест случајевима. |
| 4 | Јасно наведите предуслов за сваки од сценарија, попут услова пред-учитавања који би требало да постоје у систему, броја истовремених корисника итд., |
| 5 | Алати за помињање који се препоручују за коришћење испитивања перформанси специфичних за сваку категорију теста и за сваки тест. |
| 6 | Уверите се да су поступак надгледања показатеља учинка јасно наведени. |
Након успешног завршетка ПК-а, испуњавање захтева за перформансама је веома важно, јер свака одступања у вези са перформансама могу проузроковати велики пословни губитак стварањем неугодности за корисника и изгубиће се поверење у софтвер који ће се користити што доводи до квара софтвера.
Укратко, т он испод табеле резимира активности ИК-ОК-ПК.
| ИК | ШТА | ПК | |
|---|---|---|---|
| Шта | Да бисте верификовали процес инсталације софтвера и како је процес документован | Да бисте проверили правилно функционисање система | Купци, власници, добављачи, оперативни тим |
| СЗО | Купци, власници, добављачи, оперативни тим | Купци, власници, добављачи, оперативни тим | Купци, власници, добављачи, оперативни тим |
| Где | На локацији власника, локацији оперативног тима, локацији уживо, окружењу сличном производу | На локацији власника, локацији оперативног тима, локацији уживо, окружењу сличном производу | На локацији власника, локацији оперативног тима, локацији уживо, окружењу сличном производу |
| Када | Када софтвер добије од софтверског тима, пре ОК и ПК. | Пре пуштања система у употребу и након успешног завршетка ИК | Пре пуштања система у рад и након успешног ИК, завршетак ОК |
Табела у наставку објашњава различите улазе за сваку од фаза валидације.
| Тип | Улазни |
|---|---|
| ИК | 1. Документ о спецификацији дизајна 2. Софтверске бинарне датотеке и друге инсталационе скрипте 3. Документ Водича за инсталацију 4. Документ о водичу за конфигурацију 5. Направите документ за верификацију и тест дима |
| ШТА | 1. Документ о функционалној спецификацији 2. ОК план документ 3. Испитни документ о оперативној квалификацији 4. Предложак резимеа ОК теста 5. ИК је успешно завршен |
| ПК | 1. УРС (Усер Рекуиремент Специфицатион) документ 2. ПК план документ 3. Испитни документ о квалификацији перформанси 4. Предложак резимеа ПК теста 5. ИК и ОК су успешно завршени |
Закључак
Чак и ако је производ / софтвер прошао све фазе верификације и није успео да докаже ниједан од ИК-ОК-ПК, резултат може бити катастрофалан и изазваће огромне трошкове. Отуда је успешан завршетак ИК-ОК-ПК само успешан пренос производа са места развоја на место производње.
Све у свему, успешан завршетак процеса валидације ИК-ОК-ПК не само да даје самопоуздање софтверу, већ пружа и мир клијенту, власнику, програмерима софтвера и тестерима.
који је најбољи иоутубе видео довнлоадер
Покретање ИК-ОК-ПК такође смањује ризик од постављања на живот, без спровођења испитивања и смањује трошкове квара и умањује ризик од опозива производа.
Дакле, момци, програмери и тестери, нема прославе након завршетка интерног развоја и тестирања и пуштања софтвера у Опс тим. Прослава је само када успешно заврши ИК-ОК-ПК и софтвер буде доступан на циљаном систему.
Отуда успех софтвера зависи од успешног завршетка ИК-ОК-ПК и када је софтвер активан и спреман за употребу од стране крајњих корисника.
О аутору: Овај чланак написао је члан СТХ тимаГаиатхри Субрахманиам. Има више од 2 деценије искуства на пољу тестирања софтвера. Током своје тест каријере, урадила је пуно ТММИ процена, тестова, индустријализације, ТЦОЕ подешавања, уз управљање испорукама тестова и имплементирану ДевОпс праксу за велики ангажман. Али према њеним речима, учење никада не престаје ...
Поделите своја искуства о спровођењу поступка валидације и обавестите нас ако имате питања у вези са овим чланком.
Препоручено читање
- Курс за тестирање софтвера: Који институт за тестирање софтвера да се придружим?
- Најбољи алати за тестирање софтвера 2021. године (КА Тест Аутоматион Тоолс)
- Посао за КА помоћника за тестирање софтвера
- Одабир тестирања софтвера за вашу каријеру
- Тестирање софтвера Технички садржај Вритер Фрееланцер Јоб
- Нека занимљива питања за испитивање софтверског тестирања
- Повратне информације и прегледи курса за тестирање софтвера
- Тестирање софтвера Помоћ Аффилиате Програм!