Ինչպես կարգավորել QA գործառույթը քերծվածքից

Դա սովորական սցենար է. Ստարտափ ընկերությունն ունի նոր գաղափար և վարձում է մի շարք ծրագրավորողների ՝ գաղափարի աշխատանքային մոդելը կառուցելու համար:

Սկսնակ գործերի բնույթի պատճառով, այսինքն `շատ քիչ ֆինանսավորում, որը կարճ ժամանակում է` գաղափարի մշակման համար, հիմնական ջանքերը կենտրոնանում են նոր արտադրանքի ստեղծման վրա `այն հանրությանը հանելու համար ջրերը փորձարկելու համար, և, բնականաբար, փորձարկել և ՈԱ-ն զարգացման թիմի գլխավոր գերակայությունը չէ:

Այն բանից հետո, երբ ակնհայտ դարձավ, որ գաղափարը հաջող է, ընկերությունը ցանկանում է ընդլայնել գաղափարը և սկսում է ավելի շատ ծրագրավորողների վարձել, բայց միևնույն ժամանակ, նրանք ցանկանում են, որ ապրանքը փորձարկվի նախքան այն հանրությանը հայտնվի:


Որոշ ժամանակ փորձարկումն իրականացնում է յուրաքանչյուր ոք, ով մատչելի է ընկերությունում, և այն հիմնականում ժամանակավոր բնույթ է կրում, առանց համապատասխան գործընթացների հետևելու:

Հետո գալիս է մի պահ, երբ ստարտափ ընկերությունը որոշում է վարձել իրենց առաջին բարձրորակ որակի անձնավորությանը ՝ զարգացման թիմի համար նոր ՈԱ գործընթաց իրականացնելու համար:


Այս հոդվածի նպատակների համար ես ենթադրելու եմ, որ ստարտափը վեբ վրա հիմնված ընկերություն է, օրինակ. էլեկտրոնային առևտրի կայք:



ՈԱ գործընթացի իրականացում

Որակի ապահովման գործընթաց ունենալու հիմնական նպատակն է ապահովել, որ ճիշտ ապրանքը ճիշտ կառուցվի, առաջին անգամ: Դա նշանակում է, որ մենք պետք է ապահովենք, որ պահանջները ճիշտ սահմանված լինեն, և զարգացման թիմը ամուր պատկերացում ունենա նոր առանձնահատկությունների ֆունկցիոնալության մասին, նախքան կոդավորումը սկսելը:

Կարևոր է նշել, որ թեստավորումը փուլ չէ, դա գործունեություն է, և որ թեստավորումը սկսվում է զարգացման գործընթացի հենց սկզբից, հենց օգտագործողի պատմությունները գրելու պահից:

Թեստավորումը պետք է աջակցի զարգացմանը, այնպես որ փորձարկման գործողությունները զուգահեռ են զարգացման գործողություններին, և զարգացման գործընթացի յուրաքանչյուր փուլում մենք պետք է ապահովենք, որ ծածկագիրը մանրակրկիտ ստուգվի:


Թեստավորման գործընթացն իրականացնելուց առաջ մենք պետք է իմանանք զարգացման ընթացիկ մեթոդաբանությունն ու գործընթացը և անհրաժեշտության դեպքում ճշգրտումներ կատարենք գործընթացը բարելավելու համար:

Հետընթաց թեստավորում / արագավազքի թեստավորում

Ընկերությունում որպես առաջին որակի ապահովման անձնավորություն սկսելիս հավանականությունը մեծ է, որ հետընթացի փորձարկում չլինի, և նոր գործառույթների մշակման արդյունքում դուք գաղափար չեք ունենա, եթե դրանք բացասաբար են անդրադառնում գործող աշխատանքային կայքում: Ավելին, դուք պետք է հետևեք զարգացման թիմին ՝ նոր գործառույթները փորձարկելու համար ՝ ապահովելու համար, որ դրանք ճիշտ են գործում և ըստ բնութագրերի:

Parallelուգահեռաբար կա առնվազն երկու առաջադրանք. Սպրինտում նոր պատմությունների փորձարկում և հետընթացի որոշ աստիճանի ստուգում:

Նոր առանձնահատկությունների փորձարկումն առաջնային է, քանի որ նոր ծածկագրում սխալներ հայտնաբերելու հավանականությունն ավելի շատ է, քան առկա աշխատանքային կայքը կոտրելը: Միևնույն ժամանակ, հետընթացի թեստավորումը պահանջվում է ՝ ապահովելու համար, որ գոյություն ունեցող հավելվածը շարունակի գործել, երբ մենք ստեղծում ենք նոր առանձնահատկություններ:


Հետընթացի փորձարկման փաթեթը պետք է կատարվի հենց դիմումում թարմացում լինի, այնպես որ զարգացման թիմը կարող է ստանալ արագ արձագանք դիմումի առողջության մասին:

Հետընթացի թեստեր գրելու, ինչպես նաև նոր գործառույթների փորձարկումներին հետևելու համար բավարար ժամանակ չկա: Ինչպե՞ս կարող ենք խախտել այս ցիկլը:

Սովորաբար սպրինտի առաջին մի քանի օրվա ընթացքում մշակողները զբաղված են կոդավորմամբ, ուստի նոր գործառույթները որոշ ժամանակ պատրաստ չեն փորձարկման: Ահա լավ հնարավորություն է սկսելու աշխատել ռեգրեսիայի թեստերի վրա:

Ռեգրեսիայի փորձարկման լավագույն փորձեր կան, բայց ընդհանուր առմամբ, մոտեցումը կլինի օգտվողների հիմնական հիմնական ուղևորությունների բացահայտումը ամբողջ կայքում, որպեսզի կայքի յուրաքանչյուր նոր թողարկման ժամանակ մենք վստահ լինենք, որ հավելվածը դեռևս օգտագործելի է իր մեծամասնության կողմից: օգտագործողներ:


Կարիք չկա այս սցենարների սպառիչ ցուցակ ունենալ, պարզապես հիմնական և ամենակարևորը բավական կլինի մի փոքր ռեգրեսիոն փաթեթ սկսելու համար, որը կարող է կատարվել յուրաքանչյուր կառուցվածքի վրա: Հետագայում, երբ ռեգրեսիայի փաթեթը հասունանում է, մենք կարող ենք սկսել ավելացնել ավելի շատ սցենարներ:

Ամենակարևորը, հետընթացի այս սցենարները պետք է ավտոմատացվեն:

Ավտոմատացված թեստավորում

Anարպիկ նախագծում, որտեղ արագավազքը սովորաբար տևում է մոտ երկու շաբաթ, բավարար ժամանակ չկա բոլոր ձեռքով փորձարկումները կատարելու համար: Կա նոր պատմությունների փորձարկում, ինչպես նաև ռեգրեսիայի փորձարկում: Չնայած իմաստ ունի նոր հատկանիշներ ստուգելու համար կատարել հետախուզական փորձարկումներ, ռեգրեսիայի թեստերը պետք է ավտոմատացվեն ՝ նույն թեստերը ձեռքով բազմիցս կատարելու աշխարհիկ առաջադրանքը նվազեցնելու համար:

Խողովակաշարի տեղակայում / կառուցում

Anարպիկ նախագծում տեղակայելը կամ կառուցելու համար խողովակաշարը սահմանում է, թե ինչպես է պատմությունը անցնում արտադրանքի կուտակումից դեպի կենդանի արտադրության կայք: Այն սահմանում է գործընթաց և գործողություններ, որոնք տեղի են ունենում յուրաքանչյուր փուլում:


Որակի ապահովման հաջող գործընթաց իրականացնելու համար, որը հավաստիացնում է, որ մենք հաճախակի ենք արձակում որակի կոդ, տեղակայման խողովակաշարը պետք է սահմանվի և պահպանվի բոլոր շահագրգիռ կողմերի կողմից: Տեղակայման խողովակաշարը ծրագրային ապահովման ողնաշարն է:

Խողովակաշարը պետք է հիմնված լինի լավագույն փորձի վրա և ներառի յուրաքանչյուր փուլում տեղի ունեցող գործողությունները:

Պատմության սեմինարներ

Anարպիկ ծրագրի ամենակարևոր գործողություններից մեկը պատմությունների սեմինարի հաճախակի դասընթացներն են: Դա այն դեպքում, երբ ապրանքի սեփականատերը, մշակողները և փորձարկողները հավաքվում են սենյակում և սկսում մշակել և մանրամասնել պատմությունների մանրամասները: Սա կարևոր է, քանի որ բոլորը պետք է ունենան նույն ընկալումը պատմության մեջ, նախքան զարգացման աշխատանքները սկսելը:

Որակի ապահովումը ոչ թե հայտնաբերման, այլ թերությունների կանխարգելմանն է վերաբերում: Պատմության սեմինարներում թիմը հնարավորություն է ունենում հարցեր տալ պատմության մանրամասների, տեխնիկական կամ նախագծային ցանկացած խոչընդոտների և պատմությունները զարգացնելու ցանկացած արգելափակման մասին:

Ահա հիանալի հնարավորություն է սկսելու գրել պատմությունների ընդունման չափանիշները: Յուրաքանչյուրը պետք է նպաստի և սկսի մտածել յուրաքանչյուր սցենարի հնարավոր սցենարների մասին, քանի որ յուրաքանչյուրն ունենալու է մեկ այլ գաղափար, այնպես որ որքան շատ պատմություն լինի, այնքան սցենար կարելի է մտածել և արատների կանխարգելման կանխարգելման ավելի մեծ հնարավորություն:

Երբ բոլորը համոզվեն յուրաքանչյուր պատմության մանրուքի և ծավալի վերաբերյալ, զարգացումը սկսվում է:

Developրագրավորողի փորձարկում / թեստավորում մշակման ընթացքում

Բոլորը պետք է պատասխանատու լինեն արտադրանքի որակի համար, և ոչ միայն փորձարկողները: Որպես այդպիսին, անհրաժեշտ է, որ «մշակողի փորձարկումներ» լինեն բավարար քանակությամբ ՝ ապահովելու համար, որ գրված ծածկագիրը բարձրորակ է ՝ նախքան փորձարկման միջավայրում տեղակայվելը հետագա փորձարկման համար:

Իհարկե, ֆունկցիոնալության յուրաքանչյուր նոր կտոր պետք է լավ փորձարկվի: Բացի այդ, պետք է լինեն ինտեգրման թեստեր, API թեստեր, ինչպես նաև UI թեստեր:

Գործընկերների կոդերի վերանայումները կամ «ընկերների փորձարկումները» կարող են երկրորդ հայացքը դնել մշակողի աշխատանքի վրա: Փորձարկողը կարող է օգնել վերանայել միավորի թեստերը, ինչպես նաև API թեստերը ՝ համոզվելու համար, որ ճիշտ թեստեր են գրվել, ինչպես նաև կօգնի գրել բարձր մակարդակի ավտոմատացված UI թեստեր:

Շարունակական ինտեգրում / թեստային միջավայրեր

Նոր գործառույթներն արդյունավետորեն փորձարկելու համար մենք պետք է ապահովենք, որ ծածկագիրը գործում է ոչ միայն մշակողի մեքենայի, այլ նաև այլ միջավայրերի վրա և ինտեգրված է մշակողի այլ կոդի հետ:

Շարունակական ինտեգրումը օգնում է բացահայտել գործընթացում կառուցման ցանկացած խնդիր, որպեսզի, երբ տեղակայումը ձախողվի, մենք կարողանանք պարզել, թե որտեղից է խնդիրը գալիս:

Թեստային միջավայրը փորձարկողներին և թիմի մյուս անդամներին հնարավորություն է տալիս ստուգել նոր գործառույթները նախքան ուղիղ հեռարձակումը:

Ոչ ֆունկցիոնալ թեստավորում

Անհրաժեշտության դեպքում մենք պետք է նաև իրականացնենք ոչ ֆունկցիոնալ փորձարկումներ, ինչպիսիք են կատարման, բեռի և անվտանգության փորձարկումները: Բավականին հաճախ ուշադրությունը կենտրոնանում է ֆունկցիոնալությունը լավ աշխատելու վրա, սակայն ոչ ֆունկցիոնալ փորձարկմանը պետք է տրվի նույն առաջնությունը, հատկապես վեբ հավելվածների համար, քանի որ դրանք կարող են ենթարկվել մեծ բեռի և (կամ) հարձակման:

Իրականացնելով ոչ ֆունկցիոնալ փորձարկում, մենք կարող ենք վստահ լինել, որ մեր ծրագիրը կարող է հաղթահարել բեռը պիկ ժամերին, և դա բաց չէ անվտանգության սպառնալիքների համար:

Քննարկման այլ կետեր

  • Խաչաձև զննարկիչ, Խաչի սարքի փորձարկում
  • Բջջայինի և պլանշետի փորձարկում
  • Ավտոմատացված փորձարկումների զուգահեռ կատարում
  • Հետախուզական փորձարկում
  • Գործիքներ, ինչպիսիք են iraիրան, enենկինսը, Սելենիան և այլն
  • Շարունակական բարելավում
  • Փորձարկողների հավաքագրում