Verification, Validation

Verification

Verification (Static Testing) – Այն իրականացվում է Requirement analysis եւ Design փուլերում: Սա կոդի, պահանջների եւ դիզայնի փաստաթղթերի ստուգման պրոցեսն է` որոշելու համար software-ը կառուցվա՞ծ է պահանջներին համապատասխան, թե՞ ոչ: Այս դեպքում կոդը չի իրականացվում: QA-ը համոզվում է, որ պահանջները ճիշտ են հասկացել եւ ճիշտ են design արել:
Գլխավոր նպատակը software application-ի որակի ապահովումն է՝ development cycle-ի վաղ փուլերում error-ներ հայտնաբերելու միջոցով: Իրական կյանքից որպես օրնակ կարող ենք վերցնել թատրոնը։ Մինչ թատրոնը կհասնի վերջնական հանդիսատեսին, նախ եւ առաջ աչքի տակով անցկացնում են սցենարը եւ կատարում են տարբեր պարապմունքներ եւ փորձնական բեմադրություններ։
Սցենարի որեւէ սյուժէ ուսումնասիրելու ընթացքում ներկա են լինում սցենարիստը, բեմադրողը եւ դերասանները, որոնք ներգրավված են այդ սյուժեում։ Սցենարը կարդալիս ամեն մեկն անում է իր առաջարկները եւ գուցե գտնվում են թերություններ, որոնք ունեն շտկման կարիք։ Բեմադրության փորձերի ժամանակ ամեն սյուժե նորից խորապես քննարկվում է։
Հենց այսպիսի գործընթաց էլ տեղի է ունենում SDLC-ի ընթացքում։ Որոշակի կոդեր գրելուց հետո ուսումնասիրվում են ընդհանուր դակումենտացիան եւ այդ գրված կոդերը։ Այսինքն երբ կլիենտը ասում է, որ իրեն պետք է ծրագիր հետեւյալ ֆունկցիոնալներով եւ տալիս է պահանջների դոկումենտացիա, դեռ չի նշանակում, որ այդ պահանջներն ընթացքում չեն փոփոխվելու։ Դեվելոփմենթի ընթացքում առաջանում են զանազան լավ եւ հետաքրքիր մտքեր, ինչպես նաեւ երբեմն առաջանում են իրականացման խնդիրներ. դրանց շնորհիվ կամ պատճառով կարիք է լինում անընդհատ կապի մեջ լինել կլիենտի հետ եւ փոխհամագործակցության շնորհիվ հասնել լավ արդյունքի։ Ստատիկ թեստավորումը բաժանվում է երկու մասի՝ պահանջների փաստաթղթերի վերանայում(Review) եւ ստատիկ անալիզ (Static Analysis):

Վերանայումը իր հերթին լինում է չորս տեսակի.

1. Ոչ ֆորմալ (Informal Reviews) - Ոչ ֆորմալ դիտարկման ընթացքում փաստաթղթերի ստեղծողը բովանդակությունը դնում է լսարանի առջեւ, եւ բոլորը տալիս են իրենց կարծիքը, եւ այդպիսով թերությունները հայտնաբերվում են վաղ փուլում:
2. Քայլարշավ (Walkthroughs) - Հիմնականում դա իրականացվում է փորձառու անձի կամ փորձագետի կողմից` գրոհելու սխալները ստուգելու համար, որպեսզի հետագա դեվելոփմենթի կամ թեստավորման համար այլեւս խնդիրներ չլինեն:
3. Գործընկերների ակնարկ (Technical Reviews) - Գործընկերների վերանայում նշանակում է միմյանց փաստաթղթերի ստուգում` թերությունները հայտնաբերելու եւ շտկելու համար: Դա հիմնականում արվում է թիմի շրջանակներում: Այսինքն ամեն դեվելոփեր կատարում է այդ պահանջների փաստաթղթի մի որոշ հատված եւ այդ հատվածը քննարկվում է հենց դեվելթփերների միջեւ։
4. Տեսչություն (Inspections) - Փաստաթղթի ստուգումն, ըստ էության, ավելի բարձր մարմինների կողմից։

Static Analysis-ը ներառում է developer-ի գրած կոդի որակի գնահատումը, վերլուծությունը եւ համեմատումը ստանդարտների հետ: Այն օգնում է գտնել հետեւյալ դեֆեկտները՝

• Չօգտագործված փոփոխականներ
• Dead code
• Անվերջ loop-եր
• Չորոշված արժեքով փոփոխականներ
• Սխալ syntax

Validation

Validation (Dynamic Testing) – Բուն թեստավորման պրոցեսն է, արդյոք ծրագիրը ճի՞ շտ է աշխատում, թե՞ ոչ, developer-ի ստեղծած ծրագիրը համապատասխանու՞ մ է սպասվածին, թե՞ ոչ: Validation-ի համար պատասխանատու է Tester-ը:
Waterfall մեթոդի դեպքում սկզբում կատարվում է Verification-ը, այնուհետեւ բոլոր փուլերի ավարտից հետո կատարվում է Validation: Agile-ում դրանք իրականացվում են որքան հնարավոր է մոտ ժամանակահատվածում, միաժամանակ:

Օրինակ՝

App-ում պետք է լինի Submet անունով սեղմվող կոճակ (clickable button):

Verification

• Կստուգի դիզայնի փաստաթուղթը եւ կուղղի ուղղագրական սխալները:
• Development թիմը կստեղծի այդպիսի կոճակ:

Validation

• Կոդը պատրաստ է, Validation արվել է եւ հայտնաբերել է, որ կոճակը սեղմվող չէ:
• Validation-ի շնորհիվ development team-ը կոճակը կդարձնի սեղմվող:

Verification VS Validation

Verification	Validation
Ստուգման գործընթացը ներառում է փաստաթղթերի, դիզայնի, ծածկագրի և ծրագրի ստուգում:	Դա իրական արտադրանքի փորձարկման և վավերացման դինամիկ մեխանիզմ է:
Այն չի ներառում կոդի գործարկում:	Այն միշտ ներառում է կոդի կատարումը:
Verification-ի օգտագործում է այնպիսի մեթոդներ, ինչպիսիք են. վերանայումներ, ուսումնասիրություններ, ստուգումներ և աշխատասեղանների ստուգում և այլն:	Այն օգտագործում է մեթոդներ, ինչպիսիք են սև տուփի փորձարկումը, սպիտակ տուփի փորձարկումը և ոչ ֆունկցիոնալ փորձարկումը:
Ստուգվում է արդյոք software-ը համապատասխանում է տեխնիկական պայմաններին:	Այն ստուգում է, թե արդյոք software-ը համապատասխանում է հաճախորդի պահանջներին և ակնկալիքներին:
Այն հայտնաբերում է bug-եր զարգացման ցիկլի սկզբում:	Այն կարող է գտնել bug-եր, որոնք ստուգման գործընթացը չի կարող գտնել:
Թիրախը հավելվածների և software ճարտարապետությունն է, ճշգրտումը, ամբողջական դիզայնը, բարձր մակարդակը և տվյալների բազայի ձևավորումը և այլն:	Թիրախը փաստացի արտադրանք է:
QA թիմը ստուգում է կատարում և համոզվում, որ software-ը համապատասխանում է SRS փաստաթղթի պահանջին:	Փորձարկման խմբի մասնակցությամբ վավերացումն իրականացվում է software կոդի վրա:
Այն գալիս է validation-ից առաջ։	Այն գալիս է verification-ից հետո։

o o o o o o o o o o o o o o o o o o

Օգտակար հղումներ`
Validation vs Verification /article/eng
Difference Between Verification and Validation /article/eng
Validation vs Verification /article/rus
Validation vs Verification /video tutorial/eng