Մեր Մասին

Կարիերա

Թիմ

<h3>Visual (GUI) method</h3> GUI-ները, ինչպիսիք են տառատեսակները, գույները, հավասարեցումը և պատկերները, անհրաժեշտ են ոչ միայն կայքը օգտագործելի դարձնելու համար, այլև ապրանքանիշի բնութագրերը, ինչպիսիք են ընկերասիրությունը, հուսալիությունը կամ նորարարությունը: Շատ թիմեր նախ սահմանում են առանձնահատկությունները, այնուհետև դիզայներներն ու շահագրգիռ կողմերը ընտրում են համապատասխան տեսողական մանրամասներ: Այս մոտեցումը ենթադրում է, որ դիզայներների և բաժնետերերի կարծիքները ճշգրիտ կկանխատեսեն օգտագործողի արձագանքը: Սա լավ քայլ է, բայց երաշխիք չկա, որ դիզայների համար «բարյացակամ» թվացողը նույնը կլինի օգտատիրոջ համար: Ընկերությունը կարող է շատ բան շահել արդյունավետ բրենդինգից, ուստի տեսողական գեղագիտությունը և օգտատերերի վրա դրա ազդեցությունը պետք է ուշադիր գնահատվեն՝ հիմնվելով հետազոտության տվյալների վրա: Ինչպես ստուգել վիզուալ դիզայնի ընկալումը Ինչպես ցանկացած UX հետազոտության դեպքում, հավաքագրեք մասնակիցների ձեր թիրախային լսարանից: Նրանք կարիք չունեն դիզայնի փորձառության. մարդիկ մասնագիտական ​​վերապատրաստման կարիք չունեն, որպեսզի իմանան, որ ինչ-որ բան իրենց դուր է գալիս: Ըստ Gitte Lindegaard-ի և նրա գործընկերների ուսումնասիրության, օգտատերերին անհրաժեշտ է ընդամենը տասը վայրկյան դիզայնը գնահատելու համար: Բայց եթե ինչ-որ մեկին դուր է գալիս դիզայնը, դա չի նշանակում, որ այն ճիշտ է փոխանցում ապրանքանիշի առանձնահատկությունները։ Ոչ դուք, ձեր թիմի անդամները, ոչ էլ ղեկավարությունը արտադրանքի օգտագործողներ չեք: Բավական չէ պարզապես օգտատերերին հարցնելը՝ արդյոք նրանց դուր է գալիս դիզայնը, թե ոչ: Անհրաժեշտ է ավելի կառուցվածքային մոտեցում, որը կարելի է բաժանել երկու հիմնական մասի. Ներկայացնելով տեսողական խթանը. Ցույց տվեք ուսումնասիրության մասնակիցներին դիզայնը: Սա կարող է լինել նկար, նախատիպ, կենդանի ինտերակտիվ կայք կամ հավելված: Գնահատելով օգտագործողի արձագանքը այս խթանին. Չափել ռեակցիաները դիզայնի նկատմամբ՝ օգտագործելով բաց կամ խիստ վերահսկվող հարցեր: <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/gui-testing.html" target="_blank">GUI testing article/eng</a> <a href="https://www.browserstack.com/guide/visual-testing-beginners-guide" target="_blank">Visual testing article/eng</a> <a href="https://www.youtube.com/watch?v=crbwyGlcXm0" target="_blank">Visual testing video tutorial/rus</a></blockquote>

Ի՞նչ է իրենից ներկայացնում թեստավորման Visual (GUI) method-ը։

Visual (GUI) method

<h3>Ի՞նչ է QE-ը (Quality Engineering)</h3> QE-ը վերաբերում է պրոդուկտի եւ ծառայության որակի ապահովման (Quality Assurance) եւ վերահսկման (Quality Control) սկզբունքներին եւ պրակտիկային: Quality engineer-ի գործունեությունն ուղղված է ծրագրերի մշակման ընթացքի բարելավմանը, խնդիրների բացահայտմանը եւ շտկմանը ։ <h3>Ի՞նչ է որակը</h3> Պարզ ասված՝ այն պիտանելիությունն է օգտագործման կամ նպտակի համար: Խոսքը հաճախորդների կարիքների եւ սպասումների, արտադրանքի ֆունկցիոնալության, դիզայնի, հուսալիության, ամրության եւ գնի մասին է: <h3>Ի՞նչ է ապահովումը</h3> Այն փաստ է, որ product-ը կամ service-ը լավ են աշխատելու:Այն երաշխավորում է, որ product-ը կաշխատի առանց որեւէ խնդրի, ըստ սպասելիքների կամ պահանջի: <h3>Ի՞նչ է որակի ապահովումը(QA)</h3> Այն համակարգված գործընթաց է, որոշելու համար արդյոք product-ը կամ service-ը համապատասխանու՞մ են նշված պահանջներին, թե՞ ոչ: <h3>Որակի ապահովման ընթացքն ունի հետեւյալ փուլերը՝</h3> <ul><li style="text-align: justify;">Պրոդուկտին ներկայացվող պահանջների ստուգում</li><li style="text-align: justify;">Ռիսկերի գնահատում</li><li style="text-align: justify;">Պրոդուկտի որակի բարելավմանն ուղղված գաղափարների պլանավորում</li><li style="text-align: justify;">Թեստավորման պլանավորում</li><li style="text-align: justify;">Թեստավորման արդյունքների վերլուծություն</li></ul> <h3>Quality engineering-ում կան 4 հիմնական դերեր`</h3> <ol><li style="text-align: justify;">Test Analyst - Թեստի վերլուծող, ով զբաղվում է պահանջների ստատիկ թեստավորմամբ, ստուգում է, թե որքանով են պահանջներն ամբողջական, միանշանակ, միմյանց չհակասող։</li><li style="text-align: justify;">Test Designer - Թեստ ստեղծող, ով պահանջների բազայի հիմքի վրա ստեղծում է թեստեր, մշակում է կոնֆիգուրացիաներ, որոնք անհրաժեշտ են թեստավորման համար։</li><li style="text-align: justify;">Test Executor - Թեստ իրականացնող, ով կատարում է նախապես մշակված թեստերը, նշում է սխալները եւ սխալների առաջացման քայլերը։</li><li style="text-align: justify;">Test Manager - Թեստ մենեջերն ավելի շատ ղեկավարում է ամբողջ ընթացքը, պլանավորում եւ վերահսկում է աշխատանքը՝ գնահատում է ժամկետները, հսկում է աշխատանքային գրաֆիկը, առաջադրանքներ է հանձնարարում, հաղորդակցվում է stakeholder-ների հետ։</li></ol> <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.youtube.com/watch?v=goaZTAzsLMk" target="_blank" style="font-size: 14px;">Software testing /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=FS_TuKTsYOg" target="_blank" style="font-size: 14px;">QA engineering /video tutorial/arm</a> <a href="https://www.guru99.com/all-about-quality-assurance.html" target="_blank" style="font-size: 14px;">Quality assurence /article/eng</a></blockquote>

Ի՞նչ է Որակի Ապահովումը։

Որակի ապահովում

<h3>&nbsp;Ի՞նչ է Software Testing–ը</h3> Այն համակարգչային ծրագրի ստուգման պրոցեսն է, հասկանալու, արդյո՞ք այն համապատասխանում է նշված պայմաններին և տալի՞ս է ցանկալի արդյունք, թե՞ ոչ: Նպատակն է` մի շարք գործողությունների միջոցով գտնել ծրագրի defect – ները և մինչ օգտագործողին տրամադրելը հաստատել ծրագրի ճշգրտությունը, ամբողջականությունը և որակը: Թեստավորում մասնագիտության առաջացման խթանը դարձավ այն գիտակցումը, որ ծրագրերի հաջողության գլխավոր գրավականը դրանց որակն է։ Դա է պատճառը, որ հիմա գրեթե բոլոր ՏՏ ընկերություններն ունեն այս հաստիքի մասնագետներ, քանի որ առաջնային նշանակություն ունի պրոդուկտի որակը՝ համապատասխանությունը պահանջներին, անսխալ ու անխափան աշխատանքը։ Թեստավորման մասնագետը ծրագրի մշակման փուլում ծանոթանում է բոլոր պահանջներին և մտածում, թե ինչպիսի թեստավորում է պետք իրականացնել։ Ծրագրի մշակման ավարտից հետո թեստավորման մասնագետը ստուգում է պրոդուկտի համապատասխանությունը պահանջներին, ապա` ծանոթանում պրոդուկտին որպես օգտատեր։ Այդ ընթացքում նա կատարում է բազմաթիվ գործողություններ՝ ստուգելով, թե ինչպես է աշխատում պրոդուկտը։ Առաջացող սխալները մուտքագրվում են դրա համար նախատեսված համակարգ, ծրագրավորողներն ուղղում են այն, ապա թեստավորողը նորից է ստուգում աշխատանքը։ Կարևոր է հետևել, որ մեկ սխալի ուղղումը չդառնա նոր սխալների առաջացման պատճառ։ <h3>Ինչու՞ է Software Testing-ը կարևոր</h3> Software testing-ը կարևոր է, քանի որ եթե software-ում առկա են
bug-եր կամ error-ներ, այն կարելի է վաղ հայտնաբերել և լուծել մինչև ծրագրային
product-ի առաքումը: Պատշաճ թեստավորված software product-ը ապահովում է հուսալիություն,
անվտանգություն և բարձր կատարողականություն, ինչը հետագայում հանգեցնում է ժամանակի
խնայողության, ծախսերի արդյունավետության և հաճախորդների գոհունակության:
Թեստավորումը կարևոր է, քանի որ software bug-երը կարող են թանկ
կամ նույնիսկ վտանգավոր լինել: Software bug-երը կարող են պոտենցիալ դրամական և մարդկային
կորուստներ պատճառել։ Պատմությունը լի է նման օրինակներով:<ul><li>
2015 թվականի ապրիլին Լոնդոնի Bloomberg տերմինալը վթարի ենթարկվեց
software bug-ի պատճառով, որը տուժեց ավելի քան 300,000 թրեյդերների ֆինանսական շուկաներում:
Դա ստիպեց կառավարությանը հետաձգել 3 միլիարդ ֆունտ ստեռլինգ պարտքի վաճառքը:
</li><li>Nissan մեքենաները շուկայից հետ են կանչել ավելի քան 1 միլիոն մեքենա՝
անվտանգության բարձիկների զգայական դետեկտորների software bug-ի պատճառով: Այս ծրագրաշարի
ձախողման պատճառով երկու վթար է գրանցվել:
</li><li>Starbucks-ը ստիպված է եղել փակել խանութների մոտ 60 տոկոսը ԱՄՆ-ում
և Կանադայում՝ իր POS համակարգի software bug-ի պատճառով: Մի պահ խանութը սուրճ է մատուցել
անվճար, քանի որ նրանք չեն կարողացել ընթացք տալ գործարքին:
</li><li>Amazon-ի երրորդ կողմի մանրածախ վաճառողներից ոմանք տեսել են, որ
իրենց արտադրանքի գինը նվազել է մինչև 1p՝ software անսարքության պատճառով: Նրանք մնացել
են մեծ կորուստներով։
</li><li>Խոցելիություն Windows 10-ում: Այս bug-ը թույլ է տալիս օգտվողներին
փախչել անվտանգության ավազատուփերից՝ win32k համակարգի թերության պատճառով:
2015 թվականին F-35 կործանիչն ծրագրային սխալի զոհ է դարձել, ինչի
պատճառով այն չի կարողացել ճիշտ հայտնաբերել թիրախները։
</li><li>China Airlines Airbus A300-ը վթարի է ենթարկվել ծրագրային սխալի
պատճառով 1994 թվականի ապրիլի 26-ին, ինչի հետևանքով զոհվել է 264 անմեղ մարդ։
</li><li>1985 թվականին Կանադայի Therac-25 ճառագայթային թերապիայի մեքենան
անսարքության պատճառով խափանվեց software bug-ի պատճառով և մահացու ճառագայթման չափաբաժիններ
հասցրեց հիվանդներին, ինչի հետևանքով մահացավ 3 մարդ, ևս 3-ը ծանր վիրավորվեցին:</li><li>
1999 թվականի ապրիլին software bug-ը պատճառ դարձավ 1,2 միլիարդ
դոլար արժողությամբ ռազմական արբանյակի արձակման ձախողման՝ պատմության մեջ ամենաթանկ
վթարը։
</li><li>1996-ի մայիսին software bug-ի պատճառով ԱՄՆ-ի խոշոր բանկի 823
հաճախորդների բանկային հաշիվները 920 միլիոն ԱՄՆ դոլարով վարկավորվեցին</li></ul> <h3>Software Testing-ի եղանակները</h3> <ul><li style="text-align: justify;">Positive Testing – Փորձարկման այս եղանակի դեպքում մուտքագրելով valid data` ստուգվում է, արդյո՞ք application-ը ակնկալվածի պես աշխատում է, թե՞ ոչ</li></ul> Օրինակ՝ Կա text box, որն ընդունում է միայն թվեր ՝ մինչև 99999-ը, մնացած բոլոր արժեքները չեն ընդունվում: Testing-ը կլինի Positive, երբ որպես մուտքային արժեքներ վերցնենք 0-99999 թվերը և ստուգենք համակարգը ընդունու՞մ է այս արժեքները, թե՞ ոչ: <ul><li style="text-align: justify;">Negative Testing - Փորձարկման այս եղանակի դեպքում մուտքագրելով invaliddata` ստուգվում է, թե արդյո՞ք application-ը չի անում մի բան, որը թույլատրված չէ:</li></ul> Օրինակ՝ Նախորդ օրինակի text box-ում որպես մուտքային արժեքներ վերցնենք A-Z, a-z սիմվոլները, application-ը կամ պետք է չընդունի, կամ error message տա: <h3>Positive և Negative testing-ի իրականացման տեխնիկաները</h3> <ul><li style="text-align: justify;">Boundary Value Analysis – Այս դեպքում ստուգվում են միայն եզրային արժեքները: Ընդ որում, եթե մուտքագրված տվյալները եզրային արժեքների սահմաններում են, ապա Positive Testing է, իսկ եթե դուրս են՝ Negative Testing:</li></ul> Օրինակ ՝ Text box-ն ընդունում է միայն 0-10 արժեքներ, մնացած բոլոր թվերն invalid են: Կստուգվեն -1, 0, 1 և 9, 10, 11 եզրային արժեքները: <ul><li style="text-align: justify;">Equivalence Partitioning – Այս դեպքում մուտքային տվյալը բաժանվում է մասերի: Յուրաքանչյուր մասից պետք է ստուգվի առնվազն մեկ անգամ: Valid արժեքներն օգտագործվում են Positive Testing-ի համար, invalid արժեքները՝ Negative Testing-ի:</li></ul> Նախորդ օրինակի համար մուտքային տվյալները բաժանում ենք 2 (կամ 3) մասի, Օրինակ՝ -10-ից 0 և 0-ից 10: Ստուգելու համար վերցնում ենք 5 (Positive Testing), -5 (Negative Testing): <blockquote style="text-align: justify;">Օգտակար հղումներ` <a href="https://www.youtube.com/watch?v=goaZTAzsLMk" target="_blank">Software testing /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=Xx1lRYj_NsY&amp;list=PLRs8EELOYKc7DYIQixlV1s4EH5SR3TdNB" target="_blank">Software testing /video tutorial/rus</a> <a href="https://www.guru99.com/software-testing.html" target="_blank">Software testing /article/eng</a> <a href="https://www.guru99.com/software-testing-introduction-importance.html" target="_blank">Software testing /article/eng</a></blockquote>

Software testing

<h3>Ծրագրային ապահովման փորձարկման 7 սկզբունքներ</h3> <ol><li>Թեստավորումը ցույց է տալիս թերությունների առկայությունը&nbsp;</li><li>Սպառիչ փորձարկում հնարավոր չէ</li><li>Վաղ թեստավորում</li><li>Defect clustering</li><li>Թունաքիմիկատների պարադոքս</li><li>Կոնտեքստից կախված թեստավորում</li><li>Սխալի բացակայություն</li></ol> <h3>Թեստավորումը ցույց է տալիս թերությունների առկայությունը</h3> Թեստավորման նպատակը application-ը ձախողելն է: Բավարար թեստավորումները նվազեցնում են թերությունների առկայությունը: Այն դեպքում, երբ թեստավորողները չեն կարողացել հայտնաբերել թերություններ regression թեստերից հետո, չի երաշխավորում, որ application-ը զերծ է բագերից: Թեստավորումը մեզ ցույց է տալիս բագի առկայությունը, այլ ոչ թե դրա բացակայությունը։ <h3>Սպառիչ փորձարկում հնարավոր չէ</h3> Ի՞նչ է սպառիչ փորձարկումը: Սպառիչ փորձարկումը բոլոր ֆունկցիաների փորձարկումն է՝ օգտագործելով բոլոր valid եւ invalid մուտքերն ու նախապայմանները: Ինչո՞ւ է անհնար հասնել սպառիչ թեստինգի: Ենթադրենք, պետք է փորձարկել մուտքային դաշտ, որն ընդունում է տարիք՝ 18-20։ Մենք փորձարկում ենք դաշտը՝ օգտագործելով 18,19,20: Եթե նույն մուտքային դաշտը ընդունում է 18-ից 100-ի սահմանները, ապա մենք պետք է փորձարկենք ՝ օգտագործելով այնպիսի մուտքեր, ինչպիսիք են` 18, 19, 20, 21,..., 99, 100: Սա սովորական օրինակ է, եւ կարելի է մտածել,որ հնարավոր է հասնել դրան՝ օգտագործելով ավտոմատացման գործիքներ: Բայց եթե դաշտն ընդունի մի քանի միլիարդ արժեքներ, հնարավոր չէ ստուգել բոլոր հնարավոր արժեքները ժամանակի սղության եւ սահմանափակումների պատճառով: Այսպիսով, պետք է գտնել օպտիմալ քանակ՝ հիմնված application–ի ռիսկերի գնահատման (risk assessment) վրա: Tester-ը պետք է գտնի այն հատվածները, որտեղ bug-երի հավանականությունն ավելի մեծ է: Եվ քանի որ բոլոր դեպքերը քննարկել հնարավորչէ,կիրառվում է boundary testing-ը: Իսկ ինչպե՞ս է իրականացվում ռիսկերի գնահատումը: Օրինակ՝ Ո՞ր գործողությունը ամենայն հավանականությամբ կդառանա համակարգի խափանման պատճառ. <ol><li style="text-align: justify;">MS Word բացելը</li><li style="text-align: justify;">Internet Explorer բացելը</li><li style="text-align: justify;">Միաժամանակ 10 graphics app բացված լինելը</li></ol> OS- ի փորձարկման ժամանակ կարելի է նկատել, որ defect-ները հիմնականում գտնվում են multi-tasking activity-ներում: <h3>Վաղ թեստավորում</h3> Թեստավորումը պետք է սկսվի հնարավորինս շուտ, որպեսզի առկա խնդիրները բացահայտվեն Software Development Life Cycle-ի վաղ փուլերում։ Software Testing Life Cycle-ի վաղ փուլերում հայտնաբերված թերությունները շտկելն ավելի էժան է։ Այսպիսով, վաղ փորձարկումների անցկացումը նվազեցնում է թերությունների շտկման ծախսերը։ <h3>Defect clustering</h3> Հայտնաբերված defect-ների մեծ մասը գտնվում են փոքր թվով մոդուլների մեջ՝ մոտավորապես 80% bug-երը գտնվում են 20% մոդուլներում: Ըստ փորձի կարելի է որոշել այդպիսի ռիսկային մոդուլները, բայց այս մոտեցման մեջ խնդիրն այն է, որ նույն test-ը մի քանի անգամ կրկնելու դեպքում նույն test case-երը bug-եր չեն գտնի: <h3>Թունաքիմիկատների պարադոքս</h3> Թունաքիմիկատների պարադոքսը Software testing-ի մեջ նույն թեստ քեյսերը կրկին ու կրկին կրկնելու գործընթացն է: Գյուղատնտեսության մեջ միջատներին վերացնելու համար նույն թունաքիմիկատների խառնուրդի կրկնակի օգտագործումը ժամանակի ընթացքում հանգեցնում է նրան, որ միջատները զարգացնում են թունաքիմիկատների նկատմամբ դիմադրություն, որը հանգեցնում է դրանց անարդյունավետությանը միջատների վրա: Նույնը վերաբերում է Software testing-ին: Եթե կրկնվող փորձարկումների նույն շարքը կատարվի, մեթոդը անօգուտ կլինի նոր bug-եր հայտնաբերելու համար: Այսպիսով, այս թունաքիմիկատների պարադոքսը հաղթահարելու համար անհրաժեշտ է պարբերաբար վերանայել թեստ քեյսերը եւ ավելացնել կամ թարմացնել դրանք՝ ավելի շատ թերություններ հայտնաբերելու համար: <h3>Կոնտեքստից կախված թեստավորում</h3> Թեստավորման մոտեցումը կախված է application-ի կոնտեքստից: Մենք թեստավորում ենք տարբեր application-ներ տարբեր ձեւերով : Օրինակ առցանց բանկային կայքը պահանջում է փորձարկման այլ մոտեցում ՝ ի տարբերություն էլեկտրոնային առեւտրի կայքի : <h3>Սխալի բացակայություն</h3> 99%-ով բագերից զերծ application-ը կարող է դեռեւս անօգուտ լինել, եթե ներառվել են սխալ պահանջներ, եւ software- ը չի բավարարում բիզնես կարիքները: Այն ծրագիրը, որը մենք կառուցում ենք, ոչ միայն պետք է լինի 99% բագերից զերծ, այլեւ պետք է բավարարի բիզնես կարիքները, հակառակ դեպքում այն կդառնա անօգուտ ծրագիր: <blockquote style="text-align: justify;">Օգտակար հղումներ` <a href="https://www.youtube.com/watch?v=rFaWOw8bIMM" target="_blank">7 Principles of Software Testing /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=XDiVs2-Ggz4" target="_blank">Software Testing Principles /video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=YvbcTFlJMhc" target="_blank">Software Testing Principles /video tutorial/rus</a> <a href="https://www.guru99.com/software-testing-seven-principles.html" target="_blank">7 Principles of Software Testing /article/eng</a> <a href="https://www.softwaretestingmaterial.com/principles-of-software-testing-2/" target="_blank">7 Principles of Software Testing /article/eng</a></blockquote>

Որո՞նք են ծրագրային ապահովման թեստավորման 7 սկզբունքները։

Թեստավորման 7 սկզբունքները

<h3>1. Requirement collection and analysis</h3> Պահանջների հավաքագրում եւ վերլուծություն: Այս փուլում կատարվում է որակի ապահովման պահանջների պլանավորում եւ ներգրավված ռիսկերի ճանաչում: Այն ավելի հստակ պատկերացում է տալիս ամբողջ ծրագրի շրջանակի, նախատեսվող խնդիրների եւ հնարավորությունների մասին: Որոշվում է աշխատանքն ավարտելու ժամանակացույցը: <h3>2. Feasibility study</h3> Իրագործելիության ուսումնասիրություն Software- ի անհրաժեշտությունների որոշման եւ փաստաթղթավորման փուլն է, որն իրականացվում է 'Software Requirement Specification' փասթաթղթի օգնությամբ, որը ներառում է այն ամենը, ինչը պետք է նախագծվի եւ մշակվի ծրագրի life cycle-ի ընթացքում: Կան իրագործելիության 5 տեսակի ստուգումներ` <ol><li style="text-align: justify;">Տնտեսական - Հնարավո՞ր է նախագիծը բյուջեի սահմաններում ավարտել, թե ոչ:</li><li style="text-align: justify;">Իրավաբանական – Հնարավո՞ր է նախագիծը վարել իրավական հիմքերինհամապատասխան:</li><li style="text-align: justify;">Գործողությունների իրագործելիություն – Հնարավո՞ր է ստեղծել այնպիսի գործողություններ, որոնք սպասվում են հաճախորդի կողմից:</li><li style="text-align: justify;">Տեխնիկական - Անհրաժեշտ է ստուգել, արդյոք ներկայիս համակարգչային համակարգը կարող է ապահովել այդ software-ը:</li><li style="text-align: justify;">Ժամանակացույց – Հնարավո՞ր է նախագիծն ավարտել տրված ժամանակահատվածում, թե ոչ:</li></ol> <h3>3. Design</h3> Այս փուլում սահմանվում է համակարգի ընդհանուր ճարտարապետությունը: Այս փուլում մշակվում են երկու տեսակի նախագծային փաստաթղթեր՝ 1.High-Level Design (HLD) <ul><li style="text-align: justify;">Յուրաքանչյուր մոդուլի համառոտ նկարագրությունը եւ անվանումը</li><li style="text-align: justify;">Յուրաքանչյուր մոդուլի ֆունկցիոնալության մասին ուրվագիծ</li><li style="text-align: justify;">Մոդուլների միջեւ ինտերֆեյսային հարաբերությունները եւ կախվածությունները</li><li style="text-align: justify;">Տվյալների բազայի աղյուսակները `իրենց հիմնական տարրերի հետ միասին</li><li style="text-align: justify;">Ամբողջական ճարտարապետության գծապատկերները `տեխնոլոգիական մանրամասների հետ միասին</li></ul> 2.Low-Level Design(LLD) <ul><li style="text-align: justify;">Մոդուլների ֆունկցիոնալ տրամաբանությունը</li><li style="text-align: justify;">Տվյալների բազայի աղյուսակները, որոնք ներառում են տեսակը եւ չափը</li><li style="text-align: justify;">Ինտերֆեյսի ամբողջական մանրամասները</li><li style="text-align: justify;">Բոլոր կապակցված issue-ների հասցեները</li><li style="text-align: justify;">Error message-ների ցուցակը</li><li style="text-align: justify;">Բոլոր մուտքերը եւ ելքերը յուրաքանչյուր մոդուլի համար</li></ul> <h3>4. Coding</h3> Այս փուլում օգտագործելով ընտրված ծրագրավորման լեզուն ՝ developer-ները գրում են ծրագիրը: Կոդավորման փուլում առաջադրանքները բաժանվում են միավորների կամ մոդուլների եւ հանձնարարվում են տարբեր developer-ների: Սա SDLC-ի ամենաերկար փուլն է: <h3>5. Testing</h3> Ծրագիրը գրելուց հետո ուղարկվում է փորձարկման՝ թեստավորման: Թեստավորման թիմը կարող է հայտնաբերել սխալներ, որոնք նրանք փոխանցում են developer-ներին: Սխալը շտկելուց հետո ծրագիրը ուղարկում են re-testing-ի՝ վերափորձարկման եւ այս փուլը շարունակվում է այնքան, մինչեւ ծրագիրը դառնա bug-free, կայուն եւ հաճախորդի պահանջներին համապատասխան: <h3 style="text-align: justify;">6. Installation/Deployment</h3> Այս փուլում թողարկվում է վերջնական ծրագիրը եւ ստուգվում է, եթե առկա են տեղադրման խնդիրներ: <h3>7. Maintenance</h3> Երբ համակարգը տեղադրվում է եւ հաճախորդները սկսում են այն օգտագործել, տեղի են ունենում 3 գործողություններ՝ <ol><li style="text-align: justify;">Bug fixing - Հայտնաբերվում են Bug-եր՝ ընդհանրապես չփորձարկվածսցենարների պատճառով</li><li style="text-align: justify;">Upgrade - Application-ի թարմացում Software-ի նոր version-ների</li><li style="text-align: justify;">Enhancement- գործող Software-ում նոր առանձնահատկությունների ավելացում</li></ol> Այս փուլի հիմնական նպատակն է ապահովել, որ կարիքները շարունակաբար բավարարվեն, եւ որ համակարգը շարունակի գործել ըստ առաջին փուլում նշված պահանջների: Կան SDLC տարբեր մեթոդներ, օրինակ՝ Waterfall model, Agile model, Spiral model...: Waterfall model-ի դեպքում SDLC-ի մի փուլն ամբողջությամբ ավարտվում է, այնուհետեւ անցում է կատարում հաջորդ փուլին: Tester-ն աշխատում է միայն Testing-ի փուլում, եւ եթե դրանից առաջ կան սխալներ, որոնք չեն ուղղվել, ապա այս փուլում ուղղելը բավականին բարդ է, քանի որ ամեն ինչ պետք է սկսել նորից: Այս մոդելի առավելությունն այն է, որ փուլերն իրարից առանձին են աշխատում եւ սխալվելու հավանակաանությունը քիչ է, սակայն եթե լինեն սխալներ, ապա դրանք ուղղելը շատ թանկ կարժենա: Մեծ ընկերություններն աշխատում են Waterfal model-ով, քանի որ ունեն շատ աշխատակիցներ եւ առանձին department-ներ: V մոդելի դեպքում՝ Requirement analysis փուլում tester-ը կազմում է user acceptance test plan: Scenario-ները մտնում են դրա մեջ: Մինչ scenario-ները գրելը tester-ը պետք է ունենա որեւէ պլան, որը գլոբալ նկարագրում է, թե ինչ է պատրաստվում թեստավորել եւ ըստ այդ պլանի գրում է տարբեր scenario-ներ: Requirements-ները ստանալուց հետո, tester-ն արդեն կարող է կազմել որոշակի պլան: Functional specification փուլում կազմվում է system test plan-ը, որը ներառում է ֆունկցիոնալության մասին ինֆորմացիա: Այս փուլում tester-ը ստուգում է ամբողջ ծրագրի ֆունկցիոնալությունը: High Level Design փուլում կազմվում է Integration test plan: tester-ն իրականացնում է Integration test, որը ստուգում է, թե ինչպես են փոխազդում ծրագրրի առանձին մոդուլները: Low Level Design փուլում իրականացվում է Unit testing (առանձին մոդուլների test-եր), սա հիմնականում անում են Developer-ները: <blockquote style="text-align: justify;">Օգտակար հղումներ` <a href="https://www.youtube.com/watch?v=i-QyW8D3ei0" target="_blank">SDLC /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=_dr5zodeFQo" target="_blank">SDLC /video tutorial/rus</a> <a href="https://www.guru99.com/software-development-life-cycle-tutorial.html" target="_blank">SDLC /article/eng</a> <a href="https://habr.com/ru/company/dcmiran/blog/521718/" target="_blank">SDLC /article/rus</a></blockquote>

SDLC

<h3>Requirement Analysis</h3> Այս փուլում tester-ներն ուսումնասիրում են պահանջները թեստավորման տեսանկյունից: QA թիմը պահանջները մանրամասն հասկանալու համար կարող է հաղորդակցվել տարբեր մասնագետների հետ ( Business Analist, Technical Leads, System Architects, etc.): Պահանջները կարող են լինել ինչպես ֆունկցիոնալ, այնպես էլ ոչ ֆունկցիոնալ: Ավտոմատ թեստավորման իրագործելիությունը նույնպես այս փուլում է որոշվում: Activities:<ol><li style="text-align: justify;">Որոշվում են թեստավորման տիպերը, որոնք պետք է կիրառվեն:</li><li style="text-align: justify;">Հավաքվում է ինֆորմացիա առաջնահերթությունների եւ կենտրոնացվածության մասին:</li><li style="text-align: justify;">Պատրաստվում է Requirement Traceability Matrix (RTM), որը ցույց է տալիս PRD, FSD, եւ այլ դոկումենտների կապը:</li><li style="text-align: justify;">Որոշվում է միջավայրը, որտեղ իրականացվելու է թեստավորումը:</li><li style="text-align: justify;">Անհրաժեշտության դեպքում կատարվում է ավտոմատացման իրագործելիության ուսաումնասիրություն:</li></ol> Deliverables:<ol><li style="text-align: justify;">RTM</li><li style="text-align: justify;">Ավտոմատացման իրագործելիության հաշվետվություն:</li></ol> <h3>Test Planning</h3> Այս փուլում Senior QA manager-ը որոշում է test plan strategy-ն, պրոյեկտի համար անհրաժեշտ ռեսուրսներն ու ծախսերը, սահմանափակումները եւ ժամանակացույցը: Թեստային պլանը պատրաստվում եւ ավարտվում է նույն փուլում: Activities:<ol><li style="text-align: justify;">Testing-ի տարբեր տիպերի համար test plan/strategy-ի առաջարկում</li><li style="text-align: justify;">Test tool-երի ընտրություն</li><li style="text-align: justify;">Testing-ի ջանքերի գնահատում</li><li style="text-align: justify;">Ռեսուրսների պլանավորում, դերերի եւ պարտականությունների որոշում</li></ol> Deliverables:<ol><li style="text-align: justify;">Test plan /strategy document.</li><li style="text-align: justify;">Effort estimation document.</li></ol> <h3>Test Case Development</h3> Այս փուլը ներառում է test case-երի եւ test script-ների ստեղծումը, verification-ը եւ վերամշակումը: Որոշվում է test data-ն, ստեղծվում եւ վերամշակվում է՝ հիմնվելով նախապայմանների վրա: Այնուհետեւ QA թիմը սկսում է test case-երի development process-ը առանձին unit-ների համար: Activities:<ol><li style="text-align: justify;">Ստեղծել test case-եր եւ automation script-ներ, եթե անհրաժեշտ են:</li><li style="text-align: justify;">Վերանայել եւ հաստատել test case-երն ու script-ները:</li><li style="text-align: justify;">Ստեղծել test data, եթե թեստավորման միջավայրը հասանելի է:</li></ol> Deliverables:<ol><li style="text-align: justify;">Test cases/scripts</li><li style="text-align: justify;">Test data</li></ol> <h3>Test Environment setup</h3> Թեստավորման միջավայրը որոշում է ծրագրային եւ ապարատային ապահովման այն պայմանները, որոնց առկայությամբ աշխատող պրոդուկտը պետք է թեստավորվի: Այն Թեստավորման գործընթացի կարեւոր փուլերից մեկն է, որը կարելի է իրականացնել նաեւ Test Case Development փուլին զուգահեռ: Թեստավորման թիմը կարող է ներգրավված չլինել այս փուլում, այլ development team-ը ապահովի թեստավորման միջավայրը: Այդ դեպքում թեստավորման թիմից պահանջվում է միայն իրականացնել smoke testing: Activities:<ol><li style="text-align: justify;">Հասկանալ պահանջվող կառուցվածքը,պատրաստել ծրագրային եւ ապարատային ապահովման պահանջների ցուցակ թեստավորման միջավայրի համար</li><li style="text-align: justify;">Կառուցել թեստավորման միջավայրը եւ տվյալները</li><li style="text-align: justify;">Կառուցվածի վրա իրականացնել smoke test</li></ol> Deliverables:<ol><li style="text-align: justify;">Պատրաստ միջավայր թեստավորման համար տվյալների հետ միասին</li><li style="text-align: justify;">smoke test-ի արդյունքները</li></ol> <h3>Test Execution</h3> Այս փուլում թեստավորողը իրականացնում է թեստավորումը հիմնված test plan-ի եւ test case-երի վրա: Bug-երը պետք է գտնի եւ ուղարկի Development team-ին: Ուղղելուց հետո պետք է իրականացվի retesting: Activities:<ol><li style="text-align: justify;">Իրականացնել թեստավորում ըստ պլանի:</li><li style="text-align: justify;">Դոկումենտացնել թեստավորման արդյունքները եւ նշել դեֆեկտները</li><li style="text-align: justify;">Ձախողված դեպքերի համար:</li><li style="text-align: justify;">Դեֆեկտները նշել RTM-ում:</li><li style="text-align: justify;">Ուղղելուց հետո վերաթեստավորել:</li><li style="text-align: justify;">Վերահսկել մինչեւ հայտնաբերված դեֆեկտը փակվի:</li></ol> <h3>Test Cycle Closure</h3> (Retrospective meeting Agile-ում) - Թեստավորման ավարտին թեստավորման թիմի անդամները հանդիպում են թեստի արդյունքները ամփոփելու համար, քննարկում եւ վերլուծում են Test Cycle-ը՝ հետագայի համար դասեր քաղելով: Նպատակն է հետագա պրոյեկտների համար առանձնացնել Test Cycle-ի լավագույն տարբերակը: Activities:<ol><li style="text-align: justify;">Գնահատել cycle-ի Exit կրիտերիաները՝ հիմնվելով ժամանակի, Test coverage-ի, գնի, Software-ի, Critical Business Objectives-ի, Quality-ի վրա:</li><li style="text-align: justify;">Սահմանել թեստի չափանիշներ վերը նշված պարամետրերի հիման վրա:</li><li style="text-align: justify;">Դոկումենտացնել պրոյեկտի արդյունքում սովորածը:</li><li style="text-align: justify;">Պատրաստել թեստի փակման հաշվետվություն:</li><li style="text-align: justify;">Որակի մասին հաշվետվություն հաճախորդին:</li><li style="text-align: justify;">Թեստի արդյունքների վերլուծություն՝ դեֆեկտներն ըստ տեսակի եւ խստության բաշխելու համար:</li></ol> Deliverables:<ol><li style="text-align: justify;">Test Closure report</li><li style="text-align: justify;">Test metrics </li></ol> <blockquote style="text-align: justify;">Օգտակար հղումներ` <a href="https://www.youtube.com/watch?v=_3OhZrad8RM" target="_blank">STLC /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=HylDB3bN6hQ" target="_blank">STLC /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=An7HC1LolDM" target="_blank">SDLC vs STLC /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=ZoOX8Q92zqc" target="_blank">STLC /video tutorial/rus</a> <a href="https://www.guru99.com/software-testing-life-cycle.html" target="_blank">STLC /article/eng</a> <a href="https://ru.education-wiki.com/5141467-sdlc-vs-stlc" target="_blank">SDLC vs STLC /article/rus</a></blockquote>

 STLC

<h3>Verification</h3> Verification (Static Testing) – Այն իրականացվում է Requirement analysis եւ Design փուլերում: Սա կոդի, պահանջների եւ դիզայնի փաստաթղթերի ստուգման պրոցեսն է` որոշելու համար software-ը կառուցվա՞ծ է պահանջներին համապատասխան, թե՞ ոչ: Այս դեպքում կոդը չի իրականացվում: QA-ը համոզվում է, որ պահանջները ճիշտ են հասկացել եւ ճիշտ են design արել: Գլխավոր նպատակը software application-ի որակի ապահովումն է՝ development cycle-ի վաղ փուլերում error-ներ հայտնաբերելու միջոցով: Իրական կյանքից որպես օրնակ կարող ենք վերցնել թատրոնը։ Մինչ թատրոնը կհասնի վերջնական հանդիսատեսին, նախ եւ առաջ աչքի տակով անցկացնում են սցենարը եւ կատարում են տարբեր պարապմունքներ եւ փորձնական բեմադրություններ։ Սցենարի որեւէ սյուժէ ուսումնասիրելու ընթացքում ներկա են լինում սցենարիստը, բեմադրողը եւ դերասանները, որոնք ներգրավված են այդ սյուժեում։ Սցենարը կարդալիս ամեն մեկն անում է իր առաջարկները եւ գուցե գտնվում են թերություններ, որոնք ունեն շտկման կարիք։ Բեմադրության փորձերի ժամանակ ամեն սյուժե նորից խորապես քննարկվում է։ Հենց այսպիսի գործընթաց էլ տեղի է ունենում SDLC-ի ընթացքում։ Որոշակի կոդեր գրելուց հետո ուսումնասիրվում են ընդհանուր դակումենտացիան եւ այդ գրված կոդերը։ Այսինքն երբ կլիենտը ասում է, որ իրեն պետք է ծրագիր հետեւյալ ֆունկցիոնալներով եւ տալիս է պահանջների դոկումենտացիա, դեռ չի նշանակում, որ այդ պահանջներն ընթացքում չեն փոփոխվելու։ Դեվելոփմենթի ընթացքում առաջանում են զանազան լավ եւ հետաքրքիր մտքեր, ինչպես նաեւ երբեմն առաջանում են իրականացման խնդիրներ. դրանց շնորհիվ կամ պատճառով կարիք է լինում անընդհատ կապի մեջ լինել կլիենտի հետ եւ փոխհամագործակցության շնորհիվ հասնել լավ արդյունքի։ Ստատիկ թեստավորումը բաժանվում է երկու մասի՝ պահանջների փաստաթղթերի վերանայում(Review) եւ ստատիկ անալիզ (Static Analysis): Վերանայումը իր հերթին լինում է չորս տեսակի. <ol><li style="text-align: justify;">Ոչ ֆորմալ (Informal Reviews) - Ոչ ֆորմալ դիտարկման ընթացքում փաստաթղթերի ստեղծողը բովանդակությունը դնում է լսարանի առջեւ, եւ բոլորը տալիս են իրենց կարծիքը, եւ այդպիսով թերությունները հայտնաբերվում են վաղ փուլում:</li><li style="text-align: justify;">Քայլարշավ (Walkthroughs) - Հիմնականում դա իրականացվում է փորձառու անձի կամ փորձագետի կողմից` գրոհելու սխալները ստուգելու համար, որպեսզի հետագա դեվելոփմենթի կամ թեստավորման համար այլեւս խնդիրներ չլինեն:</li><li style="text-align: justify;">Գործընկերների ակնարկ (Technical Reviews) - Գործընկերների վերանայում նշանակում է միմյանց փաստաթղթերի ստուգում` թերությունները հայտնաբերելու եւ շտկելու համար: Դա հիմնականում արվում է թիմի շրջանակներում: Այսինքն ամեն դեվելոփեր կատարում է այդ պահանջների փաստաթղթի մի որոշ հատված եւ այդ հատվածը քննարկվում է հենց դեվելթփերների միջեւ։</li><li style="text-align: justify;">Տեսչություն (Inspections) - Փաստաթղթի ստուգումն, ըստ էության, ավելի բարձր մարմինների կողմից։</li></ol> Static Analysis-ը ներառում է developer-ի գրած կոդի որակի գնահատումը, վերլուծությունը եւ համեմատումը ստանդարտների հետ: Այն օգնում է գտնել հետեւյալ դեֆեկտները՝ <ul><li style="text-align: justify;">Չօգտագործված փոփոխականներ</li><li style="text-align: justify;">Dead code</li><li style="text-align: justify;">Անվերջ loop-եր</li><li style="text-align: justify;">Չորոշված արժեքով փոփոխականներ</li><li style="text-align: justify;">Սխալ syntax</li></ul> <h3>Validation</h3> Validation (Dynamic Testing) – Բուն թեստավորման պրոցեսն է, արդյոք ծրագիրը ճի՞ շտ է աշխատում, թե՞ ոչ, developer-ի ստեղծած ծրագիրը համապատասխանու՞ մ է սպասվածին, թե՞ ոչ: Validation-ի համար պատասխանատու է Tester-ը: Waterfall մեթոդի դեպքում սկզբում կատարվում է Verification-ը, այնուհետեւ բոլոր փուլերի ավարտից հետո կատարվում է Validation: Agile-ում դրանք իրականացվում են որքան հնարավոր է մոտ ժամանակահատվածում, միաժամանակ: Օրինակ՝ App-ում պետք է լինի Submet անունով սեղմվող կոճակ (clickable button): Verification<ul><li style="text-align: justify;">Կստուգի դիզայնի փաստաթուղթը եւ կուղղի ուղղագրական սխալները:</li><li style="text-align: justify;">Development թիմը կստեղծի այդպիսի կոճակ:</li></ul> Validation<ul><li style="text-align: justify;">Կոդը պատրաստ է, Validation արվել է եւ հայտնաբերել է, որ կոճակը սեղմվող չէ:</li><li style="text-align: justify;">Validation-ի շնորհիվ development team-ը կոճակը կդարձնի սեղմվող:</li></ul> <h3>Verification VS Validation</h3> <table style="border-collapse: collapse; width: 98.392%; height: 172px; margin-left: 0.552764%; text-align: justify;"><tbody>
<tr>
o<td style="width: 50%;">Verification </td>
o<td style="width: 50%;">Validation</td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">Ստուգման գործընթացը ներառում է փաստաթղթերի, դիզայնի, ծածկագրի և ծրագրի ստուգում: </td>
o<td style="width: 50%; vertical-align: middle;">Դա իրական արտադրանքի փորձարկման և վավերացման դինամիկ մեխանիզմ է: </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">Այն չի ներառում կոդի գործարկում: </td>
o<td style="width: 50%; vertical-align: middle;">Այն միշտ ներառում է կոդի կատարումը: </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">Verification-ի օգտագործում է այնպիսի մեթոդներ, ինչպիսիք են. վերանայումներ, ուսումնասիրություններ, ստուգումներ և աշխատասեղանների ստուգում և այլն: </td>
o<td style="width: 50%; vertical-align: middle;">Այն օգտագործում է մեթոդներ, ինչպիսիք են սև տուփի փորձարկումը, սպիտակ տուփի փորձարկումը և ոչ ֆունկցիոնալ փորձարկումը: </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">Ստուգվում է արդյոք software-ը համապատասխանում է տեխնիկական պայմաններին: </td>
o<td style="width: 50%; vertical-align: middle;">Այն ստուգում է, թե արդյոք software-ը համապատասխանում է հաճախորդի պահանջներին և ակնկալիքներին: </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">Այն հայտնաբերում է bug-եր զարգացման ցիկլի սկզբում: </td>
o<td style="width: 50%; vertical-align: middle;">Այն կարող է գտնել bug-եր, որոնք ստուգման գործընթացը չի կարող գտնել: </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">Թիրախը հավելվածների և software ճարտարապետությունն է, ճշգրտումը, ամբողջական դիզայնը, բարձր մակարդակը և տվյալների բազայի ձևավորումը և այլն: </td>
o<td style="width: 50%; vertical-align: middle;">Թիրախը փաստացի արտադրանք է: </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">QA թիմը ստուգում է կատարում և համոզվում, որ software-ը համապատասխանում է SRS փաստաթղթի պահանջին: </td>
o<td style="width: 50%; vertical-align: middle;">Փորձարկման խմբի մասնակցությամբ վավերացումն իրականացվում է software կոդի վրա: </td></tr>
<tr>
o<td style="width: 50%; vertical-align: middle;">Այն գալիս է validation-ից առաջ։ </td>
o<td style="width: 50%; vertical-align: middle;">Այն գալիս է verification-ից հետո։ </td></tr></tbody></table> <blockquote style="text-align: justify;">Օգտակար հղումներ` <a href="https://www.guru99.com/verification-v-s-validation-in-a-software-testing.html" target="_blank">Validation vs Verification /article/eng</a> <a href="https://smartbear.com/blog/verification-and-validation-the-difference/" target="_blank">Difference Between Verification and Validation /article/eng</a> <a href="https://testmatick.com/ru/validatsiya-i-verifikatsiya-ponyatiya-shodstva-i-otlichiya/" target="_blank">Validation vs Verification /article/rus</a> <a href="https://www.youtube.com/watch?v=qxitgylm1EU" target="_blank">Validation vs Verification /video tutorial/eng</a></blockquote>

Ի՞նչ է Verification-ը և ի՞նչ է Validation-ը

Verification, Validation

<h3>Integration testing</h3> Շատ application-ներ սովորաբար բաղկացած են լինում տարբեր մոդուլներից եւ ամեն մոդուլ հանձնարարվում է տարբեր թիմերի։ Այս մոդուլներն ընդհանուր կոնցեպտով, բայց անհատական կերպով իրականացվում են տարբեր թիմերի կողմից։ Այնուհետեւ դրանք ինտեգրվում են՝ միասին կազմելով ամբողջական համակարգ՝ Application, եւ սրա թեստինգը կոչվում է System testing: Բայց երբ application-ը դեռ development-ի փուլում է, եւ 2 կամ ավելի մոդուլներ համակցվում են այդ ընթացում եւ թեստավորվում, ապա այդ փուլը կոչվում է Integration testing ։ Այլ կեպ ասած Integration թեստինգը նույն System թեստինգն է՝ պարզապես ավելի քիչ թեստավորվող հատվածներով։ Integration թեստինգի մոտեցումներն են՝ Big Bang Approach-ի ժամանակ Unit testing անցած բոլոր փոքր մոդուլները հավաքվում են եւ միասին թեստավորվում են, որպես մեկ ամբողջական համակարգ: Առավելությունները՝ <ol><li style="text-align: justify;">Այս մոտեցումը հարմար է փոքր համակարգերի դեպքում:</li><li style="text-align: justify;">Հարմար է ժամանակի խնայողության տեսանկյունից:</li></ol> Թերությունները՝ <ol><li style="text-align: justify;">Դժվար է հասկանալ, թե որ մասում է հատնաբերված bug-ը:</li><li style="text-align: justify;">Հեշտությամբ հնարավոր է բաց թողնել որոշ ինտերֆեյսերի կապերի ստուգումը:</li><li style="text-align: justify;">Քանի որ բոլոր մոդուլները միանգամից են ստուգվում, հնարավոր է բաց թողնվեն կրիտիկական bug-եր կամ ամենակարեւոր մոդուլներին բավարար ուշադրություն չդարձվի:</li></ol> Incremental Approach-ը իրականացվում է կեղծ ծրագրերի միջոցով, որոնք կոչվում են Stub-եր եւ Driver-ներ: Stub –ը կանչվում է թեստավորվող մոդուլի կողմից,իսկ Driver-ը կանչում է թեստավորվող մոդուլը: Երբ դեռ որոշակի մոդուլներ բացակայում են, սրանք հնարավորություն են տալիս իրականացնել թեստավորումը՝ փոխարինելով այդ բացակայող մոդուլներին: Bottom Up – Թեստավորումը սկսվում է ցածր մակարդակ ունեցող մոդուլներից : Ստորին մակարդակի մոդուլները թեստավորելուց եւ ինտեգրելուց հետո ձեւավորվում են հաջորդ մակարդակի մոդուլները, եւ գործընթացը շարունակվում է մինչեւ վերին մակարդակի բոլոր մոդուլների փորձարկումը: Օրինակ, եթե ուզում ենք թեստավորել Profile էջը, բայց դեռ Login էջը պատրաստ չէ, գրում ենք դատարկ մոդուլ՝ Driver, որն իրենից ներկայացնում է ֆորմալ Login էջը: Top Down – Թեստավորումը սկսվում է բարձր մակարդակ ունեցող մոդուլներից: Բացակայող մոդուլները փոխարինվում են Stub-ով: Օրինակ, եթե ուզում ենք թեստավորել Login էջը, բայց Profile էջը դեռ չկա, Profile-ը փոխարինում ենք Stub-երով: <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/integration-testing.html" target="_blank">Integration testing /article/eng</a> <a href="https://u-tor.com/topic/integration-testing" target="_blank">Integration testing /article/eng</a> <a href="https://logrocon.ru/news/intgration_testing" target="_blank">Integration testing /article/rus</a> <a href="https://www.youtube.com/watch?v=cQ39AwhjxH8" target="_blank">Testing levels /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=QYCaaNz8emY" target="_blank">Integration testing /video tutorial/eng</a></blockquote>

Ի՞նչ է Integration testing-ը և ի՞նչպես է այն իրականացվում։

Integration testing

<h3>System testing</h3> System testing-ը ծրագրային ապահովման փորձարկում է, որն իրականացվում է ամբողջական, ինտեգրված համակարգի վրա՝ ստուգելու համար, որ համակարգը համապատասխանում է իր սկզբնական պահանջներին՝ ինչպես ֆունկցիոնալ, այնպես էլ ոչ ֆունկցիոնալ: Փորձարկման առարկան ընդգծված է կարմիրով: Կատարելով system testing՝ կարող եք հայտնաբերել հետևյալ տեսակի թերությունները. Համակարգի ռեսուրսների ոչ ճիշտ օգտագործում: Օգտագործողի տվյալների անսպասելի համակցություններ: Շրջակա միջավայրի համատեղելիության խնդիրներ. Չնախատեսված օգտագործման դեպքեր. Ֆունկցիոնալ պահանջների հետ անհամապատասխանություն: Վատ օգտագործելիություն. System testing-ն իրականացվում է «Սև արկղ» մեթոդով, քանի որ Ստուգվող հավաքածուն «արտաքին» սուբյեկտներ են, որոնք չեն պահանջում փոխազդեցություն ծրագրի ներքին կառուցվածքի հետ: Խորհուրդ է տրվում նաև այն իրականացնել վերջնական օգտագործողի միջավայրին հնարավորինս մոտ միջավայրում: System testing-ի 2 մոտեցում կա. Պահանջների հիման վրա. Թեստավորումն իրականացվում է ֆունկցիոնալ կամ ոչ ֆունկցիոնալ պահանջներին համապատասխան, որոնցից յուրաքանչյուրի համար գրվում է թեստային դեպք: Օգտագործման դեպքերի հիման վրա: Թեստավորումն իրականացվում է արտադրանքի օգտագործման դեպքերի համաձայն, որոնց հիման վրա ստեղծվում են օգտագործողների գործեր: Այս օգտագործողների դեպքերից յուրաքանչյուրի համար ստեղծվում են իրենց փորձարկման դեպքերը: System testing-ը ներառում է նաև ալֆա թեստավորում և բետա թեստավորում, որոնց էությունը մենք կքննարկենք հաջորդ հոդվածներում: <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/system-testing.html" target="_blank">System testing /article/eng</a> <a href="https://www.xenonstack.com/insights/what-is-system-testing" target="_blank">System testing /article/eng</a> <a href="https://beqa.pro/blog/testing-levels/" target="_blank">Testing levels /article/rus</a> <a href="https://www.youtube.com/watch?v=t-1Cw2e7PYc" target="_blank">System testing /video tutorial/rus</a></blockquote>

System testing

<h3>Acceptance testing</h3> <ul><li>Acceptance testing-ը իրականացվում է պատրաստի արտադրանքի (կամ արտադրանքի պատրաստի մասի) պատվիրատուին առաքման փուլում: Acceptance testing-ի նպատակն է որոշել արտադրանքի պատրաստվածությունը, որը ձեռք է բերվում թեստային սցենարների և դեպքերի անցնելու միջոցով, որոնք կառուցված են մշակվող ծրագրաշարի պահանջների ճշգրտման հիման վրա: Acceptance testing-ի արդյունքը կարող է լինել. Ուղարկել նախագիծը վերանայման: Հաճախորդի կողմից որպես ավարտված առաջադրանքի ընդունում: Սա&nbsp;Acceptance testing-ի վերջին փուլն է մինչև թողարկումը: Միևնույն ժամանակ, այն չափազանց մանրակրկիտ, համապարփակ և ամբողջական չէ. հիմնականում փորձարկված է միայն հիմնական ֆունկցիոնալությունը: Acceptance testing-ն իրականացվում է կա՛մ հաճախորդի կողմից, կա՛մ հաճախորդի շահերը ներկայացնող թեստավորողների խմբի, կա՛մ ծրագրավորող ընկերության փորձարկողների կողմից: Կախված է հաճախորդի ընկերության նախասիրություններից: </li></ul> <h3 style="text-align: justify;">Ալֆա թեստավորում </h3> Ալֆա թեստավորումը&nbsp;Acceptance testing-ի տեսակ է, որը սովորաբար իրականացվում է արտադրանքի մշակման ուշ փուլում և ներառում է արտադրանքի իրական օգտագործման մոդելավորում ներքին մշակողների կամ թեստավորողների թիմի կողմից: Սովորաբար, ալֆա թեստավորումը ներառում է ծրագրի բոլոր գործառույթների համակարգված փորձարկումը՝ օգտագործելով սպիտակ տուփի և սև տուփի փորձարկման տեխնիկան: Ալֆա թեստավորման առավելությունները. <ul><li>Ապահովում է ավելի լավ պատկերացում ծրագրային ապահովման հուսալիության վերաբերյալ վաղ փուլում:</li><li>Օգնում է մոդելավորել օգտատիրոջ վարքագիծը և շրջակա միջավայրը իրական ժամանակում:</li><li>Հայտնաբերում է բազմաթիվ լուրջ սխալներ: Հնարավորություն է տալիս նախագծման և ֆունկցիոնալ սխալների վաղ հայտնաբերումը: </li></ul> Ալֆա թեստավորման թերությունները. <ul><li>Ամբողջական ֆունկցիոնալությունը չի կարող փորձարկվել, քանի որ ծրագրաշարը դեռ մշակման փուլում է: Երբեմն մշակողները և փորձարկողները դժգոհ են ալֆա թեստավորման արդյունքներից: </li></ul><h3 style="text-align: justify;"> Beta testing&nbsp;</h3><ul><li> Բետա թեստավորումը արտադրանքի գրեթե ավարտված տարբերակի ինտենսիվ օգտագործումն է, որի նպատակն է բացահայտել դրա շահագործման մեջ առավելագույն թվով սխալներ, դրանց հետագա վերացման համար մինչև ապրանքի վերջնական թողարկումը շուկա, զանգվածային սպառողին: Բետա թեստավորումը ծրագրի իսկապես աշխատող տարբերակն է՝ լիարժեք ֆունկցիոնալությամբ: Իսկ բետա թեստերի խնդիրն է գնահատել ծրագրի հնարավորություններն ու կայունությունը դրա ապագա օգտագործողների տեսանկյունից։ Ի տարբերություն ալֆա թեստավորման, որն իրականացվում է ներքին ծրագրավորողների կամ փորձարկողների կողմից, բետա թեստավորումը ներառում է կամավորների հավաքագրում արտադրանքի սովորական ապագա օգտագործողներից, ովքեր մուտք ունեն արտադրանքի նշված նախնական տարբերակը (այսպես կոչված, բետա տարբերակը): Այս կամավորները (կոչվում են բետա փորձարկողներ) հաճախ առաջնորդվում են նոր արտադրանքի նկատմամբ հետաքրքրասիրությամբ. հետաքրքրասիրություն հանուն որի նրանք պատրաստ են համակերպվել դեռևս չհայտնաբերված սխալների հետևանքները զգալու հնարավորության հետ (և հետևաբար՝ ոչ: ուղղվել է): Հետաքրքրասիրությունից բացի, մոտիվացիան կարող է պայմանավորված լինել զարգացման գործընթացի վրա ազդելու ցանկությամբ և, ի վերջո, ձեռք բերել այնպիսի արտադրանք, որն ավելի շատ կբավարարի նրանց կարիքները և շատ ավելին: Շատ լավ է, եթե սրանք մարդիկ են, ովքեր արդեն ունեն այս տեսակի ծրագրերի հետ աշխատելու փորձ, իսկ ավելի լավ՝ նույն ծրագրի նախորդ տարբերակով։ Որպես կանոն, ընկերություններն արդեն ունեն մարդկանց որոշակի շրջանակ, որոնց հետ նրանք անընդհատ համագործակցում են: Բետա թեստավորումը կարող է լինել. Փակ. Ծրագիրը փորձարկվում է օգտատերերի փոքր խմբում հրավերով: Բաց: Այս տարբերակը թույլ է տալիս փորձարկել հավելվածը ավելի մեծ խմբի հետ և ստանալ շատ արձագանքներ: Ցանկացած օգտատեր կկարողանա միանալ բաց բետա-ին և անձնական կարծիք հայտնել: </li></ul> <ul><li>Բաց բետա թեստավորումը, օրինակ, կարող է օգտագործվել որպես ապրանքի շուկա դուրս գալու ռազմավարության մաս (օրինակ՝ անվճար տրամադրել բետա տարբերակները՝ ապրանքի վերջնական, թանկ տարբերակի նկատմամբ սպառողների լայնածավալ ուշադրություն գրավելու համար) և վաղ արձագանքներ ստանալու համար։ ապագա օգտագործողների լայն շրջանակի արտադրանքի վրա: Պետք է ասել, որ ծրագրավորողները նման աշխատանքներին մասնակցելու ցանկություն ունեցողների պակաս չունեն։ Նման համագործակցությունը ձեռնտու է երկու կողմերին, քանի որ ավելի հեշտ է ուղղումներ կատարել աշխատանքային գործընթացի ընթացքում, այլ ոչ թե այն ավարտվելուց հետո, և բացի այդ, օգտվողների մեկնաբանությունները և առաջարկությունները թույլ են տալիս մեզ ավելի լավ և որակյալ դարձնել ծրագրակազմը: Բետա թեստավորման առավելությունները. Նվազեցնում է արտադրանքի ձախողման ռիսկը հաճախորդի վավերացման միջոցով: Բետա թեստավորումը թույլ է տալիս ընկերությանը փորձարկել ենթակառուցվածքը գործարկումից հետո: Բարելավում է արտադրանքի որակը հաճախորդների հետադարձ կապի միջոցով: Դա տվյալների հավաքագրման խնայող մեթոդ է՝ համեմատած նմանատիպ մեթոդների հետ: Ստեղծում է բարի կամք հաճախորդների հետ և մեծացնում հաճախորդների գոհունակությունը: </li></ul> <ul><li>Բետա թեստավորման թերությունները. Թեստի կառավարումը խնդիր է: Համեմատած թեստավորման այլ տեսակների հետ, որոնք սովորաբար իրականացվում են ներքին պայմաններում վերահսկվող միջավայրում, բետա թեստավորումն իրականացվում է իրական աշխարհում, որտեղ ընկերությունը հազվադեպ է վերահսկում: Ճիշտ բետա օգտագործողներին գտնելը և նրանց ներգրավված պահելը կարող է դժվար լինել: </li></ul> <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/user-acceptance-testing.html" target="_blank">User acceptance testing /article/eng</a> <a href="https://www.istqb.org/certifications/acceptance-tester" target="_blank">Acceptance testing /article/eng</a> <a href="https://www.calltouch.ru/blog/glossary/uat-testirovanie/" target="_blank">Acceptance testing /article/rus</a> <a href="https://www.youtube.com/watch?v=JDD5EEJgpHU" target="_blank">Writing acceptance tests /video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=uhkREQbRl-k" target="_blank">Acceptance testing /video tutorial/rus</a></blockquote>

Acceptance testing

<h3>White Box testing</h3> White Box testing-ի ժամանակ ուսումնասիրվում է software-ի ներքին կառուցվածքը, դիզայնը եւ կոդավորումը: Այս դեպքում թեստավորողին հայտնի է ներքին implementation-ը, այդ պատճառով այն կոչվում է նաեւ Clear box testing, Open box testing, Transparent box testing, Code-based testing եւ Glass box testing: Այն իրականացվում է system, integration եւ unit level-ներում: Այն կարող է սկսվել SDLC-ի վաղ փուլերում, անգամ երբ GUI-ն անհասանելի է: White Box testing-ի test case-երը հեշտ են ավտոմատացվում, սակայն բավականին բարդ է, պահանջում է մասնագիտական մեծ ռեսուրսներ եւ շատ ժամանակ: <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/white-box-testing.html" target="_blank">White-box testing article/eng</a> <a href="https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/testirovanie-belogo-iashchika" target="_blank">White-box testing article/rus</a> <a href="https://www.youtube.com/watch?v=a-nn_lXf1uA" target="_blank">White-box testing video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=AqoMSfErDSE" target="_blank">White,Black and Gray box testing video tutorial/rus</a> <a href="https://www.mend.io/blog/white-box-testing/" target="_blank">White-box testing article/eng</a> </blockquote>

White Box testing

<h3>Black Box testing</h3> Black Box Testing-ը software testing-ի մեթոդ է, որի ժամանակ ծրագրային հավելվածների ֆունկցիոնալությունը փորձարկվում է առանց ներքին կոդի կառուցվածքի, իրականացման մանրամասների և ներքին ուղիների իմացության: Black Box Testing-ը հիմնականում կենտրոնանում է ծրագրային հավելվածների մուտքագրման և ելքի վրա և այն ամբողջությամբ հիմնված է software-ի պահանջների և բնութագրերի վրա: Այն նաև հայտնի է որպես behavior թեստավորում:<img src="https://lh5.googleusercontent.com/BF1GkBhK3QsDQYJn0s_ajSvJ13kZxF4xQktFWfy46Vanm_6k_lfvSHU7nApNI6QKX3uQgc6HJG81i1hZKOo3CS9EwfFcx7wpyuh25g9YnLEZkidv9fVdrj-NK28WIp53evMMXQkHRgymiiTRlQVLfWo" width="624" height="152" style="margin-left:0px;margin-top:0px;">Վերոնշյալ Black-Box-ը կարող է լինել ցանկացած software, որը ցանկանում եք փորձարկել: Օրինակ՝ Windows-ի նման օպերացիոն համակարգ, Google-ի նման վեբկայք, Oracle-ի նման տվյալների բազա կամ նույնիսկ ձեր սեփական հատուկ հավելվածը: Black Box Testing-ի ներքո դուք կարող եք փորձարկել այս հավելվածները՝ պարզապես կենտրոնանալով մուտքերի և ելքերի վրա՝ առանց իմանալու դրանց ներքին կոդի ներդրումը: <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/black-box-testing.html" target="_blank">Black-box testing article/eng</a> <a href="https://www.imperva.com/learn/application-security/black-box-testing/" target="_blank">Black-box testing article/eng</a> <a href="https://quality-lab.ru/blog/key-principles-of-black-box-testing/" target="_blank">Black-box testing article/rus</a> <a href="https://www.youtube.com/watch?v=O7j3tBXO23M" target="_blank">Black-box vs White-box testing video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=joTjpiohrQw" target="_blank">Black-box testing video tutorial/rus</a></blockquote>

Black Box testing

<h3>Gray Box testing</h3> Gray box testing-ը White box testing-ի եւ Black box testing-ի խառնուրդն է: Ներքին implementation-ից որոշակի մաս նույնպես հայտնի է թեստավորողին: <img src="https://lh6.googleusercontent.com/GQqrgFt4THJtgs22YO9VjqpNZgHjCWv6bqNSSOOHGtrO7nZ-L4p_LsRyFLY1UqS64VTm8wEDRttErPdjISjPVOpm-VI8ZzvgnnQLzHXWqcnp8E3Z11QGEG3t0fqDjoymuZh0-40mfjp8B3MqCRQw3RY" width="624" height="217" style="margin-left:0px;margin-top:0px;">Օրինակ՝ Website-ի link-երի թեստավորման ժամանակ, եթե թեստավորողը հանդիպում է որեւէ արգելքի, կարող է անմիջապես HTML կոդում փոփոխություններ անել եւ կրկին ստուգել: <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/grey-box-testing.html" target="_blank">Gray-box testing article/eng</a> <a href="https://www.mend.io/resources/blog/gray-box-testing/" target="_blank">Gray-box testing article/eng</a> <a href="https://ru.education-wiki.com/7781700-gray-box-testing" target="_blank">Gray-box testing article/rus</a> <a href="https://www.youtube.com/watch?v=x-tNXvvz_KA" target="_blank">Gray-box testing video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=VD5tOODUOzs" target="_blank">Gray-box testing video tutorial/eng</a></blockquote>

Gray Box testing

<h3>Ad Hoc մեթոդ</h3> Ad-Hoc testing-ը թեստավորման տեսակ է, որն իրականացվում է առանց արտադրանքի փորձարկման նախապատրաստման, առանց ակնկալվող արդյունքների սահմանման կամ փորձարկման սցենարների նախագծման: Սա ոչ ֆորմալ, իմպրովիզացիոն թեստ է: Այն չի պահանջում որևէ փաստաթուղթ, պլանավորում, գործընթաց, որը պետք է հետևել թեստավորումն իրականացնելիս: Փորձարկման այս մեթոդը շատ դեպքերում առաջացնում է վրիպակների ավելի մեծ թվով հաշվետվություններ: Դա պայմանավորված է նրանով, որ փորձարկիչը առաջին քայլերում սկսում է փորձարկել արտադրանքի հիմնական ֆունկցիոնալ մասը և կատարում է հնարավոր սցենարների և՛ դրական, և՛ բացասական տարբերակները: Ամենից հաճախ նման փորձարկումն իրականացվում է, երբ ապրանքի սեփականատերը չունի կոնկրետ նպատակներ, նախագծային փաստաթղթեր և նախկինում առաջադրված խնդիրներ: Այս դեպքում փորձարկողը հիմնվում է արտադրանքի ընդհանուր պատկերացումների, նմանատիպ ապրանքների հետ համեմատության և սեփական փորձի վրա: Այնուամենայնիվ, ad-hoc թեստավորման ժամանակ իմաստ ունի արտադրանքի մասին ընդհանուր տեղեկատվություն ունենալ, հատկապես, եթե նախագիծը շատ բարդ է և մեծ: Ուստի անհրաժեշտ է լավ հասկանալ նախագծի նպատակները, դրա նպատակը և հիմնական գործառույթներն ու հնարավորությունները: Եվ հետո կարող եք սկսել ժամանակավոր թեստավորում: Ad-hoc թեստավորման տեսակները. Buddy testing-ը մի գործընթաց է, որտեղ երկու հոգի, սովորաբար մշակողն ու փորձարկողը, զուգահեռ աշխատում են և թերություններ են գտնում փորձարկվող արտադրանքի նույն մոդուլում: Այս տեսակի թեստավորումն օգնում է փորձարկողին կատարել անհրաժեշտ ստուգումներ, իսկ մշակողին՝ շտկելու բազմաթիվ թերություններ վաղ փուլերում: Pair testing-ը գործընթաց է, որտեղ 2 թեստավորողներ փորձարկում են մեկ մոդուլ և օգնում միմյանց: Օրինակ՝ կարելի է թերություններ փնտրել, իսկ երկրորդը՝ դրանք փաստագրել։ Այսպիսով, մի փորձարկիչը կունենա, այսպես ասած, դետեկտորի ֆունկցիա, իսկ մյուսը՝ նկարագրող ֆունկցիա։Monkey testing-ը արտադրանքի կամայական փորձարկումն է՝ նպատակ ունենալով կոտրել ծրագիրը կամ ստիպել այն հնարավորինս արագ դադարեցնել՝ օգտագործելով մուտքային տվյալների տարբեր տատանումներ (պարզ բառերով՝ կոտրել այն): Buddy testing-ի և Pair testing-ի միջև տարբերությունները. Buddy testing-ը միավորի փորձարկման և համակարգի փորձարկման համադրություն է մշակողի և փորձարկողի միջև: Pair testing-ը իրականացվում է միայն տարբեր մակարդակների գիտելիքներով և փորձով փորձարկողների կողմից (այս համադրությունը կօգնի կիսվել տեսակետներով և գաղափարներով): Ad-Hoc թեստավորման հիմնական առավելությունները. Փաստաթղթերի պատրաստման համար ժամանակ վատնելու կարիք չկա. Ամենակարևոր թերությունները հաճախ հայտնաբերվում են վաղ փուլերում. Հաճախ օգտագործվում է նոր աշխատող ընդունելիս: Օգտագործելով այս մեթոդը, մարդը 3 օրվա ընթացքում սովորում է, թե ինչ կպահանջվի թեստային դեպքերով զբաղվելու համար մեկ շաբաթ.&nbsp;Դժվար վերարտադրվող և խուսափողական թերություններ գտնելու ունակություն, որոնք անհնար կլինի գտնել ստանդարտ թեստային սցենարների միջոցով: Ad-Hoc թեստավորման օրինակ. Մենք հաճախ օգտագործում ենք Ad-Hoc testing-ը մեր կյանքում, օրինակ՝ սովորական սուպերմարկետ գնալը․ Սուպերմարկետ մտնելուց հետո, հենց մուտքի մոտ կարող եք գտնել մթերքների համար նախատեսված զամբյուղ, բայց եթե այն սովորական տեղում չէ, սա կարելի է համարել bug։ Կաթն ընտրելիս ուշադրություն դարձրեք պիտանելիության ժամկետին և եթե կաթը ժամկետանց է, էլի bug կլինի։ Դա նույնն է այլ ապրանքների դեպքում: Եվ, եթե ի վերջո, դրամարկղում գնումների համար վճարելիս գինու շիշը, որի վրա գրված է 100 դրամ, պարզվի, որ արժե 200, սա նույնպես bug կլինի։ Եթե ​​մեզ անհրաժեշտ է առցանց խանութի Ad-Hoc testing, ապա այս կարճ ցուցակը կարող է օգնել մեզ հասկանալ, թե ինչը պետք է ստուգել. Կայքի բոլոր հնարավորությունները հասանելի են առանց գրանցման. Անիմացիաների և նկարների ճիշտ ցուցադրում; Կայքի բոլոր հնարավորությունները հասանելի են գրանցումից հետո; Գրանցման գործընթաց; Զամբյուղից ավելացնելու/հանելու գործընթաց; Գնումների համար վճարման գործընթաց; Օգտագործման հարմարավետություն սկսնակների համար, պարզություն, խորհուրդներ, օգնություն: Հարկ է նաև նշել, որ Ad-Hoc թեստավորումը հաճախ թեստավորման սիրված տեսակ է թեստավորողների համար, որտեղ նրանք կարող են ցույց տալ իրենց ողջ գիտելիքները և կատարել ամենադժվար կանխատեսելի սցենարները, այսինքն՝ տալիս են զուտ իմպրովիզացիայի հնարավորություն։ Ad-Hoc թեստավորման արդյունավետության բարձրացման ուղիները. Նախապատրաստում. Վերլուծել նմանատիպ ծրագրերի թերությունները, դրանով իսկ մեծացնելով փորձարկվող հավելվածում նմանատիպ թերություններ գտնելու հավանականությունը: Նախագծի ձևավորում. Սա չպետք է լինի մանրամասն փորձարկման պլան, այլ ուրվագիծ, թե որտեղից սկսել և ինչ խնդիրներ փնտրել: Նիստի թեստավորում. Փորձարկել տարբեր արտադրանքի ֆունկցիոնալությունը մեկ առ մեկ, այսինքն. ոչ բոլորը միանգամից. Սա օգնում է ավելի լավ կենտրոնանալ և հասկանալ խնդիրները: Կենտրոնանալ թիրախային տարածքների վրա: Առաջին հերթին ստուգել այն տարածքները, որոնք չեն ընդգրկված թեստային նախագծով և փորձարկման փաստաթղթերով: Տարբեր օժանդակ ծրագրերի օգտագործում: Որոշ թերություններ կարելի է հայտնաբերել վրիպազերծիչների, պրոֆիլների և մոնիտորինգի միջոցով: Նման կոմունալ ծառայությունների իմացությունը օգնում է թեստավորմանը: Գրանցել թեստի արդյունքները: Գրառումներ, թե ինչ սխալներ են հայտնաբերվել, հավելվածի որ մասերում դրանք ավելի շատ են և այլն: Սա կարող է օգնել ինչպես մշակողներին, այնպես էլ հավելվածի ապագա տարբերակների փորձարկողներին: Կարող եք նաև գրել այն, ինչ չի ստացվել, քանի որ... Վերլուծաբանների համար կարող է օգտակար լինել տեսնել, թե ինչն է լավ աշխատել: Exploratary testing Ad-Hoc testing-ը թեստավորման տեսակ է, որն իրականացվում է առանց արտադրանքի փորձարկման նախապատրաստման, առանց ակնկալվող արդյունքների սահմանման կամ փորձարկման սցենարների նախագծման: Սա ոչ ֆորմալ, իմպրովիզացիոն թեստ է: Այն չի պահանջում որևէ փաստաթուղթ, պլանավորում, գործընթաց, որը պետք է հետևել թեստավորումն իրականացնելիս: Փորձարկման այս մեթոդը շատ դեպքերում առաջացնում է bug-երի ավելի մեծ թվով հաշվետվություններ: Դա պայմանավորված է նրանով, որ փորձարկիչը առաջին քայլերում սկսում է փորձարկել արտադրանքի հիմնական ֆունկցիոնալ մասը և կատարում է հնարավոր սցենարների և՛ դրական, և՛ բացասական տարբերակները: Եթե ​​փորձարկողի կատարած յուրաքանչյուր հաջորդ թեստն ընտրվում է նախորդ թեստի արդյունքների հիման վրա, դա նշանակում է, որ մենք օգտագործում ենք հետախուզական թեստավորում: Հիմնական բանը, որ պետք է հիշել Exploratory testing-ի մասին, այն է, որ դա ինքնին փորձարկման տեխնիկա չէ: Ավելի շուտ, դա մոտեցում է, որը կարող է կիրառվել ցանկացած տեսակի թեստավորման համար: Մեկ այլ կարևոր կետ այն է, որ Exploratory testing-ը միայն թեստերի անցկացման մասին չէ: Փորձարկողները կարող են օգտագործել Exploratory testing ինչպես կրկնության սկզբում նոր թեստեր մշակելիս, այնպես էլ ավարտված թեստերը վերանայելիս: Նաև Exploratory testing-ը չպետք է կատարվի անզգույշ, հապճեպ կամ առանց նախապատրաստման: Exploratory testing-ը կարող է պահանջել շատ զգույշ և երկար նախապատրաստություն որոշակի թեստերի համար, և փորձարկողի կուտակած գիտելիքներն ու հմտությունները, օգտագործելով այս մոտեցումը երկար տարիների ընթացքում, հաճախ անտեսանելի, բայց պատրաստման կարևոր ձև են: Exploratory testing-ը կարող է իրականացվել մանուալ կամ կարող է իրականացվել ավտոմատացման գործիքների լայնածավալ օգտագործմամբ, այսինքն. ցանկացած օժանդակ փորձարկման գործիք: Ե՞րբ պետք է օգտագործվի Exploratory testing Ամենատարածված դեպքերը. երբ դուք պետք է արագ արձագանքեք նոր ապրանքի կամ նոր արտադրանքի ֆունկցիոնալության համար. երբ դուք պետք է արագ ծանոթանաք ապրանքին. երբ փորձարկման հիմնական տեսակներն արդեն իրականացվել են, և ժամանակը թույլ է տալիս դիվերսիֆիկացնել փորձարկման մեթոդները. երբ պետք է հնարավորինս կարճ ժամանակում գտնել կոնկրետ մոդուլում տեղայնացված թերություն. երբ ստուգվում է մեկ այլ թեստավորման մասնագետի աշխատանքը. երբ անհրաժեշտ է ուսումնասիրել կոնկրետ ռիսկի վիճակը՝ որոշելու համար, թե արդյոք անհրաժեշտ է որոշակի տարածք ծածկել թեստերով։ <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/adhoc-testing.html" target="_blank">Ad-hoc testing article/eng</a> <a href="https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/spetsialnoe-testirovanie" target="_blank">Ad-hoc testing article/rus</a> <a href="https://www.youtube.com/watch?v=Nk_bC9WmuC4" target="_blank">Ad-hoc testing video tutorial/eng</a></blockquote>

Ի՞նչ է թեստավորման Ad Hoc method-ը։

Ad Hoc method

<h3>Manual testing</h3> 1.Manual testing-ը ծրագրային ապահովման փորձարկման տեսակ է, որտեղ փորձարկողները manual կերպով կատարում են թեստային դեպքեր՝ առանց որևէ ավտոմատացման գործիք օգտագործելու: Manual testing-ը փորձարկման բոլոր տեսակներից ամենապրիմիտիվն է և օգնում է ծրագրային համակարգում bug-եր գտնել:2.Ցանկացած նոր հավելված պետք է manual թեստավորվի՝ նախքան դրա փորձարկումը ավտոմատացնելը: Manual testing-ը ավելի շատ ջանք է պահանջում, սակայն անհրաժեշտ է ավտոմատացման իրագործելիությունը ստուգելու համար:3.Manual testing-ը չի պահանջում որևէ փորձարկման գործիքի իմացություն: Manual testing-ի նպատակները 1.Manual testing-ի հիմնական գաղափարն այն է, որ հավելվածը bug-free է և այն աշխատում է նշված ֆունկցիոնալ պահանջներին համապատասխան:2.Թեստային հավաքածուները կամ դեպքերը նախագծված են փորձարկման փուլում և պետք է ունենան 100% թեստային ծածկույթ:3.Այն նաև ապահովում է, որ հաղորդված թերությունները շտկված են մշակողների կողմից, և փորձարկողների կողմից վերստին փորձարկում է կատարվել ֆիքսված թերությունների վրա:4.Հիմնականում այս թեստավորումը ստուգում է համակարգի որակը և հաճախորդին մատակարարում է առանց սխալների արտադրանք <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/manual-testing.html" target="_blank">Manual testing article/eng</a> <a href="https://www.softwaretestinghelp.com/manual-testing-tutorial-1/" target="_blank">Manual testing article/eng</a> <a href="https://www.youtube.com/watch?v=AjkYTJklAa8" target="_blank">Manual testing video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=1lHCM2Br2eA" target="_blank">Manual testing video tutorial/ru</a></blockquote>

Ինչպե՞ս է կատարվում Manual testing-ը։

Manual testing

<h3>Selenium locators</h3> Սելեկտորներ / տեղորոշիչներ ըստ` - ID-ի - name-ի - name-ի` օգտագործելով filters - հղումային տեքստի (link text) - CSS սելետորների - XPath-ի Ուսումնասիրենք CSS սելեկտորները, որոնք օգտագործվում են Web էջի էլեմենտների ընտրության համար։ Ունիվերսալ սելեկտոր Ընտրում է բոլոր էլեմենտները։ Ցանկության դեպքում կարող է սահմանափակվել տվյալ անունների տարածությունում կամ ամբողջ անունների տարածությանը։ Քերականություն՝ * ns|* *|*Օրինակ՝ * - կհամապատասխանի էջի բոլոր էլեմենտներին։ Սելեկտորներ՝ ըստ էլեմենտի տիպի Այս հիմնական սելեկտորի միջոցով ընտրվում է այն էլեմենտը, որի նկատմամբ կկիրառվի կանոնը։ Քերականություն՝ էլեմենտ Սելեկտորներ՝ ըստ class-ի Այս հիմնական սելեկտորը ընտրում է էլեմենտները՝ նրանց class ատրիբուտի (հատկանիշի) արժեքի հիման վրա։ Քերականություն՝ ․class-ի անուն Օրինակ՝ .index սելեկտորը ընտրում է այդ class-ին համապատասխանող բոլոր էլեմենտները (class="index")։ Սելեկտորներ՝ ըստ իդենտիֆիկացիայի Այս հիմնական սելեկտորը ընտրում է էլեմենտները՝ հիմնվելով նրանց id ատրիբուտի (հատկանիշի) արժեքի վրա: Իդենտիֆիկատորը պետք է լինի եզակի, այսինքն՝ օգտագործվի HTML-փաստաթղթի միայն մեկ էլեմենտի համար։ Քերականություն՝ #իդենտիֆիկատորի անուն Օրինակ՝ Սելեկտոր #toc-ը ընտրում է toc իդենտիֆիկատորով էլեմենտը (id="toc")։ Սելեկտորներ՝ ըստ ատրիբուտի Այս սելեկտորը ընտրում է էլեմենտները, որոնք ունեն տվյալ ատրիբուտը կամ որոշակի արժեքով ատրիբուտ։ Քերականություն՝ [attr] [attr=value] [attr~=value] [attr|=value] [attr^=value] [attr$=value] [attr*=value] Օրինակ 1՝ [autoplay] սելեկտորը ընտրում է բոլոր այն էլեմենտները, որոնք ունեն autoplay ատրիբուտը՝ անկախ այդ ատրիբուտի արժեքից։ Օրինակ 2՝ a[href$=".jpg"] ընտրում է այն բոլոր հղումները, որտեղ հասցեն ավարտվում է «.jpg»-ով։ Օրինակ 3՝ a[href^="https"] ընտրում է այն բոլոր հղումները, որտեղ հասցեն սկսվում է «https»-ով։ Օրինակ 4՝ [title~=flower] ընտրում է այն բոլոր էլեմենտները, որոնց title ատրիբուտը պարունակում է «flower» բառը։ Օրինակ 5՝ a[href*="w3schools"] ընտրում է այն բոլոր հղումները, որոնց href ատրիբուտի արժեքը պարունակում է «w3schools» ենթատողը։ Կոմբինատոր «,» Կոմբինատոր «,»-ը խմբավորման միջոց է, որը ընտրում է բոլոր համապատասխանող հանգույցները։ Քերականություն՝ A, B Օրինակ՝ div, span, վերցնում է երկու էլեմենտն էլ․ և՛ <div> և ։ Կոմբինատոր « » Կոմբինատոր « » (բացատ) ընտրում է այն էլեմենտները, որոնք գտնվում ենք նշված էլեմենտի ներսում (անկախ գտնվելու մակարդակից)։ Քերականություն՝ A B Օրինակ՝ div span սելեկտորը ընտրում է այն բոլոր էլեմենտները, որոնք գտնվում են <div> էլեմենտի ներսում։ Դուստր սելեկտորներ «&gt;» կոմբինատորը ի տարբերություն բացատի ընտրում է միայն այն էլեմենտները, որոնք հանդիսանում են դուստր էլեմենտ նշված էլեմենտի համար (միայն նշված էլեմենտի ներսում լինելը բավարար պայման չէ)։ Քերականություն՝ A &gt; B Օրինակ՝ ul &gt; li ընտրում է միայն <li> դուստր էլեմենտները, որոնք գտնվում են ul էլեմենտի ներսում, բայց ul-ը հանդիսանում է </li><li> էլեմենտի անմիաջապես ծնող էլեմենտը։ Բոլոր հարևան էլեմենտների կոմբինատոր «~» ընտրում է այն էլեմենտները, որոնք գտնվում են նույն մակարդակում՝ նշված էլեմենտից հետո և ունեն նույն ծնողը։ Քերականությունը՝ A ~ B Օրինակ՝ p ~ span ընտրում է բոլոր էլեմենտները, որոնք գտնվում են էլեմենտից հետո և գտնվում են միևնույն ծնողի ներսում։ Հաջորդ հարևան էլեմենտի կոմբինատոր «+» կոմբինատորը ընտրում է այն էլեմենտը, որը ուղղակիորեն գտվում է նշված էլեմենտից հետո, եթե ունեն ընդհանուր ծնող։ Քերականութուն՝ A + B Օրինակ՝ ul + li սելեկտորը ընտրում է ցանկացած </li><li>, որը ուղղակիորեն գտնվում է <ul> էլեմենտից հետո։ </ul></li></div></div> Տերմինաբանություն Get – URL Path+header Past – URL Path+header+body Put – URL Path+bodyDelete – URL Path - <h3>Docker</h3> Պատկերացնենք իրավիճակ, որ կոդը աշխատում է Development Environment-ում, բայց Testing Environment-ում՝ ոչ: Docker-ը գործիքամիջոց է, որը նախատեսված է լուծելու վերը նշված խնդիրները, այսինքն՝ երբ կոդը աշխատում է մի միջավայրում, իսկ մյուսում՝ ոչ։ SDLC-ում Docker-ը աշխատում է deployment-ի փուլում։ Այն, օգտագործելով container-ներ, դարձնում է App-ի development-ի ընթացքը հեշտ և արդյունավետ։ Container-ները հնարավորություն են տալիս Developer-ներին «փաթեթավորել» App-ը մեկ package-ի մեջ, իրեն անհրաժեշտ բոլոր մասերի հետ միասին (libraries, dependencies) և «անվտանգ ուղարկել» այնտեղ, որտեղ անհրաժեշտ է։ <img src="https://lh5.googleusercontent.com/bKoWtSZ6g6kp95CwVID5868xBqCqyqTVFLbShrGTBHjBcgkikaw68zuZHDMvOgXxIA8lbc4kZ00Gut20Cn9cy4Aqt-A1R0bxEy11-sZpBbxOyrlsMH8cTumosSKlRNW0wZjf5eqxzBYfE2OABk5IVnc" width="624" height="209" style="margin-left:0px;margin-top:0px;">Տերմինաբանություն docker ps – ցույց է տալիս container-ները։ docker-compose build – տեղադրում է docker image-ները համակարգչում։ docker images – ցույց է տալիս build-ից հետո հայտված image-ները։ Հնարավոր է հայտնվեն image-ներ, որոնք չեն օգտագործվում docker image prune – նախատեսված է վերը նշված չօգտագործվող image-ները ջնջելու համար։ Եթե ավելացնենք -a, ապա կջնջվեն բոլոր image-ները։ docker image up -d – սկզբում ստուգում է image-ները։ Եթե անհրաժեշտ է որևէ մեկը, բայց չկա, ապա ավելացնում է և հետո up-է անում։ Նոր ավելացված imag-ների մոտ նշում է արվում։ Եթե կարգավիճակը (status) healthy է, ապա արդեն up-է։ Արդյունքում բոլորը պետք է լինեն healthy: -d-ն նախատեսված է log-երը ցույց չտալու համար։ <h3>Jenkins</h3> Jenkins-ը Continuous Integration գործիքամիջոց է, որի միջոցով ավտոմատացվում է test-երի գործարկումը (run): Որևէ գործողությունից հետո ավտոմատ գործարկվում է Trigger-ների միջոցով։ Այն դեպքում, երբ Git-ի master branch-ի վրա developer-ները commit են անում, Jenkins-ը վերցնում է code-ը Git-ից, build է անում, այնուհետև գործարկում test-երը։ Jenkins-ը տարբերում է, թե որն է test և որը՝ ոչ։ Եթե test-երը pass են կամ pass են որոշակի տոկոսով (թեստավորողը նշում է, թե քանի տոկոսով է pass), ապա deploy է անում environment-ի վրա։ Test-երի pass կամ fail լինելու մասին ուղարվում է հաղորդագրություն թեստավորողի կողմից նշված mail-երին։ <blockquote style="text-align: justify;">Օգտակար հղումներ` <a href="https://www.guru99.com/introduction-to-selenium.html" target="_blank">Selenium as an automation testing tool article/eng</a> <a href="https://www.guru99.com/locators-in-selenium-ide.html" target="_blank">Selenium locators article/eng</a> <a href="https://www.ibm.com/topics/docker" target="_blank">Docker article/eng</a> <a href="https://www.guru99.com/api-testing.html" target="_blank">API testing article/eng</a> <a href="https://www.guru99.com/jenkin-continuous-integration.html" target="_blank">Jenkins article/eng</a> <a href="https://www.youtube.com/watch?v=QtZ4yV49RtA" target="_blank">Automation testing video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=TH4qot56Uqg" target="_blank">Automation testing video tutorial/arm</a> <a href="https://www.youtube.com/watch?v=TNImFcYqb40" target="_blank">Automation testing video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=jK_4nnEJVHQ" target="_blank">Locators in Selenuim video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=9-iVt0MIqNY" target="_blank">Xpath in Selenium video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=89yWXXIOisk" target="_blank">Jenkins video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=wi-MGFhrad0&amp;list=PLhW3qG5bs-L99pQsZ74f-LC-tOEsBp2rK" target="_blank">Docker video tutorial/eng</a></blockquote>

Automated Testing-ը որպես թեստավորման մեթոդ։

Automated Testing

<h3>Manual Testing VS Automation Testing</h3> <table style="border-collapse:collapse;width: 100%;"><tbody>
<tr>
o<td style="width: 50%; text-align: center;">Manual Testing </td>
o<td style="width: 50%; text-align: center;">Automation Testing </td></tr>
<tr>
o<td style="width: 50%;">Թեստի իրականացման համար անհրաժեշտ է մարդու միջամտություն՝ բոլոր Test case-երը հատ-հատ ձեռքով ստուգվում են: </td>
o<td style="width: 50%;">Ստուգումն իրականացվում է ավտոմատ՝ օգտագործելով որոշակի tool-եր: </td></tr>
<tr>
o<td style="width: 50%;">Պահանջում է հմուտ աշխատուժ, շատ ժամանակ եւ ծախսեր: </td>
o<td style="width: 50%;">Խնայում է նշված ռեսուրսները: </td></tr>
<tr>
o<td style="width: 50%;">Ցանկացած տեսակի app-ի համար հնարավոր է Manual Testing, ad-hoc եւ monkey testing-ը հարմար է Manual-ով: </td>
o<td style="width: 50%;">Խորհուրդ է տրվում միայն կայուն համակարգերի համար եւ հիմնականում օգտագործվում է Regression Testing-ի համար: </td></tr>
<tr>
o<td style="width: 50%;">Կրկնվող է եւ ձանձրալի: </td>
o<td style="width: 50%;">Ունենում է նոր framwork-եր, կրկնվող ու ձանձրալի մասերն ավտոմատացված են: </td></tr></tbody></table> <blockquote>Օգտակար հղումներ՝ <a href="https://www.guru99.com/difference-automated-vs-manual-testing.html" target="_blank">Manual testing vs Automation testing article/eng</a> <a href="https://auriga.ru/" target="_blank">Manual testing vs Automation testing article/rus</a> <a href="https://www.youtube.com/watch?v=SEzPFlnI7mY" target="_blank">Manual testing vs Automation testing video tutorial/eng</a></blockquote>

Ինչո՞վ են տարբերվում թեստավորման այս երկու մեթոդները։

Manual Testing VS Automation Testing

<h3>Functional Testing</h3> Functional Testing-ի նպատակը software application–ի յուրաքանչյուր ֆունկցիայի ստուգումն է` ապահովելով համապատասխան մուտքը, ստուգել ելքը՝ կախված ֆունկցիոնալ պահանջներից: Ստուգվում է, յուրաքանչյուր բաղադրիչ(component) գործու՞մ է այնպես, ինչպես սպասվում էր, թե՞ ոչ: Հետեւաբար այն կոչվում է նաեւ «Component testing»: Թեստավորման այս տեսակը պարտադիր է անկախ նրանից, թե ինչ տեսակի application է: Functional Testing-ի ընթացքում օգտագործվում է Black Box Testing տեխնիկան, որում փորձարկվող համակարգի ներքին տրամաբանությունը հայտնի չէ: Ստուգում է User Interface-ը, API-երը, Database-ը, Security-ն, Client/Server հաղորդակցությունը եւ application-ի այլ ֆունկցիաներ: Այն կարելի է իրականացնել ինչպես manual, այնպես էլ automat: Ֆունկցիաները փորձարկվում են` փոխանցելով դրանց մուտքային տվյալներ եւ ուսումնասիրելով արդյունքը: Functional Testing-ը երաշխավորում է, որ application-ը պատշաճ կերպով բավարարում է պահանջները: Թեստավորման այս տեսակը կապված չէ այն բանի հետ, թե ինչպես է տեղի ունենում implementation-ը, այլ կապված է միայն արդյունքների հետ։ Ի՞նչ է ստուգում Functional Testing-ը 1.Application-ի հիմնական գործառույթները, նկարագրված ֆունկցիոնալը: Այլ կերպ ասած՝ ստուգվում է application-ի պահվածքը` համաձայն թեստի սպեցիֆիկացիաների:2.Error conditions – սխալ պայմանների դեպքում հաղորդագրությունների առկայությունը: Functional Testing-ի քայլերը 1.Հասկանալ գործառույթները, որոնք application-ը պետք է իրականացնի:2.Ստեղծել մուտքային տվյալներ` ելնելով ֆունկցիաների սպեցիֆիկացիաներից:3.Որոշել ակնկալվող ելքային արդյունքները ընտրված մուտքային արժեքների համար:4.Իրականացնել test case-երը:5.Իրական եւ ակնկալվող արդյունքների համեմատում: Functional testing-ի տեսակները 1.
Unit testing
2.
Integration testing
3.
Interface testing
4.
System testing
5.
Regression testing
6.
Smoke testing7. Sanity testing8. Acceptance testing Unit testing 1,Այս ֆունկցիոնալ փորձարկման տիպի դեպքում կոդերի ամենափոքր ֆունկցիոնալ և փորձարկվող միավորը փորձարկվում է unit testing-ի ժամանակ: 2. Հիմնականում իրականացվում է մշակողների կողմից, քանի որ դա White-Box թեստավորման տեխնիկա է: 3. Կատարվում է զարգացման ամենավաղ փուլերում, հետևաբար օգնում է բացահայտել թերությունները սկզբնական զարգացման փուլերում: Սա օգնում է խնայել STLC-ի հետագա փուլերում թերությունները շտկելու ավելի մեծ ծախսերը։ Integration testing 1. Ծրագրաշարի երկու կամ ավելի միավոր փորձարկված բաղադրիչները ինտեգրված են միասին և փորձարկվում են դրանց միջև փոխազդեցությունը հաստատելու համար, ինչպես և սպասվում էր: 2. Հրամանների, տվյալների, DB զանգերի, API զանգերի, միկրո ծառայությունների մշակման հաղորդակցությունը տեղի է ունենում բաժինների միջև և այս ինտեգրման ընթացքում անսպասելի վարքագիծ չի նկատվում: Interface testing 1.Integration testing-ի մի մասը; Ստուգվում է երկու ինտեգրված բաղադրիչների միջև տվյալների փոխանակման, տվյալների փոխանցման, հաղորդագրությունների, զանգերի և հրամանների ճշգրտությունը: 2. Տվյալների բազայի, վեբ-ծառայությունների, API-ների կամ որևէ արտաքին բաղադրիչի և հավելվածի միջև հաղորդակցությունը փորձարկվում է Interface testing-ի ընթացքում:3. Այս տվյալների կամ հրամանի հաղորդակցման ընթացքում չպետք է լինի որևէ սխալ կամ ձևաչափի անհամապատասխանություն: Եթե նման խնդիր է առաջանում, այն պետք է շտկվի: 4. Interface testing-ը տարբեր ինտերֆեյսների միջև կապի փորձարկումն է, մինչդեռ Integartion testing-ը մոդուլների ինտեգրված խմբի փորձարկումն է որպես մեկ միավոր։ System testing 1. Համակարգի բոլոր բաղադրիչները համակցված են, և համակարգը փորձարկվում է համապատասխանության և ճշտության համար՝ պահանջների բնութագրերին (ֆունկցիոնալ կամ համակարգային): 2. Դա Black-Box թեստավորման տեխնիկա է, որը վավերացնում է ինտեգրված համակարգը: 3. Այն իրականացվում է նախքան Acceptance testing-ի փորձարկումը (UAT) STLC-ում (Software testing-ի life cycle): 4. System testing-ը իրականացվում է գրեթե իրական միջավայրում և ըստ իրական կյանքի օգտագործման: Regression testing 1. Developer-ների կողմից որոշ բարելավումներից կամ կոդի շտկումից հետո շատ կարևոր է դառնում Regression testing-ի փաթեթը գործարկելը: Regression testing-ը իրականացվում է՝ համոզվելու համար, որ կոդի այս փոփոխությունները չեն խոչընդոտել առկա աշխատանքային գործառույթներին կամ որևէ նոր թերություն չի ներմուծվել կոդում: 2.Regression testing-ի դեպքերը գործող Ֆունկցիոնալ թեստերի ենթաբազմություն են, որոնք ընդգրկում են համակարգի հիմնական գործառույթները: 3. Regression դեպքերը պետք է թարմացվեն, ավելացվեն և ջնջվեն՝ համաձայն հավելվածի փոփոխությունների: 4. Regression testing case-երը ավտոմատացման թեստավորման լավագույն թեկնածուներն են, քանի որ դրանք հաճախ են գործարկվում և կատարման համար ժամանակ են պահանջում: Smoke testing 1. Developement-ից հետո, երբ թողարկվի նոր բիլդ, Smoke Testing-ը կատարվում է հավելվածի վրա՝ ապահովելու, որ բոլոր հիմնական գործառույթներն աշխատում են մինչև վերջ: 2. Smoke Testing-ը սովորաբար կատարվում է հավելվածի մշակման սկզբնական փուլում ստեղծված կառուցվածքների համար, որոնք դեռ կայուն չեն: 3. Փորձարկման ընթացքում, եթե որևէ հիմնական ֆունկցիոնալությունը չի աշխատում այնպես, ինչպես սպասվում էր, ապա այդ կոնկրետ կառուցումը մերժվում է: Developer-ները պետք է շտկեն bug-երը և ստեղծեն նոր կառուցվածք՝ հետագա փորձարկման համար: 4. Smoke testing-ի հաջող փորձարկումից հետո հավելվածը պատրաստ է փորձարկման հաջորդ մակարդակին: Sanity testing 1. Sanity testing-ը ընտրվում է Regression testing-ի փաթեթից՝ ընդգրկելով հավելվածի հիմնական գործառույթները: 2.Sanity Testing-ը կատարվում է ծրագրավորողների կողմից ստեղծված նոր կառուցվածքի վրա՝ համեմատաբար կայուն հավելվածի համար: 3. Երբ դիմումը հաջողությամբ անցնում է Sanity testing-ը, այն պատրաստ է թեստավորման հաջորդ մակարդակին: 4. Հեշտ է շփոթվել Smoke testing-ը և Sanity testing-ը: Նոր կառուցումից հետո նախնական հավելվածը փորձարկելու համար կատարվում է Smoke Testing: Բազմաթիվ թողարկումներից հետո, երբ այն կայունություն է ձեռք բերել, նույն հավելվածի վրա կատարվում է Sanity Testing: Acceptance testing 1. Acceptance testing-ի ընթացքում ստուգվում է վերջնական օգտագործողի կողմից հայտի ընդունումը: Այս թեստավորման նպատակն է համոզվել, որ մշակված համակարգը կատարում է բոլոր այն պահանջները, որոնք համաձայնեցվել են բիզնեսի պահանջների ստեղծման ժամանակ: 2. Այն իրականացվում է System testing-ից անմիջապես հետո և մինչև հավելվածի վերջնական թողարկումը: 3. Acceptance testing-ը օգտվողի համար դառնում է համակարգը կամ ընդունելու կամ մերժելու չափանիշ: 4. Դա Black-Box թեստավորման տեխնիկա է, քանի որ մենք միայն շահագրգռված ենք իմանալ հավելվածի աշխատունակությունը շուկայի և իրական օգտագործողների համար: <blockquote>Օգտակար հղումներ՝ <a href="https://www.guru99.com/functional-testing.html" target="_blank">Functional testing article/eng</a> <a href="https://www.applause.com/blog/functional-testing-types-examples" target="_blank">Functional testing types article/eng</a> <a href="https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/funktsionalnoe-testirovanie-2" target="_blank">Functional testing article/rus</a> <a href="https://www.youtube.com/watch?v=IGnZHgjU42Y" target="_blank">Functional testing video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=B1-1BqAr1f4" target="_blank">Functional testing video tutorial/rus</a></blockquote>

Functional Testing-ը որպես թեստավորման տեսակ։

Functional Testing

<h3>Non Functional Testing</h3> Non-Functional Testing-ը software application–ի ոչ ֆունկցիոնալ կողմերի ստուգումն է՝ կատարողականություն, օգտագործելիություն, հուսալիություն եւ այլն: Նպատակն է բարձրացնել product-ի օգտագործման հարմարավետությունը, արդյունավետությունը, պահպանելիությունը եւ մատչելիությունը, նվազեցնել product-ի ոչ ֆունկցիոնալ կողմերի հետ կապված ռիսկերը եւ ծախսերը: Ոչ ֆունկցիոնալ թեստավորումն իրականացվում է թեստային բոլոր մակարդակներում: Ոչ ֆունկցիոնալ թեստի լավ օրինակ կլինի ստուգել, թե քանի՞ մարդ կարող է միաժամանակ մուտք գործել համակարգ: Թեստավորման այս մակարդակը նույնպես շատ կարեւոր է client-ի համար, քանի որ դժվար թե մեկն ուզի ծրագիր, որը, օրինակ, դանդաղ է աշխատում։ Ծրագիրը գրելուց առաջ պահանջների մեջ պետք է ներառված լինեն որոշ ստանդարտներ եւ ծրագրավորման թիմը չպետք է դուրս գա այդ սահմաններից։ Usability Testing 1.Usability testing-ը տեխնիկա է, որն օգտագործվում է օգտատերերի վրա հիմնված փոխազդեցության նախագծման մեջ՝ ապրանքը գնահատելու համար՝ այն օգտագործողների վրա փորձարկելու միջոցով: 2.Սա կարող է դիտվել որպես անփոխարինելի Usability պրակտիկա, քանի որ այն ուղղակիորեն տալիս է տեղեկատվություն այն մասին, թե իրական օգտվողներն ինչպես են օգտագործում համակարգը: 3.Usability testing-ը ընդհանուր առմամբ ներառում է որոշել, թե որքան լավ են փորձարկվողները արձագանքում չորս ոլորտներում՝ արդյունավետություն, ճշգրտություն, հիշել և զգացմունքային: արձագանք Recovery testing Recovery testing-ը փորձարկում է, թե որքանով է հավելվածը կարողանում վերականգնել խափանումներից, ապարատային խափանումներից և նմանատիպ այլ խնդիրներից: Օրինակ։ Մինչ հավելվածը տվյալներ է ստանում ցանցից, անջատեք միացնող մալուխը: Որոշ ժամանակ անց նորից միացրեք մալուխը և վերլուծեք հավելվածի հնարավորությունը՝ շարունակելու տվյալներ ստանալ ցանցային կապի անհետացման կետից: Compatibility testing 1.Compability testing-ը, որը ծրագրային ապահովման ոչ ֆունկցիոնալ թեստերի մի մասն է, թեստավորում է, որն իրականացվում է հավելվածի վրա՝ գնահատելու հավելվածի համատեղելիությունը հաշվողական միջավայրի հետ: 2.Հաշվողական միջավայրը կարող է պարունակել տարբեր ՕՀ տեսակներ (IOS 6, IOS 7), տարբեր տեսակի բրաուզերներ (Chrome, Firefox, IE): Performance testing 1.Performance testing-ը ընդհանուր առմամբ իրականացվում է որոշելու համար, թե ինչպես է համակարգը կամ ենթահամակարգը գործում որոշակի ծանրաբեռնվածության ներքո արձագանքելու և կայունության առումով: 2.Այն կարող է նաև ծառայել՝ չափելու, վավերացնելու կամ ստուգելու համակարգի այլ որակական հատկանիշներ, ինչպիսիք են մասշտաբայնությունը, հուսալիությունը և ռեսուրսների օգտագործումը: Performance Testing Metrics Կատարման փորձարկման ընթացքում վերահսկվող հիմնական պարամետրերը ներառում են. 1.Պրոցեսորի օգտագործումը - պրոցեսորի ծախսած ժամանակի չափը, որը կատարում է ոչ պարապ թելերը: 2.Հիշողության օգտագործում - ֆիզիկական հիշողության քանակ, որը հասանելի է համակարգչում գործընթացներին: 3.Սկավառակի ժամանակ - այն ժամանակը, երբ սկավառակը զբաղված է կարդալու կամ գրելու հարցումը կատարելով: 4.Թողունակություն - ցույց է տալիս բիթերը վայրկյանում, որոնք օգտագործվում են ցանցային ինտերֆեյսի կողմից: 5.Մասնավոր բայթեր - գործընթացի հատկացված բայթերի քանակը, որոնք չեն կարող կիսվել այլ գործընթացների միջև: Դրանք օգտագործվում են հիշողության արտահոսքի և օգտագործման չափման համար: 6.Պարտավոր հիշողություն - օգտագործված վիրտուալ հիշողության քանակը: 7.Հիշողության էջեր/վայրկյան - սկավառակի վրա գրված կամ կարդացված էջերի քանակը՝ կոշտ էջի անսարքությունները լուծելու համար: Կոշտ էջի անսարքությունները տեղի են ունենում, երբ ընթացիկ աշխատանքային հավաքածուից չհանդիսացող կոդը կանչվում է այլ տեղից և վերցվում սկավառակից: 8.Page faults/second - ընդհանուր արագությունը, որով անսարք էջերը մշակվում են պրոցեսորի կողմից: Սա կրկին տեղի է ունենում, երբ գործընթացն իր աշխատանքային հավաքածուից դուրս կոդ է պահանջում: 9.CPU-ի ընդհատումները վայրկյանում - միջինն է: ապարատային ընդհատումների քանակը, որոնք պրոցեսորը ստանում և մշակում է յուրաքանչյուր վայրկյան: 10.Սկավառակի հերթի երկարությունը - միջինն է: ոչ ընթերցման և գրելու հարցումները, որոնք հերթագրված են ընտրված սկավառակի համար նմուշի ընդմիջման ընթացքում: 11.Ցանցի ելքային հերթի երկարությունը - փաթեթների մեջ ելքային փաթեթների հերթի երկարությունը: Երկուսից ավելի ցանկացած բան նշանակում է հետաձգում և խցանումներ, որոնք պետք է դադարեցվեն: 12.Ցանցի բայթերի ընդհանուր թիվը մեկ վայրկյանում - բայթերի ուղարկման և ստացման արագություն ինտերֆեյսի վրա, ներառյալ շրջանակային նիշերը: 13.Արձագանքման ժամանակ - ժամանակ, երբ օգտատերը դիմում է մուտքագրում մինչև պատասխանի առաջին նիշը ստանալը: 14.Արտադրողականություն - գնահատեք համակարգիչը կամ ցանցը, որոնք ստանում են հարցումներ վայրկյանում: 15.Կապի միավորման գումարը - օգտվողների հարցումների քանակը, որոնք բավարարվում են միավորված կապերով: Որքան շատ պահանջներ կատարվեն լողավազանում միացումների կողմից, այնքան ավելի լավ կլինի կատարումը: 16.Առավելագույն ակտիվ նստաշրջաններ - նիստերի առավելագույն քանակը, որոնք կարող են ակտիվ լինել միանգամից: 17.Հիթերի գործակիցներ – Սա կապված է SQL հայտարարությունների քանակի հետ, որոնք մշակվում են քեշավորված տվյալների միջոցով՝ թանկարժեք I/O գործառնությունների փոխարեն: Սա լավ տեղ է սկսելու համար խցանման խնդիրները լուծելու համար: 18.Հարվածներ վայրկյանում - ոչ: վեբ սերվերի վրա բեռնվածության փորձարկման յուրաքանչյուր վայրկյանի ընթացքում դիտումների քանակը: 19.Հետադարձ հատված - տվյալների քանակությունը, որը կարող է հետ վերադարձվել ժամանակի ցանկացած պահի: 20.Տվյալների բազայի կողպեքներ - աղյուսակների և տվյալների բազաների արգելափակումը պետք է վերահսկվի և ուշադիր կարգավորվի: 21.Վերևի սպասումներ. վերահսկվում են՝ որոշելու համար, թե սպասման ժամանակները կարող են կրճատվել հիշողությունից տվյալների արագ վերբերման հետ կապված: 22.Թեմաների քանակը - Հավելվածի առողջությունը կարելի է չափել ոչ-ով: այն թեմաները, որոնք աշխատում են և ներկայումս ակտիվ են: 23.Աղբահանություն - Դա կապված է չօգտագործված հիշողությունը համակարգ վերադարձնելու հետ: Աղբահանության արդյունավետության համար անհրաժեշտ է վերահսկել Performance Testing-ի տեսակները 1.Load testing- ստուգում է հավելվածի կարողությունը գործելու օգտատերերի սպասվող բեռների ներքո: Նպատակն է բացահայտել կատարողականի խոչընդոտները՝ նախքան ծրագրային ապահովման հավելվածի գործարկումը: 2.Stress testing – ներառում է հավելվածի փորձարկում ծայրահեղ ծանրաբեռնվածության ներքո՝ տեսնելու, թե ինչպես է այն կառավարում մեծ թրաֆիկի կամ տվյալների մշակումը: Նպատակը հայտի բեկման կետը բացահայտելն է: 3.Volume testing - Ծավալի փորձարկման տակ մեծ թիվ. -ից Տվյալները համալրվում են տվյալների բազայում և վերահսկվում է ընդհանուր ծրագրային համակարգի վարքագիծը: Նպատակն է ստուգել ծրագրային հավելվածի կատարումը տվյալների բազայի տարբեր ծավալների ներքո: 4.Scalability testing - scalability testing-ի նպատակն է որոշել ծրագրային ապահովման հավելվածի արդյունավետությունը «մեծացնելու» հարցում՝ աջակցելու օգտվողների բեռի ավելացմանը: Այն օգնում է պլանավորել ձեր ծրագրային համակարգի կարողությունների ավելացումը: 5.Endurance testing - արվում է համոզվելու համար, որ ծրագրաշարը կարող է երկար ժամանակ հաղթահարել սպասվող բեռը: &nbsp; Security testing Security testing-ը գործընթաց է՝ որոշելու, որ տեղեկատվական համակարգը պաշտպանում է տվյալները և պահպանում է ֆունկցիոնալությունը, ինչպես նախատեսված է: Security վեց հիմնական հասկացությունները, որոնք պետք է ծածկվեն Security testing-ով, հետևյալն են. 1onfidentiality 2.Integrity 3.Authentication4.Availability 5.Authorizationnon-repudiation. 6.Availability Testing Internationalization and Localisation Testing Internationalization-ը և Localization-ը համակարգչային հավելվածները տարբեր լեզուներին, տարածաշրջանային տարբերություններին և թիրախային շուկայի տեխնիկական պահանջներին հարմարեցնելու միջոցներ են: 1.Internalization-ը ծրագրային հավելվածի նախագծման գործընթաց է, որպեսզի այն հարմարեցվի տարբեր լեզուների և տարածաշրջանների՝ առանց ինժեներական փոփոխությունների: 2.Localization-ը միջազգայնացված ծրագրաշարի հարմարեցման գործընթաց է որոշակի տարածաշրջանի կամ լեզվի համար՝ ավելացնելով տեղային հատուկ բաղադրիչներ և թարգմանելով տեքստ: <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/non-functional-testing.html" target="_blank">Non-functionl testing article/eng</a> <a href="https://diffy.website/blog/functional-vs-non-functional-testing" target="_blank">Functional testing vs Non-functional testing article/eng</a> <a href="https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/ne-funktsionalnoe-testirovanie" target="_blank">Non-functional testing article/rus</a> <a href="https://www.youtube.com/watch?v=j_79AXkG4PY" target="_blank">Functional testing vs Non-functional testing video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=0BszE2j8Zug" target="_blank">Functional testing vs Non-functional testing video tutorial/rus</a></blockquote>

Non Functional Testing-ը որպես թեստավորման տեսակ

Non Functional Testing

<h3>Maintenance Testing</h3> Maintenance Testing-ն իրականացվում է արդեն տեղակայված ծրագրաշարի վրա: Տեղակայված ծրագրակազմը պետք է կատարելագործվի, փոխվի կամ տեղափոխվի այլ սարքավորում: Այս կատարելագործման, փոփոխման և միգրացիայի ցիկլի ընթացքում կատարված փորձարկումները հայտնի են որպես տեխնիկական սպասարկում: <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.softwaretestingmaterial.com/maintenance-testing/" target="_blank">Maintenance testing article/eng</a> <a href="https://www.youtube.com/watch?v=7B69Z35BvD4" target="_blank">Maintenance testing video tutorial/eng</a></blockquote>

Maintenance Testing-ը որպես թեստավորման տեսակ։

Maintenance Testing

<h3>Defect, Bug , Error, Failure</h3> Ստացված արդյունքի եւ սպասվածի միջեւ տարբերությունը, որը գտնում է developer-ը կոչվում է Defect: Տարբերությունը, որը գտնում է tester-ը, կոչվում է Bug: Սխալը,որի պատճառով կոդը compile կամ run չի լինում, կոչվում է Error: Սխալը, որը չի գտել ոչ developer-ը, ոչ էլ tester-ը, այլ այն հայտնաբերվել է user-ի կողմից, կոչվում է Failure: <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.360logica.com/blog/difference-between-defect-error-bug-failure-and-fault/" target="_blank">Difference between Defect, Error,Bug, and Failure article/eng</a> <a href="https://www.youtube.com/watch?v=53braDId-RQ" target="_blank">Defect, Error,Bug, and Failure video tutorial/eng</a></blockquote>

Ո՞րն է այս տերմինների հիմնական տարբերությունը։

Defect, Bug, Error, Failure

<h3>Bug Life Cycle</h3> Bug Life Cycle-ը Bug-ի կարգավիճակների հատուկ հաջորդականություն է, որն անցնում է Bug-ը իր գոյության ընթացքում: Bug Life Cycle-ի նպատակը դեֆեկտի ընթացիկ ստատուսը հեշտ համակարգելն ու հաղորդելն է: Ստատուսը դեֆեկտի ընթացիկ կարգավիճակն է: Ստատուսի նպատակը դեֆեկտի ընթացիկ վիճակը կամ առաջընթացը ճշգրիտ փոխանցելն է՝ առաջընթացին ավելի լավ հետեւելու եւ հասկանալու համար: Դեֆեկտի ստատուսների թիվը պրոյեկտից պրոյեկտ փոխվում է: Ներքեւում բերված դիագրամը նկարագրում է դեֆեկտի բոլոր հնարավոր կարգավիճակները: 1.New :Երբ tester-ը գտնում է սխալ, ասում ենք, որ բացվել է bug , որի status = new: 2.Assign:Bug-ը հայտնաբերված է, team lead-ը պետք է հաստատի Bug-ը ուղարկի development team-ին ուղղելու համար՝ status=assign, սակայն մինչեւ ուղարկելը պետք է որոշի Bug-ի առաջնահերթության աստիճանը(priority): 3.Open:Developer-ը սկսում է վերլուծել եւ աշխատել Bug-ն ուղղելու վրա: Սա իր հերթին&nbsp;կարող է լինել Duplicate, այսինքն` tester-ը լավ չի նայել արդեն բացված bug-երը եւ իր բացած bug-ը համընկնում է արդեն հայտնաբերված մեկ այլ bug-ի հետ, այս դեպքում bug-ը փակվում է՝ Closed: Այն դեպքում, երբ PM-ը վերլուծում է bug-ը եւ ասում, որ դա&nbsp;իրականում bug չի ՝ status = Rejected =&gt; Closed: Իսկ եթե bug-ն ուղղելու համար չկան համապատասխան ռեսուրսներ, կամ տվյալ bug-ի առաջնահերթությունը ցածր է, ապա&nbsp;status=Deffered եւ bug-ը հետաձգվում է մինչեւ հաջորդ Release-ը ` status= Next Release: Developer-ն, ով աշխատում է bug-ի վրա ստատուսը դնում է in_progress: 4.Pending retest:Երբ defect-ը շտկվում է, մշակողը տալիս է հատուկ կոդ՝ ծածկագիրը վերստուգելու համար փորձարկողին: 5.Retest:այս փուլում փորձարկողն իրականացնում է կոդի վերստուգում՝ ստուգելու՝ արդյոք թերությունը շտկված է մշակողի կողմից, թե ոչ, և կարգավիճակը փոխում է «re-test»։ 6.Checked:Թեստավորողը նորից փորձարկում է bug-ը developer-ի կողմից այն շտկելուց հետո։ Եթե software-ի մեջ սխալ չի հայտնաբերվել, ապա bug-ը շտկվում է, և նշանակված կարգավիճակը «verified»: 7.Reopen:Եթե bug-ը պահպանվում է նույնիսկ այն բանից հետո, երբ developer-ը շտկել է bug-ը, թեստավորողը փոխում է կարգավիճակը «reopened»: Կրկին bug-ը անցնում է life cycle: 8.Closed:Եթե bug-ը այլևս գոյություն չունի, փորձարկողը վերագրում է «closed» կարգավիճակը: 9.Dublicate:Եթե defect-ը կրկնվում է երկու անգամ կամ համապատասխանում է bug-ի նույն հասկացությանը, կարգավիճակը փոխվում է «dublicate»: 10.Reject:Եթե developer-ը զգում է, որ defect-ը իրական defect չէ, ապա այն փոխվում է «rejected»: 11.Deffered:Եթե ներկա bug-ը առաջնահերթություն չէ, և եթե ակնկալվում է, որ այն կշտկվի հաջորդ անգամ, ապա փոխվում է «Deffered»։ 12.Not a bug:Եթե դա չի ազդում հավելվածի ֆունկցիոնալության վրա, ապա bug-ին վերագրված կարգավիճակը «not a bug»: <img src="https://lh4.googleusercontent.com/UgOiYKxjOhr-1mg_t-JlCdb03bEqfEBHV9TlE-_HdfQa65MPMaZihbuoBMaLRB9x7Vk3_f3TZSOPLmdSSNNnAqVOjaCsXuX9f98NL4yzIxR0jxBJ7ToYhDFZ0IYgRn-CHUEGRN8MlXTMmOExyeH1-1g" width="624" height="464" style="margin-left:0px;margin-top:0px;">1.Թեստավորողը գտնում է defect-ը 2.Status-ը տրված է defect- New 3.Defect-ը փոխանցվում է Ծրագրի ղեկավարին վերլուծության համար 4.Ծրագրի ղեկավարը որոշում է, թե արդյոք թերությունը վավեր է 5.Այստեղ թերությունը վավեր չէ. կարգավիճակը տրվում է «Մերժված է»: 6.Այսպիսով, ծրագրի ղեկավարը նշանակում է rejected status: Եթե defect-ը չի մերժվում, ապա հաջորդ քայլը ստուգելն է, թե արդյոք այն իր շրջանակում է: Ենթադրենք, մենք ունենք մեկ այլ գործառույթ՝ էլփոստի 7.գործառույթ նույն հավելվածի համար, և դուք դրա հետ կապված խնդիր եք գտնում: Բայց դա ընթացիկ թողարկման մաս չէ, երբ այդպիսի թերություններ կան 8.նշանակվել է որպես հետաձգված կամ հետաձգված կարգավիճակ: 9.Հաջորդը, մենեջերը ստուգում է, թե արդյոք նախկինում նման թերություն է առաջացել: Եթե այո, թերությունը նշանակվում է կարգավիճակի կրկնօրինակ: 10.Եթե ոչ, թերությունը վերագրված է developer-ին, ով սկսում է շտկել կոդը: Այս փուլում թերությանը վերագրվում է ընթացքի կարգավիճակ: 11.Երբ կոդը ամրագրվի: Թերությանը վերագրվում է ֆիքսված կարգավիճակ 12.Հաջորդը, փորձարկողը նորից կփորձարկի կոդը: Փորձարկման գործն անցնելու դեպքում թերությունը փակվում է: Եթե փորձարկման դեպքերը կրկին ձախողվեն, ապա թերությունը կրկին բացվում է և վերագրվում է մշակողին: 13.Դիտարկենք մի իրավիճակ, երբ Թռիչքի ամրագրման 1-ին թողարկման ժամանակ ֆաքսի պատվերում թերություն է հայտնաբերվել, որը շտկվել է և նշանակվել է փակված կարգավիճակ: Երկրորդ 14.արդիականացման ժամանակ նույն թերությունը նորից հայտնվեց: Նման դեպքերում փակ թերությունը նորից կբացվի։ <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/defect-life-cycle.html" target="_blank">Defect/Bug life cycle article/eng</a> <a href="https://www.youtube.com/watch?v=EZGDyFPHFMw" target="_blank">Bug life cycle video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=ndwA0ywELvg" target="_blank">Bug life cycle video tutorial/rus</a></blockquote>

Ինչպե՞ս է բնութագրվում Bug Life Cycle-ը։

Bug Life Cycle

<h3>Defect Severity and Priority</h3> Severity-ն թեստավորման ենթակա app-ի ֆունկցիոնալության վրա bug-ի ազդեցության աստիճանն է: Tester-ը հիմնվելով test case-ի եւ requirement-ների իմացության վրա, որոշում է Severity-ի տիպը: Priority-ն սահմանվում է որպես կարգ, ըստ որի պետք է bug-ը ֆիքսվի: Bug-ը, որը software system-ը դարձնում է անօգտագործելի, ունի ավելի բարձր առաջնահերթություն, քան նրանք, որոնց դեպքում software-ի ձախողվելու հավանականությունը փոքր է: Որքան բարձր է Priority-ն, այնքան ավելի շուտ է ֆիքսվում Bug-ը: Որոշում է manager-ը կամ client-ը: Severity Levels Blocker– Այս Bug-ը առաջացնում է app-ի ամբողջական խափանում, եւ tester-ը չի կարողանում այլեւս առաջ գնալ : Միշտ ունի high priority: Critical – Մասամբ խափանում է app-ի աշխատանքը: Այսինքն user-ը դեռ կարողանում է որոշ ֆունկցիաներից օգտվել կամ նույն սցենարը հնարավոր է այլ կերպ իրականացնել: Միշտ ունի high priority: Major- Այս դեպքում համակարգը չի խափանվում, բայց առաջանում է որոշակի անցանկալի վարքագիծ: Այս bug-երը հավասարապես կարեւոր են եւ պետք է ուղղվեն առանց հետաձգելու: Minor &amp; Trivial– Նշանակալի վնաս չեն պատճառում համակարգին: Կարող են լինել UI փոքր խնդիրներ, ուղղագրական սխալներ, հավասարեցման, գույների հետ կապված խնդիրներ, որոնք ֆունկցիոնալության վրա ոչ մի ազդեցություն չունեն: Priority Levels High (P1) - Սխալը պետք է ուղղվի հնարավորինս շուտ, քանի որ համակարգը չի կարող օգտագործվել մինչեւ ուղղվելը: Medium (P2) – P1 Priority ունեցող դեֆեկտներից հետո, պետք է ուղղվեն P2-ները: Նման խնդիրները չեն խանգարում հետագա թեստավորմանը: Low (P3) – Կուղղվի միայն առավել լուրջ սխալներ ուղղելուց հետո: Severity-ին որոշելու տարբերակներ Որոշել bug-ի հաճախականությունը. Որոշ դեպքերում այն փոքր խնդիրները, որոնք հաճախ են կրկնվում, ավելի լուրջ կարող են լինել: bug-ի առանձնացում. bug-ն առանձնացնելը կարող է օգնել դրա ազդեցությունը պարզելու հարցում: Օրինակներ Scenarion 1: High priority and blocker severity 1.Շատ տարածված օրինակ՝ Օգտվողը չի կարողանում մուտք գործել հավելված՝ համապատասխան հավատարմագրերով: Սա շատ կարևոր սցենար է, որը պետք է հնարավորինս արագ շտկվի։ 2.Էլեկտրոնային առևտրի կայքէջում օգտատերը չի կարող ապրանքը ավելացնել զամբյուղի մեջ / չի կարող դուրս գալ զամբյուղից վճարման համար: Եթե տեղի է ունեցել իրական հավելվածում, այս խնդիրը կարող է մեծ մակարդակով ազդել բիզնեսի վրա: 3.Գրանցվելուց հետո օգտվողը չի ստանում հղումը գրանցման գործընթացը ավարտելու համար: 4.Համակարգը խափանում է, երբ որոնման վանդակում տրամադրվում են անվավեր հիմնաբառեր (օրինակ՝ XSS սկրիպտներ): Scenario 2: Low priority and low severity 1.Ուղղագրական փոքր սխալներ այնպիսի էջերում, ինչպիսիք են «Կայքի քարտեզ», «Կարիերա» կամ «Ընկերության բլոգ» էջերը: 2.«Մեր մասին» էջի կոճակի գույնը մի փոքր այլ է: 3.Ընկերության բլոգների էջի բովանդակության հետ հավասարեցման աննշան խնդիրներ: Scenario 3: High priority and low severity 1.Շատ տարածված օրինակ՝ «Ընկերության լոգոն» չի ցուցադրվում այնպես, ինչպես սպասվում էր: Այս թերությունը չի ազդում որևէ ֆունկցիոնալ սցենարի վրա, բայց կարող է ազդել ընկերության ապրանքանիշի արժեքի վրա: Այնպես որ, այս խնդիրը պետք է լուծվի առանց ուշացման։ <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/defect-severity-in-software-testing.html" target="_blank">Defect severity and priority article/eng</a> <a href="https://www.performance-lab.ru/blog/sereznost" target="_blank">Defect severity and priority article/rus</a> <a href="https://www.youtube.com/watch?v=HW_tnUnUav8" target="_blank">Defect severity and priority video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=ZyiV9fmUzjk" target="_blank">Defect severity and priority video tutorial/rus</a></blockquote>

Ինչպե՞ս որոշել Bug-ի Severity-ն և Priority-ն։

Defect Severity and Priority

<h3>Defect Report</h3> փաստաթուղթ է, որը նույնականացնում և նկարագրում է փորձարկողի կողմից հայտնաբերված թերությունը: Անբավարարության մասին զեկույցի նպատակն է հնարավորինս հստակ նշել խնդիրը, որպեսզի developer-ները կարողանան հեշտությամբ գտնեն թերությունը և շտկեն այն: Defect Report Template Ընկերությունների մեծ մասում օգտագործվում է defect reporting գործիք, և հաշվետվության տարրերը կարող են տարբեր լինել: Այնուամենայնիվ, ընդհանուր առմամբ, defect reporting-ը կարող է բաղկացած լինել հետևյալ տարրերից. Bugի մասին developer-ին զեկուցելիս ձեր defect report-ը պետք է պարունակի հետևյալ տեղեկատվությունը` 1.ID - Ունիկալ համար յուրաքանչյուր bug-ի համար 2.Project – Project-ի անունը, որի վրա հայտնաբերվել է bug-ը: 3.Product – Product-ի անունը 4.Realease Version - Product-ի Realease Version-ի համարը, օր. 1, 2 , 3 .... 5.Module – Նշվում է մոդուլը, որտեղ հայտնաբերվել է bug-ը: 6.Detected Build Version - Build Version-ը, որի ընթացքում հայտնաբերվել է bug-ը: 7.Summary - bug-ի ամփոփումն է, գրվում է, թե ինչ է իրենից ներկայացնում bug-ը, սա առաջին ինֆորմացիան է, որը կարդում է Report-ը նայողը: 8.Description - Bug-ի որքան հնարավոր է մանրամասն նկարագրությունն է, բայց առանց ինչ-որ բան կրկնելու կամ բարդ բառեր օգտագործելու: Այն պետք է լինի պարզ, բայց սպառիչ: 9.Steps to Replicate – Քայլ առ քայլ նկարագրվում են այն գործողություններ, որոնց արդյունքում հայտնաբերվել է bug-ը: Պետք է գրվի շատ մանրամասն եւ քայլերը համարակալելով: 10.Actual Result – Իրականում ստացված արդյունքը: 11.Expected Results – Սպասված արդյունքը: 12.Attachments – Կցվում է ցանկացած լրացուցիչ տեղեկատվություն,օրինակ screenshot 13.Remarks – Լրացուցիչ comment-ներ կապված bug-ի հետ: 14.Defect Probability 15.Defect Severity 16.Defect Priority 17.Reported by – Մարդու անունը, ով զեկուցում է bug-ը: 18.Assigned to – Մարդու անունը, ով պետք է վերլուծի կամ ուղղի bug-ը: 19.Status 20.Fixed build Version – Նշվում է build Version-ը, որի ընթացքում ուղղվել է bug-ը: Արդյունավետ Defect Report գրելու ուղեցույց՝ 1.Այն պետք է լինի կոնկրետ եւ հստակ։ 2.Մանարամասն։ 3.Այն պետք է գրել՝ օբյեկտիվորեն, հենվելով փաստերի վրա խուսափելով , զգացմունքներից: 4.Նախքան bug բացելը, պետք է վստահ լինել, որ այն bug է: 5.Ավարտելուց հետո այն պետք է անպայման վերանայել: 6.Bug գտնելու քայլերը պետք է հնարավորինս մինիմիզացնել: <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://bugherd.com/blog/bug-reporting/" target="_blank">Bug report article/eng</a> <a href="https://www.youtube.com/watch?v=Axm-F0pH8cg" target="_blank">Bug report video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=dns4zBqfpEM" target="_blank">Bug report video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=g8FJ_Zja9P0" target="_blank">Bug, Bug report video tutorial/arm</a></blockquote>

Ինչպե՞ս կազմել գրագետ Defect Report։

Defect Report

<h3>Test Case</h3> TEST CASE-ը պայմանների կամ փոփոխականների մի շարք է, որոնց ներքո փորձարկողը կորոշի, թե արդյոք փորձարկվող համակարգը բավարարում է պահանջներին կամ ճիշտ է աշխատում: Թեստային դեպքերի մշակման գործընթացը կարող է նաև օգնել գտնել խնդիրներ հավելվածի պահանջների կամ նախագծման մեջ: <table style="border-collapse:collapse;width: 100%;"><tbody>
<tr>
o<td style="width: 22.1245%; text-align: center;">Test Case դաշտ</td>
o<td style="width: 77.8078%; text-align: center;">Նկարագրություն</td></tr>
<tr>
o<td style="text-align: left;">Test Case ID </td>
o<td style="text-align: left;">Յուրաքանչյուր test case պետք է ներկայացվի եզակի ID-ով: Թեստի տեսակները նշելու համար հետևեք որոշ կոնվենցիայի, օրինակ՝ «TC_UI_1», որը ցույց է տալիս&nbsp;"User Interface Test Case#1."։</td></tr>
<tr>
o<td style="text-align: left;">Name of the Modul</td>
o<td style="text-align: left;">Այն օգտակար է թեստն իրականացնելիս Ցածր Միջին Բարձր </td></tr>
<tr>
o<td style="text-align: left;">Test designed by</td>
o<td style="text-align: left;">Որոշեք փորձարկվող հիմնական մոդուլի կամ ենթամոդուլի անվանումը </td></tr>
<tr>
o<td style="text-align: left;">Date of test designed</td>
o<td style="text-align: left;">Թեստի նախագծման ամսաթիվը </td></tr><tr><td style="text-align: left;">Test executed by</td>
o<td style="text-align: left;">Ով է փորձարկել թեստը- թեստավորողը</td></tr><tr><td style="text-align: left;">Date of the test execution</td>
o<td style="text-align: left;">Ամսաթիվը, երբ պետք է կատարվի թեստը </td></tr><tr><td style="text-align: left;">Name or Test Title</td>
o<td style="text-align: left;">Test case-ի&nbsp; անվաումը</td></tr><tr><td style="text-align: left;">Description/Sum mary of Test</td>
o<td style="text-align: left;">Հակիրճ ամփոփեք թեստի նպաատակը</td></tr><tr>
o<td style="text-align: left;">Pre-condition</td>
o<td style="text-align: left;">Ցանկացած պահանջ, որը պետք է կատարվի նախքան այս test case-ի կատարումը: Այս test case-ն իրականացնելու համար նշեք բոլոր նախապայմանները </td></tr><tr>
o<td style="text-align: left;">Dependencies</td>
o<td style="text-align: left;">Որոշեք ցանկացած կախվածություն թեստի պահանջներից կամ փորձարկման այլ դեպքերից </td></tr><tr>
o<td style="text-align: left;">Test Steps</td>
o<td style="text-align: left;">Մանրամասն նշեք թեստի բոլոր քայլերը և գրեք այն հերթականությամբ, որով այն պետք է կատարվի: Թեստի քայլերը գրելիս հնարավորինս շատ մանրամասնեք </td></tr><tr>
o<td style="text-align: left;">Test Data</td>
o<td style="text-align: left;">Test data-ի օգտագործումը որպես մուտքագրում թեստային գործի համար: Տրամադրել տարբեր dataset-եր ճշգրիտ արժեքներով, որոնք կօգտագործվեն որպես մուտքագրում </td></tr><tr>
o<td style="text-align: left;">Expected Results</td>
o<td style="text-align: left;">Նշեք ակնկալվող արդյունքը, ներառյալ սխալը կամ հաղորդագրությունը, որը պետք է հայտնվի էկրանին </td></tr><tr>
o<td style="text-align: left;">Post-Condition</td>
o<td style="text-align: left;">Ինչպիսի՞ն կլինի համակարգի վիճակը թեստը գործարկելուց հետո: </td></tr><tr>
o<td style="text-align: left;">Actual Result</td>
o<td style="text-align: left;">Թեստավորումից հետո պետք է լրացվի փորձարկման փաստացի արդյունքը </td></tr><tr>
o<td style="text-align: left;">Status(Fail/Pass)</td>
o<td style="text-align: left;">Նշեք այս դաշտը որպես ձախողված, եթե իրական արդյունքը չի համապատասխանում գնահատված արդյունքին </td></tr><tr>
o<td style="text-align: left;">Notes</td>
o<td style="text-align: left;">Եթե կան որոշ հատուկ պայմաններ, որոնք մնացել են վերը նշված դաշտում </td></tr></tbody></table> Test Case VS Test Scenario 1.Test Case-ը գործողությունների մի շարք է, որոնք կատարվում են որոշակի հատկանիշներ կամ ֆունկցիոնալությունը ստուգելու համար, մինչդեռ Test Scenario-ն ցանկացած գործառույթ է, որը կարող է փորձարկվել: 2.Test Case-ը հիմնականում բխում է փորձարկման սցենարներից, մինչդեռ Test Scenario-ն բխում են փորձնական արտեֆակտներից, ինչպիսիք են BRS-ը և SRS-ը: 3.Test Case-ն օգնում է հավելվածի սպառիչ փորձարկմանը, մինչդեռ Test Scenario-ն օգնում է արագաշարժ եղանակով փորձարկել վերջից մինչև վերջ ֆունկցիոնալությունը: 4.Test Case-երը կենտրոնացած են այն բանի վրա, թե ինչ պետք է փորձարկել և ինչպես փորձարկել, մինչդեռ Test Scenario-ն ավելի կենտրոնացած է այն բանի վրա, թե ինչ պետք է փորձարկել: 5.Test Case-երը ցածր մակարդակի գործողություններ են, մինչդեռ Test Scenario-ները բարձր մակարդակի գործողություններ են: 6.Test Case-ը պահանջում է ավելի շատ ռեսուրսներ և ժամանակ թեստի կատարման համար, մինչդեռ Test Scenario-ն պահանջում է ավելի քիչ ռեսուրսներ և ժամանակ թեստի կատարման համար: 7.Test Case-ը ներառում է թեստային քայլեր, տվյալներ, թեստավորման համար ակնկալվող արդյունքներ, մինչդեռ Test Scenario-ն ներառում է փորձարկվող վերջից մինչև վերջ ֆունկցիոնալությունը: Ահա թեստային սցենարի և փորձարկման դեպքի միջև զգալի տարբերություններ: <table style="border-collapse:collapse;width: 100%;"><tbody>
<tr>
o<td style="width: 50%; text-align: center;">Test Scenario</td>
o<td style="width: 50%; text-align: center;">Test Case</td></tr>
<tr>
o<td style="width: 50%;">Test Scenario-ն պարունակում է բարձր մակարդակի փաստաթղթեր, որոնք նկարագրում են փորձարկվող վերջնական ֆունկցիոնալությունը: </td>
o<td style="width: 50%;">Test Case-երը պարունակում են որոշակի թեստային քայլեր, տվյալներ, ակնկալվող արդյունքներ՝ հավելվածի բոլոր հատկանիշները փորձարկելու համար: </td></tr>
<tr>
o<td style="width: 50%;">Այն կենտրոնանում է ավելի շատ «ինչ փորձարկել», քան «ինչպես փորձարկել»: </td>
o<td style="width: 50%;">Ամբողջական շեշտադրում «ինչ փորձարկել» և «ինչպես փորձարկել»: </td></tr>
<tr>
o<td style="width: 50%;">Test Scenario-ները միակողմանի են: Այսպիսով, թեստավորման ընթացքում միշտ կա երկիմաստության հավանականություն։ </td>
o<td style="width: 50%;">Test Case-երը սահմանել են քայլ, նախադրյալներ, ակնկալվող արդյունք և այլն։ Հետևաբար, այս գործընթացում երկիմաստություն չկա։ </td></tr>
<tr>
o<td style="width: 50%;">Փորձարկման սցենարները բխում են փորձնական արտեֆակտներից, ինչպիսիք են BRS, SRS և այլն: </td>
o<td style="width: 50%;">Test Case-ը հիմնականում բխում է Test Scenario-ներից: Բազմակի Test Case-ը կարող է բխվել մեկ Test Scenario-ից: </td></tr>
<tr>
o<td style="width: 50%;">Այն օգնում է արագաշարժ կերպով ստուգել ծայրից ծայր ֆունկցիոնալությունը: </td>
o<td style="width: 50%;">Այն օգնում է հավելվածի սպառիչ փորձարկմանը։ </td></tr>
<tr>
o<td style="width: 50%;">Test Scenario-ները բարձր մակարդակի գործողություններ են: </td>
o<td style="width: 50%;">Test Case-երը ցածր մակարդակի գործողություններ են: </td></tr>
<tr>
o<td style="width: 50%;">Համեմատաբար ավելի քիչ ժամանակ և ռեսուրսներ են պահանջվում սցենարներ ստեղծելու և փորձարկելու համար: </td>
o<td style="width: 50%;">Ավելի շատ ռեսուրսներ են անհրաժեշտ Test Case-ի փաստաթղթավորման և կատարման համար: </td></tr></tbody></table> <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/test-case.html" target="_blank">Test case article/eng</a> <a href="https://www.parasoft.com/blog/how-to-write-test-cases-for-software-examples-tutorial/" target="_blank">Test case article/eng</a> <a href="https://www.youtube.com/watch?v=e0cHqx5cRPo" target="_blank">Test case video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=g0PrXoWKM2Y" target="_blank">Test case video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=Hq7dt5zVxL0" target="_blank">Test case, Test plan video tutorial/arm</a></blockquote>

Test Case

<h3>Test Script</h3> Test Script-ը instruction-ների ամբողջություն է՝ գրված կոդավորման լեզվով (JavaScript, Perl, Python, Ruby, Tcl, Unix Shell Script, VBScript), որն իրականացվում է թեստավորվող system-ի վրա՝ ստուգելու համար, այն աշխատու՞մ է ակնկալվածի պես, թե՞ ոչ: Այն օգտագործվում է ավտոմատացված թեստավորման ժամանակ: <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/test-script.html" target="_blank">Test script article/eng</a> <a href="https://www.youtube.com/watch?v=txQZm6l4MbM" target="_blank">Test script video tutorial/eng</a></blockquote>

Test Script

<h3>Test Plan</h3> Test Plan-ը փաստաթուղթ է, որը մանրամասն նկարագրում է software testing-ի շրջանակը եւ գործունեությունը, ռազմավարությունը, նպատակները, ժամանակացույցը, գնահատումը, ռեսուրսները, որոնք անհրաժեշտ են պրոդուկտի փորձարկումն իրականացնելու համար: Այն օգնում է գնահատել պրոդուկտի որակի validation-ի համար անհրաժեշտ ջանքերը: Այն վերահսկվում է test manager-ի կողմից: <h3 style="text-align: justify;">Test Plan Template</h3> Test Plan Identifier Պետք է ապահովել ունիկալ Identifier: Այն կարող է ներառել version-ի վերաբերյալինֆորմացիա, Test Plan-ի տեսակի մասին ինֆորմացիա:Օրինակ՝ ‘Master Test plan for Workshop Module TP_1.0’ : Introduction (Ներածություն) Test Plan-ի ամփոփում Նպատակները / խնդիրները Սահմանափակումներ, օրինակ՝ ռեսուրսների, բյուջեի եւ այլն: References (Հղումներ) Հարակից փաստաթղթերը ՝ առկայության դեպքում հղումներով, Project Plan-ով Configuration Management Plan-ով: Test Items (Թեստավորման առարկաները) Թվարկել թեստավորման առարկաները (software/products)՝ իրենց version-ներով: Features to be Tested (Փորձարկման ենթակա հատկություններ) Թվարկել software/product-ի փորձարկման ենթակա հատկությունները: Տրամադրել թեստավորվող հատկությունների Requirement-ների եւ/կամ Design-ի հղումները: Features Not to Be Tested (Չթեստավորվող հատկություններ) Թվարկել software/product-ի չփորձարկվող հատկությունները: Նշել պատճառները, թե ինչու չեն թեստավորվելու: Approach Նշել թեստավորման ընդհանուր մոտեցումը Նշել testing level-ները [եթե դա Master Test Plan է], թեստավորման տեսակները եւ մեթոդները [Manual/Automated; White Box/Black Box/Gray Box] Item Pass/Fail Criteria (Pass/Fail չափորոշիչներ) Նշել բոլոր չափանիշները յուրաքանչյուր Item-ի համար, որոնց դեպքում դրանք կհամարվեն Passed/Failed: Suspension Criteria and Resumption Requirements(Կասեցման չափորոշիչներ եւ վերսկսման պահանջներ) Նշել չափորոշիչները, որոնք կօգտագործվեն փորձարկման գործունեությունը կասեցնելու համար: Նշել փորձարկման գործողությունները, որոնք փորձարկումը վերսկսելու ժամանակ պետք է կրկին արվեն: Test Deliverables Թվարկել deliverable-ները, եւ եթե առկա են դրանց հղումները: Test Plan Test Cases Test Scripts Defect/Enhancement Logs Test Reports Test Environment (Թեստավորման միջավայր) Նշել փորձարկման միջավայրի հատկությունները՝ hardware, software, network եւ այլն. Թվարկել ցանկացած testing եւ հարակից tool-եր: Estimate Տրամադրել թեստավորման գնահատման ամփոփումը (ծախսեր, ջանքեր) եւ/կամ մանրամասն գնահատման հղում: Schedule (Ժամանակացույց) Տրամադրել ժամանակացույց կամ ժամանակացույցի հղումը: Staffing and Training Needs (Աշխատակազմի կամ ուսուցման անհրաժեշտություններ) Նշել աշխատակազմից պահանջվող հմտությունները ըստ դերերի: Որոշել թե ինչ training է հարկավոր աշխատակազմին համապատասխան հմտություններով ապահովելու համար, եթե դրանց արդեն իսկ չեն տիրապետում: Responsibilities (Պարտականություններ) Նշել յուրաքանչյուր թիմի / դերի / անհատի պարտականությունները: Ռիսկեր Նշեք այն ռիսկերը, որոնք հայտնաբերվել են: Յուրաքանչյուր ռիսկի համար նշել mitigation եւ the contingency plan : Assumptions and Dependencies (Ենթադրություններ եւ կախվածություններ) Նշել այն ենթադրությունները, որոնք արվել են պլանի պատրաստման ընթացքում: Նշել կախվածությունները: Approvals (Հաստատում) Նշել բոլոր անձանց անուններն ու դերերը, ովքեր պետք է հաստատեն plan-ը: Տրամադրել տարածք ստորագրությունների եւ ամսաթվերի համար: (Եթե փաստաթուղթը պետք է տպվի): <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/what-everybody-ought-to-know-about-test-planing.html" target="_blank">Test plan article/eng</a> <a href="https://www.youtube.com/watch?v=S2_AJP9Oeg0" target="_blank">Test plan video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=KH7oPMlAaSM" target="_blank">Test plan video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=Hq7dt5zVxL0" target="_blank">Test plan, Test case video tutorial/arm</a></blockquote>

Test Plan-ը կարևոր փաստաթուղթ է, որը նկարագրում է ծրագրային ապահովման փորձարկման գործընթացը:

Test Plan

<h3>Agile մոդել</h3> Agile-ը կոդավորման պրակտիկա է, որը հետևում է արագաշարժ ծրագրաշարի մշակման կանոններին և սկզբունքներին: Այս Agile ձեռնարկում դուք կսովորեք Agile, Agile մոդելների և մեթոդաբանությունների հիմունքները, Agile vs. Scrum-ի տարբերություններ, Scrum master ուսուցում Agile թեստավորման հարցազրույցի հարցերին և պատասխաններին: Agile-ի զարգացման այս ձեռնարկը բացարձակ սկսնակների ուղեցույց է Agile-ի համար, և Scrum թեստավորումը, ձեռնարկի կամ ավտոմատացման ծրագրային ապահովման փորձարկման հիմնական ըմբռնումը օգտակար կլինի: Ինչպե՞ս է աշխատում Agile-ը: 1.Ստեղծվում է առաջադրանքների ցանկ:2.Ամբողջ առաջադրանքը բաժանվում է մի քանի ավարտուն հատվածների:3.Յուրաքանչյուր հատվածին վերագրվում է որոշակի առաջնահերթություն:4.Սկսվում է իրականացումը:5.Թարմացվում է պլանը ընթացքի հնարավոր փոփոխությունների հետ կապված: Ինչո՞վ է տարբերվում Agile-ը: 1.Analysis, design, coding, testing, այս բոլորը շարունակական գործընթացներ են:2.Development-ը իտերատիվ է:3.Պլանը հարմարվող է, կարող է փոփոխվել:4.Նախատեսված ժամանակը կարող է փոփոխվել:5.Աշխատող ծրագիրը հաջողության չափանիշն է: Օգտագործողի պատմություններ և գնահատումներ: 1.Օգտատիրոջ պատմություններն այն հատկանիշներն են, որոնք մեր հաճախորդները կարող են մի օր ցանկանալ տեսնել իրենց ծրագրաշարում: 2.Դրանք գրված են ինդեքսային քարտերի վրա՝ խրախուսելու դեմ առ դեմ շփումը: 3.Սովորաբար աշխատում է ոչ ավելի, քան մի քանի օր, դրանք կազմում են մեր արագաշարժ ծրագրերի հիմքը: 4.Մենք դրանք ստանում ենք մեր հաճախորդներին շատ հարցեր տալով: Կրկնություններ Կրկնությունները Agile-ի զարգացման հիմնական շինանյութն են: Յուրաքանչյուր կրկնություն ստանդարտ, ֆիքսված երկարությամբ ժամանակացույց է, որտեղ Agile Teams-ը լրացուցիչ արժեք է հաղորդում աշխատանքային, փորձարկված ծրագրաշարի և համակարգերի տեսքով: Ժամկետի առաջարկվող տևողությունը երկու շաբաթ է: Այնուամենայնիվ, մեկից չորս շաբաթ ընդունելի է, կախված բիզնեսի համատեքստից: Կրկնություններն ապահովում են կանոնավոր, կանխատեսելի արագություն թիմերի համար՝ արժեքի աճ ստեղծելու, ինչպես նաև նախկինում մշակվածները ճշգրտելու համար: Այս կարճ ժամանակահատվածները օգնում են թիմին, արտադրանքի սեփականատերերին, արտադրանքի ղեկավարներին և այլ շահագրգիռ կողմերին կանոնավոր կերպով փորձարկել և գնահատել տեխնիկական և բիզնես վարկածները աշխատանքային համակարգում: Յուրաքանչյուր կրկնություն խարսխում է ինտեգրման կետը, «ձգողական իրադարձություն», որը հավաքում է համակարգի տարբեր ասպեկտներ՝ ֆունկցիոնալությունը, որակը, դասավորվածությունը և օգտագործման համար հարմարեցվածությունը, բոլոր թիմերի ներդրումներում: Քանի որ ամենակարճ կայուն ժամկետը Lean-Agile զարգացման կարևոր նպատակն է, Agile թիմերը հնարավորինս արագ իրականացնում են պլան-կատարել-ստուգում-հարմարեցնել (PDCA) ամբողջական ցիկլը: PDCA ուսուցման ցիկլը (ցուցադրված է Նկար 1-ում) ներկայացնում է հետևյալ կրկնվող իրադարձությունները. Plan– Կրկնվող պլանավորումը պլանի քայլն է Do– Կրկնություն Կատարումը անելու քայլն է Check– Կրկնվող վերանայումը ստուգման քայլն է Adjust– Կրկնության հետահայացը ճշգրտման քայլն է Պլանավորում և վերամշակում Master Story – Մեր անելիքների ցանկը agile նախագծի վերաբերյալ Team Velocity - Արագություն, որով մենք օգտվողների պատմությունները վերածում ենք աշխատանքային ծրագրաշարի Planning- կրկնություններ = ընդհանուր ջանք / թիմի գնահատված արագություն Refactoring- Քանի որ մենք ավելացնում ենք ավելի շատ ֆունկցիոնալություն համակարգին, մեզ անհրաժեշտ է մեր դիզայնը պահպանելու և մեր տունը կարգին պահելու միջոց:<blockquote style="text-align: justify;"> Օգտակար հղումներ՝ <a href="https://www.infoworld.com/article/3237508/what-is-agile-methodology-modern-software-development-explained.html" target="_blank">Agile methodology article/eng</a> <a href="https://scrumtrek.ru/blog/agile-scrum/4029/metodologiya-agile/" target="_blank">Agile methodology article/rus</a> <a href="https://www.youtube.com/watch?v=WjwEh15M5Rw" target="_blank">Agile methodology video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=TPrj-AMJ4Ds" target="_blank">Agile methodology video tutorial/rus</a></blockquote>

Ի՞նչ է Agile Model-ը և ինչպես է այն աշխատում:

Agile Model

<h3>Agile vs Waterfall</h3> User stories and estimation Agile-ում User story-ն ամենափոքր միավորն է, որի վրա աշխատում են: Այն end user-ի կամ customer-ի տեսանկյունից software-ի հատկությունների մասին գրավոր ընդհանուր բացատրությունն է: Գլխավոր նպատակն է պարզաբանել, թե ծրագրի փոքր կտորն ինչ արդյունք պիտի տա customer-ին: Դրանք գրվում են հասկանալի լեզվով եւ ընդգծում են ցանկալի արդյունքը՝ առանց մանրամասների: Պահանջներն ավելացվում են հետագայում թիմի համաձայնեցումից հետո: User story-ներից յուրաքանչյուրն ունենում է սահմանված point-եր՝ 1 pnt –small-ջանքեր չի պահանջում, 3 pnt – medium – անհաղթահարելի բան չկա, 5pnt – large – պահանջում է որոշակի ջանք, եւ իրենցից ներկայացնում են 1-2օրվա աշխատանք: Դրանք գրվում են հաճախորդների հետ մանրամասն քննարկումներ անելով: Scrum-ում user story-ներն ավելացվում են sprint-ներին,իսկ Kanban-ում դրանք հավաքվում են backlog-ի մեջ: Iterations Իտերացիան միավոր development cycle-ն է, որը տեւում է 1-2 շաբաթ: Այսինքն յուրաքանչյուր story անցնում է development cycle-ի փուլերով, որից հետո տվյալ պատրաստի մասը ցուցադրվում է պատվիրատուին եւ feedback արվում: Հենց այդ պրոցեսը կոչվում է իտերացիա: Planning and Refactoring Master Story – Բոլոր story-ների ցուցակն է: Refactoring-ը կոդը բարելավելու գոծընթացն է՝ պահպանելով առկա ֆունկցիոնալությունը: Նպատակը անարդյունավետ եւ բարդ կոդը արդյունավետ եւ հեշտ դարձնելն է: Եթե կոդը չունի լավ կառուցվածք եւ հեշտ պահպանվող չէ, ամեն իտերացիայից հետո կոդն ընդլայնել հնարավոր չի լինի: Իսկ եթե կոդը փոփոխվում է առանց պատշաճ Refactoring-ի, ապա դա կարող է նպաստել cod smell-ի եւ technical debt-ի առաջացմանը: Թեստավորողի գործն է Refactoring-ից հետո ստուգել bug-երի առկայությունը, ստուգել ֆունկցիոնալությունը պահպանվել է, թե ոչ եւ այլն: Team Velocity – Թիմի՝ user story-ն աշխատող ծրագիր դարձնելու, արագությունն է: Planning – Գնահատում է աշխատանքը, ջանքը՝ օգտագործելով իտերացիաները: iterations = total effort / estimated team velocity Agile planning-ը տարբերվում է նրանով, որ ոչ թե ամբողջական պլանավորում է, այլ՝- բաժանված է սպրինտների, - հիմնված է User story-ների վրա, - քայլ առ քայլ է, - գնահատումը կատարվում է թիմի անդամների կողմից: <table style="border-collapse:collapse;width: 100%;"><tbody>
<tr>
o<td style="width: 50%; text-align: center;">Agile </td>
o<td style="width: 50%; text-align: center;">Waterfall </td></tr>
<tr>
o<td style="width: 50%;">Այն բաժանում է նախագծի lifecycle-ը սպրինտների: </td>
o<td style="width: 50%;">Ծրագրային ապահովման մշակման գործընթացը բաժանված է առանձին փուլերի. </td></tr>
<tr>
o<td style="width: 50%;">Այն հետևում է աստիճանական մոտեցմանը: </td>
o<td style="width: 50%;">Waterfall մեթոդաբանությունը հաջորդական նախագծման գործընթաց է: </td></tr>
<tr>
o<td style="width: 50%;">Agile մեթոդոլոգիան հայտնի է իր ճկունությամբ: </td>
o<td style="width: 50%;">Waterfall-ը ծրագրային ապահովման մշակման կառուցվածքային մեթոդաբանություն է, ուստի շատ դեպքերում այն կարող է բավականին կոշտ լինել: </td></tr>
<tr>
o<td style="width: 50%;">Agile-ը կարելի է դիտարկել որպես բազմաթիվ տարբեր նախագծերի հավաքածու: </td>
o<td style="width: 50%;">Ծրագրային ապահովման մշակումը կավարտվի որպես մեկ միասնական նախագիծ: </td></tr>
<tr>
o<td style="width: 50%;">Agile-ը բավականին ճկուն մեթոդ է, որը թույլ է տալիս փոփոխություններ կատարել նախագծի մշակման պահանջներում, նույնիսկ եթե նախնական պլանավորումն ավարտված է: </td>
o<td style="width: 50%;">Ծրագրի մշակումը սկսելուց հետո պահանջները փոխելու հնարավորություն չկա: </td></tr>
<tr>
o<td style="width: 50%;">Agile մեթոդաբանություն, հետևեք կրկնվող զարգացման մոտեցմանը, քանի որ պլանավորման, մշակման, նախատիպի ձևավորման և ծրագրաշարի մշակման այլ փուլերը կարող են հայտնվել մեկից ավելի անգամ: </td>
o<td style="width: 50%;">Ծրագրի զարգացման բոլոր փուլերը, ինչպիսիք են նախագծումը, մշակումը, փորձարկումը և այլն, ավարտվում են մեկ անգամ ջրվեժի մոդելում: </td></tr>
<tr>
o<td style="width: 50%;">Փորձարկման պլանը վերանայվում է յուրաքանչյուր սպրինտից հետո: </td>
o<td style="width: 50%;">Թեստի պլանը հազվադեպ է քննարկվում թեստային փուլում: </td></tr>
<tr>
o<td style="width: 50%;">Agile development-ը գործընթաց է, որի ժամանակ ակնկալվում է, որ պահանջները փոխվեն և զարգանան: </td>
o<td style="width: 50%;">Մեթոդը իդեալական է այնպիսի նախագծերի համար, որոնք ունեն որոշակի պահանջներ և փոփոխություններ, որոնք բոլորովին չեն սպասվում: </td></tr>
<tr>
o<td style="width: 50%;">Agile մեթոդաբանության մեջ թեստավորումն իրականացվում է ծրագրային ապահովման մշակման հետ միաժամանակ: </td>
o<td style="width: 50%;">Այս մեթոդաբանության մեջ «testing» փուլը գալիս է «build» փուլից հետո </td></tr><tr>
o<td style="width: 50%;">Agile-ը ներկայացնում է արտադրանքի մտածելակերպ, որտեղ ծրագրային արտադրանքը բավարարում է իր վերջնական հաճախորդների կարիքները և փոխվում է ըստ հաճախորդի պահանջների: </td>
o<td style="width: 50%;">Այս մոդելը ցույց է տալիս նախագծային մտածելակերպը և ամբողջովին կենտրոնանում է նախագծի իրականացման վրա: </td></tr><tr>
o<td style="width: 50%;">Agile մեթոդաբանությունը բացառիկ լավ է աշխատում Time &amp; Materials-ի կամ ոչ ֆիքսված ֆինանսավորման հետ: Դա կարող է մեծացնել սթրեսը ֆիքսված գնով սցենարներում: </td>
o<td style="width: 50%;">Նվազեցնում է ռիսկը ընկերության ֆիքսված գնով պայմանագրերում` գործընթացի սկզբում ռիսկի համաձայնագիր ստանալով: </td></tr><tr>
o<td style="width: 50%;">Նախընտրում է փոքր, բայց նվիրված թիմեր՝ համակարգման և համաժամացման բարձր աստիճանով: </td>
o<td style="width: 50%;">Թիմի համակարգումը/համաժամեցումը շատ սահմանափակ է: </td></tr><tr>
o<td style="width: 50%;">Ապրանքների սեփականատերը թիմի հետ պատրաստում է պահանջները գրեթե ամեն օր նախագծի ընթացքում: </td>
o<td style="width: 50%;">Բիզնեսի վերլուծությունը նախապատրաստում է պահանջները նախքան նախագծի սկիզբը: </td></tr><tr>
o<td style="width: 50%;">Թեստային թիմը կարող է առանց խնդիրների մասնակցել պահանջների փոփոխությանը: </td>
o<td style="width: 50%;">Թեստի համար դժվար է նախաձեռնել պահանջների որևէ փոփոխություն: </td></tr><tr>
o<td style="width: 50%;">Ծրագրի մանրամասների նկարագրությունը կարող է փոփոխվել ցանկացած պահի SDLC գործընթացի ընթացքում: </td>
o<td style="width: 50%;">Մանրամասն նկարագրությունը պետք է իրականացնի Waterfall ծրագրային ապահովման մշակման մոտեցումը: </td></tr><tr>
o<td style="width: 50%;">Agile Team-ի անդամները փոխարինելի են, արդյունքում նրանք ավելի արագ են աշխատում: Ծրագրի ղեկավարների կարիք նույնպես չկա, քանի որ նախագծերը ղեկավարվում են ամբողջ թիմի կողմից </td>
o<td style="width: 50%;">Waterfall մեթոդով գործընթացը միշտ պարզ է, ուստի ծրագրի ղեկավարը կարևոր դեր է խաղում SDLC-ի յուրաքանչյուր փուլում: </td></tr></tbody></table> <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://worksection.com/blog/waterfall-vs-agile.html" target="_blank">Agile vs Waterfall article/rus</a> <a href="https://www.youtube.com/watch?v=rvTejAg_fbY" target="_blank">Agile vs Waterfall video tutorial/eng</a> <a href="https://project-management.com/agile-vs-waterfall/" target="_blank">Agile vs Waterfall article/eng</a> </blockquote>

Ո՞րն է տարբերությունը Agile և Waterfall մոդելների միջև:

Agile vs Waterfall

<h3>Scrum Methodology</h3> Scrum-ը Agile-ի համապատասխան մեթոդոլոգիա է, որում կան երեք առանցքային դերեր՝ Scrum Master – Պատասխանատու է թիմի կազմավորման, sprint meeting-ների, ներսում առաջացած խնդիրների լուծման, «արտաքին աշխարհ»-ի հետ բոլոր քննարկումների կազմակերպման եւ բանակցությունները վարելու համար: Product Owner – Թիմում հաճախորդի ներկայացուցիչն է: Պատասխանատու է product backlog-ի ստեղծման, backlog-ի առաջնահերթությունների որոշման, յուրաքանչյուր իտերացիայում ճիշտ ֆունկցիոնալության առաքման համար: Նա պետք է ամբողջությամբ տիրապետի պահանջներին: Scrum Team – Բաղկացած է 6-8 հոգուց ( Developer &amp; QA): Թիմը պատասխանատու է product-ի առաքման համար: Թիմը պետք է մասնակցի ամենօրյա Scrum meeting-ներին եւ զեկուցի status-ը: Backlog – Product-ի բոլոր պահանջների, User story-ների պահոցն է, որն անընդհատ զարգանում է եւ երբեք ամբողջական չէ: Sprint backlog – Խնդիրների ցուցակն է, որոնք պետք է ըստ առաջնայնության կատարվեն տվյալ Sprint-ի ընթացքում: <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.atlassian.com/agile/scrum" target="_blank">Scrum methodology article/eng</a> <a href="https://www.atlassian.com/ru/agile/scrum" target="_blank">Scrum methodology article/rus</a> <a href="https://www.youtube.com/watch?v=8dGdIcyDk1w" target="_blank">Scrum methodology video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=mockcEwNBbs" target="_blank">Scrum methodology video tutorial/rus</a></blockquote>

Scrum-ը որպես Agile մոդելի մաս։

Scrum Methodology

<h3>Kanban Methodology</h3> Kanban-ը Agile-ին համապատասխան մեթոդ է: Kanban-ը ճապոներեն բառ է, որը նշանակում է board` տախտակ, որը պարունակում է product-ը ավարտին հասցնելու համար ամբողջ ինֆորմացիան: Kanban-ը pull system է, այսինքն աշխատանքր քաշվում է համակարգ, երբ թիմը կարողություն ունի, ավելին քան task-երը, որ արդեն կան top-ում: Այն օգտագործվում է պրոցեսները եւ աշխատանքային հոսքը բարելավելու համար՝ առանց թիմի կառուցվածքում փոփոխություններ անելու: Visualize workflow (Պատկերացնել աշխատանքային հոսքը)– Առաջին եւ ամենակարեւոր խնդիրը ընթացիկ աշխատանքային հոսքը պարզելն է, այսինքն ինչ քայլերի հաջորդականություն է պետք item-ը request-ից deliverable product դարձնելու համար: Սա արվում է Kanban board-ի օգնությամբ, որտեղ յուրաքանչյուր սյուն իրենից ներկայացնում է աշխատանքային հոսքի քայլ, իսկ յուրաքանչյուր քարտ՝ work item: Յուրաքանչյուր item հոսքով շարժվում է սկզբից մինչեւ վերջ, որը հեշտությամբ թույլ է տալիս հետեւել առաջընթացին եւ խցանումերին: Limit Work in Progress (WIP) – Ընթացիկ աշխատանքի սահմանափակումն է: Կենտրոնացման կորուստը կարող է լրջորեն վնասել թիմի արտադրողականությանը, ուստի ընթացիկ աշխատանքի սահմանափակումը թիմին կենտրոնացնում է չավարտած աշխատանքը կատարելու վրա մինչ նորին անցնելը: Enhance flow (Ավելացնել հոսքը) Որեւէ բան ավարտելուց հետո backlog-ից հոսքի մեջ ենք դնում ամենաբարձր item-ը: <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.atlassian.com/agile/kanban" target="_blank">Kanban methodology article/eng</a> <a href="https://upr.ru/article/metodologiya-kanban-sekrety-effektivnogo-ispolzovaniya/" target="_blank">Kanban methodology article/rus</a> <a href="https://www.youtube.com/watch?v=1_Zti9v5ugA" target="_blank">Kanban methodology video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=iVaFVa7HYj4" target="_blank">Kanban methodology video tutorial/eng</a></blockquote>

Kanban-ը որպես Agile մոդելի մաս։

Kanban Methodology

<h3>Scrum VS Kanban</h3> <table style="border-collapse:collapse;width: 100%;"><tbody>
<tr>
o<td style="width: 50%; text-align: center;">Scrum</td>
o<td style="width: 50%; text-align: center;">Kanban</td></tr>
<tr>
o<td style="width: 50%;">Scrum-ը շեշտը դնում է պլանավորման վրա: Այն սկսվում է սպրինտի պլանավորումից և ավարտվում է սպրինտի հետահայացությամբ: Կան բազմաթիվ հանդիպումներ, որոնք օգնում են հավաստիացնել, որ թիմը համահունչ է հաջորդ քայլերին, առաջնահերթություններին և նախորդ սպրինտներից ստացված գիտելիքներին: </td>
o<td style="width: 50%;">Kanban-ը բաց է փոփոխություններ կատարելու համար: Դա նշանակում է, որ ավելի քիչ կոշտություն կա, և ամեն ինչ կարող է հաճախակի փոխվել: </td></tr>
<tr>
o<td style="width: 50%;">Այն առաջարկում է հավաքել ժամանակի չափումները, որոնք կատարվել են սպրինտների ժամանակ: </td>
o<td style="width: 50%;">Kanban-ն առաջարկում է գրաֆիկներ՝ ժամանակի ընթացքում թիմի առաջընթացի ակնարկ ստանալու համար: </td></tr>
<tr>
o<td style="width: 50%;">Scrum-ն այլևս թիմերից պարտավորություն չի պահանջում: Փոխարենը խոսքը սպրինտի նպատակների ու կանխատեսումների մասին է։ </td>
o<td style="width: 50%;">Kanban-ը հենվում է ժամանակի և կանխատեսումների վրա: </td></tr>
<tr>
o<td style="width: 50%;">Այն շեշտը դնում է պլանավորման վրա, ուստի գնահատումը շատ կարևոր դեր ունի Scrum-ում: </td>
o<td style="width: 50%;">Kanban-ը գնահատման համար պարտադիր պահանջներ չունի: </td></tr>
<tr>
o<td style="width: 50%;">Յուրաքանչյուր անհատ ունի իր դերն ու պարտականությունները։ </td>
o<td style="width: 50%;">Չկան սահմանված դերեր, այնքան ճկունություն անհատական պարտականությունների առումով: </td></tr>
<tr>
o<td style="width: 50%;">Կրկնությունները/սպրինտները ամրագրված են տևողությամբ: Այս տեւողությունը տատանվում է 2 շաբաթից մինչեւ 1 ամիս։ </td>
o<td style="width: 50%;">Kanban-ը հիմնված չէ տևողության վրա: Այս բանը չափվում է ցիկլի ժամանակների հետ կապված: </td></tr>
<tr>
o<td style="width: 50%;">Թիմերից պահանջվում է որոշակի ծավալի աշխատանք կատարել: </td>
o<td style="width: 50%;">Պարտավորությունը պարտադիր չէ, այն ընտրովի է թիմերի համար: </td></tr>
<tr>
o<td style="width: 50%;">Այս մեթոդում խաչաձև ֆունկցիոնալ թիմերը կարևոր են, քանի որ նրանք կարող են հաղթահարել ցանկացած խափանում, որը կարող է խոչընդոտներ առաջացնել ծրագրային ապահովման մշակման մեջ: </td>
o<td style="width: 50%;">Կարևոր է մասնագիտացված թիմ ունենալը։ </td></tr>
<tr>
o<td style="width: 50%;">Հնարավոր չէ ավելացնել տարրեր շարունակական կրկնություններին: </td>
o<td style="width: 50%;">Նոր տարրերը կարող են հեշտությամբ ավելացնել, եթե առկա է լրացուցիչ հզորություն: </td></tr><tr>
o<td style="width: 50%;">Sprint-ի հետաձգումը պատկանում է միայն մեկ թիմին: </td>
o<td style="width: 50%;">Բազմաթիվ թիմեր կարող են կիսել Kanban տախտակը: </td></tr><tr>
o<td style="width: 50%;">Առաքումը որոշվում է սպրինտներով, որոնք պետք է ավարտվեն և պատրաստ լինեն վերանայման: </td>
o<td style="width: 50%;">Ապրանքները և գործընթացները շարունակաբար առաքվում են անհրաժեշտ հիմունքներով: Այսպիսով, թեստավորման և վերանայման գործընթացը շարունակվում է միաժամանակ: </td></tr><tr>
o<td style="width: 50%;">Scrum ծրագրային ապահովման մշակման մեթոդը կենտրոնանում է հետին պլանի վրա: </td>
o<td style="width: 50%;">Kanban մեթոդը ամբողջությամբ կենտրոնանում է գործընթացի վահանակի վրա: </td></tr><tr>
o<td style="width: 50%;">Թիմի յուրաքանչյուր անդամ ունի հատուկ դեր Scrum Master-ի ժամանակացույցի որոշման մեջ, արտադրանքի սեփականատերը սահմանում է նպատակներ և խնդիրներ, և թիմի անդամներն իրականացնում են զարգացման աշխատանքը: </td>
o<td style="width: 50%;">Թիմի համար նախապես սահմանված դերեր չկան: Այնուամենայնիվ, դեռ կարող է լինել Ծրագրի կառավարիչ; թիմը խրախուսվում է համագործակցել և աշխատել միասին: </td></tr><tr>
o<td style="width: 50%;">Լավագույնը փոփոխվող առաջնահերթություններ ունեցող նախագծերի համար: </td>
o<td style="width: 50%;">Իդեալական է կայուն առաջնահերթություններ ունեցող թիմերի համար, որոնք ժամանակի ընթացքում դժվար թե փոխվեն: </td></tr><tr>
o<td style="width: 50%;">Չափում է արտադրությունը՝ օգտագործելով արագությունը սպրինտների միջոցով: </td>
o<td style="width: 50%;">Չափում է արտադրությունը՝ օգտագործելով ցիկլի ժամանակը կամ այն ճշգրիտ ժամանակը, որն անհրաժեշտ է նախագծի մեկ ամբողջական հատվածն ավարտելու համար: </td></tr><tr>
o<td style="width: 50%;">Scrum-ը պահանջում է ամբողջական անցում ավանդական մոդելից Agile Scrum մոդելին, որը կիրականացվի նախագիծը: </td>
o<td style="width: 50%;">Kanban-ը թույլ չի տալիս կտրուկ փոփոխություններ նախագծում։ </td></tr><tr>
o<td style="width: 50%;">Այն իդեալական մեթոդ է լայնորեն տարբեր առաջնահերթություններ ունեցող նախագծերի համար: </td>
o<td style="width: 50%;">Լավագույնը հարմար և կայուն առաջնահերթություններ ունեցող թիմերի համար: </td></tr><tr>
o<td style="width: 50%;">Scrum-ում ամբողջ թիմը կենտրոնանում է համագործակցելու և առաջադրանքն ավարտելու վրա՝ ապահովելու որակյալ զարգացման աշխատանք: </td>
o<td style="width: 50%;">Թիմերը աշխատում են նպատակներին հասնելու և ամբողջ գործընթացը ավարտելու, ժամանակը կրճատելու համար: Այսպիսով, ժամանակային ցիկլի կրճատումն այստեղ հաջողության ամենամեծ ցուցանիշն է։ </td></tr><tr>
o<td style="width: 50%;">Scrum-ը շեշտը դնում է իր ժամանակացույցի վրա. նոր տարրեր չեն կարող ավելացվել շարունակական կրկնություններին: </td>
o<td style="width: 50%;">Kanban-ն իր բնույթով ավելի կրկնվող է, քանի որ այն չունի կոնկրետ ժամկետներ: Այսպիսով, նոր տարրերը կարող են շարունակաբար ավելացվել, երբ առկա է լրացուցիչ հզորություն: </td></tr></tbody></table> <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.guru99.com/scrum-vs-kanban.html" target="_blank">Scrum vs Kanban article/eng</a> <a href="https://asana.com/ru/resources/waterfall-agile-kanban-scrum" target="_blank">Scrum vs Kanban article/rus</a> <a href="https://www.youtube.com/watch?v=GLFuzBiy18o" target="_blank">Scrum vs Kanban video tutorial/eng</a></blockquote>

Տարբերությունները երկու Agile մեթոդոլոգիաների միջև՝ Scrum և Kanban:

Scrum VS Kanban

<h3>Վեբ տեխնոլոգիաների դերը Որակի ապահովման ոլորտում</h3> Ծանոթանանք վեբ տեխնոլոգիաներում հաճապ կիրառվող տերմինների հետ։ Տերմինաբանություն WWW (Word Wide Web) - ինֆորմացիոն տիրույթ է, որտեղ փաստաթղթերն ու այլ վեբ ռեսուրսները նույնականացված են URL-ներով։ URI (Uniform Resource Identifier) - սիմվոլային տող է, որը բնորոշում է որոշակի ռեսուրս։ URN (Uniform Resource Name) - URI-է, որը բնորոշում է ռեսուրսը անունով՝ հատուկ անվան դաշտում։ URL (Uniform Resource Locator) – արտահայտություն է, որը ցույց է տալիս ռեսուրսի տեղը համակարգչային ցանցում։ Այն ներառում է պրոտոկոլը (http(s)), hostname-ը (www.example.com) և ֆայլի անունը (index.html): Web Browser – software app է, որը նախատեսված է www-ի ինֆորմացիային դիմելու համար։ Web Server - ընդունում է HTTP-հարցումներ հաճախորդներից, սովորաբար վեբ դիտարկչի կողմից, և վերադարձնելով HTTP-պատասխաններ, ինչպես ընդունված է HTML-էջեր, պատկերներ, ֆայլեր, լրատվամիջոցների հոսք կամ այլ տվյալներ։ Web Page – փաստաթուղթ է, որը հարմար է նկարագրել որպես www-ի web ռեսուրս։ Web Site – web էջերի ամբողջություն։ Client side-ը տեսանելի է օգտագործողին, իսկ server side-ը՝ ոչ։ Protocols Ստորև ներկայացված են 4 հիմնական պրոտոկոլները․ IP (Internet Protocol) FTP (File Transfer Protocol) HTTP (Hypertext Transfer Protocol) HTTPS (Hypertext Transfer Protocol Secure) Cash - Պահեստ է, որտեղ հավաքվում են տվյալները (ռեսուրսները), որոնք արդեն մեկ անգամ ստացվել են հարցման արդյունքում։ Cookie - Փոքր ֆայլեր են, որոնք ներբեռնվում են համակարգչից, երբ հարցում է կատարվում վեբ կայքին։ Authentication - Ստուգում է Data-ում տվյալների առկայությունը։ Authorization - ստուգում է էջին ունեցած հասանելիությունը։ Տարբեր օգտատերեր կարող են ունենալ տարբեր հասանելիություն միևնույն կայքին։ HTTP(S)-ի մեթոդները՝ get – իրականացնել հարցում և ստանալ պատասխան։ Սա կոչվում է get request post –ստեղծել որևէ նոր բան put – փոխել գոյություն ունեցող որևէ բան, այսինքն՝ update։ delete – ջնջել Մեթոդներից յուրաքանչյուրի աշխատանքի արդյունքում ստանում ենք response, որն ունի status code։ Դրանք ներկայացված են ստորև․ 1** - information (ինֆորմացիա) 2** - success (հաջողված) 3** - redirect (անցում այլ կայք) 4** - not fount, user error (օգտատիրոջ սխալ) 5** - server error (սերվերի սխալ) <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP" target="_blank">HTTP Basics article/eng</a> <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods" target="_blank">HTTP methods article/rus</a> <a href="https://www.youtube.com/watch?v=eesqK59rhGA" target="_blank">HTTP and WEB video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=9aycvfzH8UA" target="_blank">HTTP video tutorial/rus</a> <a href="https://www.youtube.com/watch?v=FsE0W7_l3uo" target="_blank">HTTP response video tutorial/arm</a></blockquote>

Ո՞րն է վեբ տեխնոլոգիաների դերը Որակի ապահովման ոլորտում։

Վեբ տեխնոլոգիաների դերը Որակի ապահովման ոլորտում

<h3>Regular expressions</h3> Տերմինաբանություն ^_ - նշում է տողը, որը սկսվում է _ -ով։ _$ - նշում է տողը, որը վերջանում է _ -ով։ abc* - abc / |c|&gt;=0 abc+ - abc / |c|&gt;=1 abc? - abc / |c|={0,1} abc{2} - abc / |c|=2 abc{2,5} - abc / 2&lt;=|c|&lt;=5 d - նշում է թվերը՝ հատ առ հատ (d)+ - նշում է երկու թվերի միջև ընկած թվային հատվածը w - նշում է տառերը՝ հատ առ հատ (w)+ - նշում է երկու տառերի միջև ընկած տառային հատվածը, այսինքն՝ բառերը (D)+ - նշում է երկու թվերի միջև ընկած ոչ թվային հատվածը s - բացատ [0-9] - նշում է [0-9] միջակայքի թվերը՝ հատ առ հատ [0-9]+ - նշում է մի քանի թիվ [0-9]+ [a-z] +[0-9]+ -թիվ, տառ, թիվ [^_] – նշում է ամեն ինչ, բացի բացատից [_] – նշում է միայն _ -երը • - նշում է մեկ սիմվոլ Օրինակ՝ (/d [a,z] + /d (,) /s [0,6]+) .$ <img src="https://lh4.googleusercontent.com/O5bWLkMcrUEwsqT2cy5oWr4R01dMpmVNrl4x60H3NEV5dj6kj0tW4sWGy7WNULq2cOA2N993YgbCuraUDhzAWyHS0t46zKCpeoQnTXFFTWFzQX0QytZSlgWSmmk2lg161ZvQFYUlrFr_R1ooDtyTh1M7YDfok4R3jjxPTLV2Q7oz4AUq81jVYMz6kcxbTDNzT3guy9Lw"> <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions" target="_blank">Regular expressions article/eng</a> <a href="https://developer.mozilla.org/ru/docs/Web/JavaScript/Guide/Regular_Expressions" target="_blank">Regular expressions article/rus</a> <a href="https://www.youtube.com/watch?v=sa-TUpSx1JA" target="_blank">Regular expressions video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=_pLpx6btq6U" target="_blank">Regular expressions video tutorial/rus</a></blockquote>

Regular expressions

Linux-ը որպես օպերացիոն համակարգի միջուկ:

Linux օպերացիոն համակարգ

<h3>Git</h3> Git-ը կոդերի տարբերակների վերահսկողության համակարգ է (Version Control System): Այն հնարավորություն է տալիս հետևել կոդի փոփոխությանը ցանկացած պահի։ Յուրաքանչյուր փոփոխություն (commit) ունի իր ունիկալ կոդը, որի միջոցով կարելի է վերադառնալ կոդի տվյալ տարբերակին, այսինքն՝ նախորդ բոլոր տարբերակները պահպանվում են։ Բոլոր կոդերը պահպանվում են որևէ սերվերի վրա։ Այնտեղից վերցնում ենք վերջին տարբերակը, փոփոխում և նորից ուղարկում սերվերին։ Եթե կատարում ենք որևէ փոփոխություն և չենք ցանկանում այն ուղարկել սերվերին, ապա ստեղծում ենք branch, այնուհետև push ենք անում վերջինիս վրա և այդ branch-ի անունը ուղարկում ենք նրանց, ովքեր պետք է տեսնենք կատարված փոփոխությունը։ Master Branch-ի վրա լինում է վերջնական կոդը, որը պետք է հանձնել պատվիրատուին։ Develop Branch-ի վրա կատարվում են բոլոր անհրաժեշտ փոփոխությունները, և վերջնական պատրաստ լինելու դեպքում այն տեղափոխում ենք Master Branch-ի վրա։ Commit անելու համար կոդը վերցնում ենք Develop Branch-ից, ստեղծում ենք մեր սեփական Branch-ը, փոփոոխում ենք կոդը և ավարտելուց հետո այն նորից ուղարկում Develop Branch-ին։ Տերմիանաբանություն git status – բոլոր փոփոխությունների ցանկ git add name - ավելացնում է փոփոխություն ունեցող ֆայլը git commit -m “message” – փոփոխություն է անում local branch-ի վրա git push- փոփոխում է repository-ում git checkout branchname – Branch-ը փոխելու համար git config --list – նախատեսվախ է բոլոր տեղադրված պարամետրերը դիտելու և դրանց ճշգրիտ տեղը պարզելու համար git branch – բոլոր branch-ները, որոնց վրա գոնե մեկ commit կա git checkout -b “name” – ստեղծում է branch և տեղափոխվում git add -p filename – ցույց է տալիս փոփոխությունները՝ մինչև ավելացնելը git log – բոլոր commit-ները <blockquote style="text-align: justify;">Օգտակար հղումներ՝ <a href="https://www.atlassian.com/git/tutorials/what-is-git" target="_blank">Git article/eng</a> <a href="https://www.atlassian.com/git" target="_blank">Git article/eng</a> <a href="https://www.youtube.com/watch?v=SWYqp7iY_Tc" target="_blank">GitHub video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=CRlGDDprdOQ" target="_blank">Git video tutorial/eng</a></blockquote>

Git-ը որպես Version Control System.

Visual (GUI) method

ԸՆԿԵՐՈՒԹՅՈՒՆ

ԾԱՌԱՅՈՒԹՅՈՒՆՆԵՐ