Anարպիկ միջավայրում, որտեղ մենք աշխատում ենք կարճատև արագությամբ կամ կրկնությամբ, յուրաքանչյուր արագավազք կենտրոնացած է ընդամենը մի քանի պահանջների կամ օգտագործողների պատմությունների վրա, ուստի բնական է, որ փաստաթղթավորումը կարող է լինել այդքան էլ ծավալուն ՝ թե քանակի, թե բովանդակության առումով:
Արագ փորձարկման ռազմավարության փաստաթղթի նպատակն է թվարկել լավագույն փորձը և կառուցվածքի որոշակի ձև, որը թիմերը կարող են հետևել: Հիշեք, ճարպկություն չի նշանակում չկառուցված:
Այստեղ մենք դիտում ենք Agile Test ռազմավարության նմուշը և այն, ինչ ներառել փաստաթղթում:
Թեստային ռազմավարությունը սովորաբար ունի առաքելության հայտարարություն, որը կարող է կապված լինել բիզնեսի ավելի լայն նպատակների և խնդիրների հետ:
Առաքելության բնորոշ հայտարարությունը կարող է լինել.
Անընդհատ մատուցել աշխատանքային ծրագրակազմ, որը բավարարում է հաճախորդի պահանջները `արագ արձագանքման ապահովում և թերությունների կանխարգելում, այլ ոչ թե թերությունների հայտնաբերում:
Աջակցում է ՝
- Ոչ մի կոդ չի կարող գրվել պատմության համար, քանի դեռ մենք նախ չենք սահմանել դրա ընդունման չափանիշները / թեստերը
- Մի պատմություն չի կարող համարվել ավարտված, քանի դեռ չեն անցել դրա ընդունման բոլոր թեստերը
Agile Test ռազմավարության փաստաթղթում ես նաև բոլորին հիշեցում կներառեմ որակի ապահովման վերաբերյալ
ՈԱ-ն գործողությունների ամբողջություն է, որի նպատակն է ապահովել, որ ապրանքները համակարգված, հուսալի կերպով բավարարեն հաճախորդի պահանջները:
SCRUM (ճկուն) ՈԱ-ն բոլորի պարտականությունն է, ոչ միայն փորձարկողների: ՈԱ-ն այն բոլոր գործողություններն են, որոնք մենք անում ենք `նոր որակի զարգացման ընթացքում ճիշտ որակ ապահովելու համար:
ԻՆՉՈՒ Ապահովելու համար, որ ծածկագիրը ճիշտ է մշակվել
ԱՀԿ: Մշակողներ / տեխնիկական ճարտարապետներ
ԻՆՉ: Բոլոր նոր ծածկագրերը + ժառանգական ծածկագրի վերա-ֆակտորինգը, ինչպես նաև Javascript- ի միավորի փորձարկում
ԵՐԲ: Հենց նոր կոդ է գրվում
ՈՐՏԵ Տեղական Dev + CI (կառուցվածքի մի մաս)
ԻՆՉՊԵՍ: Ավտոմատացված, Junit, TestNG, PHPUnit
ԻՆՉՈՒ Ապահովելու համար, որ բաղադրիչների միջև կապը գործում է
ԱՀԿ: Մշակողներ / տեխնիկական ճարտարապետներ
ԻՆՉ: Նոր վեբ ծառայություններ, բաղադրիչներ, կարգավորիչներ և այլն
ԵՐԲ: Հենց նոր API- ն մշակվի և պատրաստ լինի
ՈՐՏԵ Տեղական Dev + CI (կառուցվածքի մի մաս)
ԻՆՉՊԵՍ: Ավտոմատացված, օճառի միջերես, հանգստի հաճախորդ
ԻՆՉՈՒ Ապահովելու համար, որ հաճախորդի սպասելիքները բավարարվեն
ԱՀԿ: Մշակող / SDET / ձեռնարկ QA
ԻՆՉ: Պատմությունների ընդունման թեստերի ստուգում, առանձնահատկությունների ստուգում
ԵՐԲ: Երբ հատկությունը պատրաստ է և միավորը փորձարկված է
ՈՐՏԵ CI / Test միջավայր
ԻՆՉՊԵՍ: Ավտոմատացված (վարունգ)
ԻՆՉՈՒ Ապահովելու համար, որ ամբողջ համակարգը գործում է, երբ ինտեգրված է
ԱՀԿ: SDET / Manual QA / Բիզնես վերլուծաբան / Ապրանքի սեփականատեր
ԻՆՉ: Սցենարի փորձարկում, օգտագործողի հոսքեր և բնորոշ օգտագործողի ճանապարհորդություններ, կատարման և անվտանգության փորձարկում
ԵՐԲ: Երբ ընդունման թեստավորումն ավարտվում է
ՈՐՏԵ Բեմական միջավայր
ԻՆՉՊԵՍ: Ավտոմատացված (Webdriver) հետախուզական փորձարկում
Softwareրագրակազմի մշակման ձախողման ամենատարածված պատճառը անհասկանալի պահանջների և թիմի տարբեր անդամների կողմից պահանջների տարբեր մեկնաբանության հետ է կապված:
Օգտատերերի պատմությունները պետք է լինեն պարզ, հակիրճ և միանշանակ: Որպես լավ ուղեցույց, լավագույնն է հետևել INVEST մոդելին ՝ օգտագործողների պատմություններ գրելու համար:
Օգտագործողի լավ պատմությունը պետք է լինի.
Ես անկախ (բոլոր մյուսներից)
Ն վիճելի (առանձնահատկությունների համար հատուկ պայմանագիր չէ)
Վ փոփոխական (կամ ուղղահայաց )
ԻՆՉ Է դյուրագրգիռ (լավ մոտավորություն)
Ս առեւտրի կենտրոն (այնպես, որ տեղավորվի կրկնության մեջ)
Տ կայուն (սկզբունքորեն, նույնիսկ եթե դրա համար դեռ փորձություն չկա)
Հետևյալ ձևաչափը պետք է օգտագործված լինի օգտագործողների պատմությունները գրելու համար
As a [role] I want [feature] So that [benefit]
Կարևոր է չմոռանալ «Նպաստ» մասը, քանի որ բոլորը պետք է տեղյակ լինեն, թե ինչ արժեք են ավելացնում `զարգացնելով պատմությունը:
Օգտագործողի պատմություններից յուրաքանչյուրը պետք է պարունակի ընդունման չափանիշներ: Հնարավոր է, սա ամենակարևոր տարրն է, որը խրախուսում է թիմի տարբեր անդամների հետ շփումը:
Ընդունման չափանիշները պետք է գրվեն, երբ օգտագործողի պատմությունը ստեղծվի, և այն պետք է ներառված լինի պատմության մարմնում: Ընդունման բոլոր չափանիշները պետք է ստուգվեն:
Ընդունման յուրաքանչյուր չափանիշ պետք է ունենա ընդունման մի շարք թեստեր, որոնք ներկայացված են որպես սցենարներ գրված գերկինի ձևաչափով, օրինակ.
Scenario 1: Title Given [context] And [some more context]... When [event] Then [outcome] And [another outcome]...
Յուրաքանչյուր պատմվածքների սեմինարում թիմում բոլորը սովորում են պատմությունների մանրամասների մասին, այնպես որ մշակողները և ՈԱ-ն գիտեն աշխատանքի շրջանակը: Բոլորը պետք է ունենան նույն պատկերացումը, թե ինչի մասին է պատմությունը:
Մշակողները պետք է լավ հասկանան այն տեխնիկական մանրամասները, որոնք ներգրավված են պատմությունը հանձնելու մեջ, և ՈԱ-ն պետք է իմանա, թե ինչպես է փորձարկվելու պատմությունը և եթե պատմությունները փորձելու համար խոչընդոտներ կան:
Պատմության սեմինարներում Պետք է ներգրավվեն PO, BA, Dev և QA:
Պետք է մտածել սցենարների մասին (վավեր, անվավեր և ծայրահեղ դեպքեր) (ՈԱ-ն այստեղ կարող է հսկայական արժեք ավելացնել ՝ պատմության մասին աբստրակտ մտածելով) և գրի առարկա ֆայլերում:
Կարևոր է նշել, որ սցենարները (առավել քան որևէ այլ բան) կբացահայտեն թերությունները արտադրանքը փորձարկելիս, ուստի որքան շատ ջանք ու ժամանակ ծախսվի այս գործունեության վրա, վերջում լավագույն արդյունքը:
Քանի որ թերությունների մեծամասնությունը պայմանավորված է անորոշ և անորոշ պահանջներով, այս գործողությունը կօգնի նաև կանխել սխալ վարքի իրականացումը, քանի որ բոլորը պետք է նույն պատկերացումները ունենան պատմության վրա:
Նմանապես, սպրինտ պլանավորման հանդիպումներում, պատմության համար տրված գնահատականները պետք է ներառեն նաև փորձարկման և ոչ միայն կոդավորման ջանքեր: Պետք է ներկա լինի նաև ՈԱ (ձեռնարկ և ավտոմատացում) սպրինտ պլանավորման հանդիպումներում ՝ պատմության փորձարկման նախահաշիվը տրամադրելու համար:
Երբ մշակումն սկսվում է, պետք է ապահովվի արտադրության նոր ծածկագրի և (կամ) ժառանգության ծածկագրում փոփոխության կատարումը մշակողների կողմից գրված միավորի թեստեր և գնահատվում է մեկ այլ մշակողի կամ հմուտ SDET- ի կողմից:
Կոդի պահեստի նկատմամբ ցանկացած պարտավորություն պետք է խթանի CI սերվերից միավորի փորձարկումների կատարումը: Սա զարգացման թիմին արագ հետադարձ մեխանիզմ է ապահովում:
Միավորների փորձարկումները ապահովում են, որ համակարգը գործում է տեխնիկական մակարդակում և տրամաբանության մեջ սխալներ չկան:
Որպես մշակող, պահեք ձեզ այնպես, կարծես թիմում կամ կազմակերպությունում որևէ ՈԱ չունեք: Qիշտ է, որ ՈԱ-ները տարբեր մտածելակերպ ունեն, բայց դուք պետք է փորձեք ձեր հնարավորությունների սահմաններում:
Դուք կարծում եք, որ ժամանակ եք խնայում արագ անցնելով հաջորդ պատմությանը, բայց իրականում, երբ հայտնաբերվում և հայտնվում է թերություն, խնդիրը շտկելու համար ավելի շատ ժամանակ է պահանջվում, քան մի քանի րոպե անցկացնելը ՝ համոզվելով, որ գործառույթը լավ է աշխատում:
Newանկացած նոր ծածկագիր և (կամ) ժառանգական ծածկագրի վերափոխում պետք է ունենա համապատասխան միավորի թեստեր, որոնք կդառնան միավորի հետընթացի թեստի մի մաս:
Ընդունման ավտոմատացված թեստերը ներառում են ինտեգրման թեստեր և սպասարկման թեստեր և UI թեստեր, որոնց նպատակն է ապացուցել, որ ծրագրակազմը գործում է ֆունկցիոնալ մակարդակում, և որ այն համապատասխանում է օգտվողի պահանջներին և բնութագրերին:
Ընդունման ավտոմատացված թեստերը սովորաբար գրվում են հերկինի լեզվով և կատարվում են վարունգի նման BDD գործիքի միջոցով:
Հիշիր : Ոչ բոլոր թեստերը պետք է ավտոմատացվեն:
Քանի որ այս թեստերը, որպես կանոն, պահանջում են հաղորդակցություն HTTP
- ի շուրջ, դրանք պետք է կատարվեն տեղակայված ծրագրի վրա, այլ ոչ թե գործարկվեն որպես կառուցվածքի մաս:
Ոչ ֆունկցիոնալ թեստեր ինչպիսիք են Կատարման և Անվտանգության թեստերը նույնքան կարևոր են, որքան ֆունկցիոնալ թեստերը, ուստի պետք է կատարվեն յուրաքանչյուր տեղակայման վրա:
Կատարման թեստերը պետք է ստուգեն կատարման ցուցանիշները յուրաքանչյուր տեղակայման վրա ՝ ապահովելու համար որևէ կատարողականի դեգրադացիա:
Անվտանգության թեստերը պետք է ստուգեն անվտանգության հիմնական խոցելիությունները, որոնք առաջացել են OWASP
Շատ կարևոր է, որ սա պետք է լինի ամբողջովին ավտոմատացված գործընթաց `շատ քիչ սպասարկումով` ավտոմատ տեղակայություններից առավելագույն օգուտ ստանալու համար: Սա նշանակում է, որ չպետք է լինեն ընդհատվող թեստի ձախողումներ, թեստի սցենարի խնդիրներ և կոտրված միջավայր:
Ձախողումները պետք է պայմանավորված լինեն միայն կոդի իսկական արատներով, այլ ոչ թե սցենարի խնդիրներով, հետևաբար, ցանկացած ձախողման փորձարկում, որը չի պայմանավորված իրական խափանումներով, պետք է շտկվի անմիջապես կամ հանվի ավտոմատացման փաթեթից, որպեսզի կարողանա հետեւողական արդյունք ունենալ:
Չսպասելով բազմաթիվ արատներ գտնելուն: Նրանց նպատակը միայն հետադարձ կապի տրամադրումն է, որը մենք չենք կոտրել հիմնական ֆունկցիոնալությունը: Պետք է լինի շատ քիչ քանակությամբ ձեռքի ռեգրեսիայի փորձարկում:
Այս փաթեթը պարունակում է միայն բարձր մակարդակի ֆունկցիոնալություն ՝ համոզվելու համար, որ հավելվածը բավականին կայուն է հետագա զարգացման կամ փորձարկման համար:
Օրինակ, էլեկտրոնային առևտրի կայքի համար այս փաթեթում ներառված թեստերը կարող են լինել.
Այս տուփը պարունակում է թեստերի հետադարձ ռեեստրի ամբողջական փաթեթ և պարունակում է այն ամենը, ինչ ներառված չէ ծխի տուփի մեջ:
Այստեղ նպատակն է արագ արձագանք ստանալ ավելի մեծ թեստերով: Եթե հետադարձ կապը տևում է 1 ժամից ավելի, դա արագ չէ: Կամ կրճատեք թեստերի քանակը, օգտագործելով զույգերով թեստավորման տեխնիկա, ստեղծեք թեստային փաթեթներ ՝ ելնելով ռիսկից, կամ զուգահեռ վարեք թեստերը:
Պատճառ չկա, թե ինչու UAT- ը և հետախուզական փորձարկումը չեն կարող ընթանալ ավտոմատացված ընդունման թեստերին զուգահեռ: Ի վերջո, դրանք տարբեր գործողություններ են և նպատակ ունեն գտնել տարբեր խնդիրներ: UAT- ի նպատակն է ապահովել, որ մշակված առանձնահատկությունները բիզնեսի իմաստը և օգտակար լինեն հաճախորդներին:
PO- ն (ապրանքի սեփականատեր) պետք է կատարի Օգտագործողի ընդունման թեստեր կամ Ներդրված արտադրանքը հաստատելու համար Բիզնեսի ընդունման թեստեր այն է, ինչ սպասվում էր, և որ այն համապատասխանում է օգտագործողի սպասելիքներին:
Հետախուզական փորձարկումը պետք է կենտրոնանա օգտագործողների սցենարների վրա և պետք է գտնի այն սխալները, որոնք ավտոմատացումը բաց է թողնում: Հետախուզական փորձարկումը չպետք է աննշան սխալներ գտնի, այլ պետք է գտնի նուրբ խնդիրներ:
Վերոնշյալ բոլոր գործողություններն ավարտելուց և որևէ խնդիր չհայտնաբերվելուց հետո պատմությունն այն է Կատարած!
Վերոնշյալը մի քանի ուղեցույց է այն մասին, թե ինչ կարող է ներառվել Agile Test ռազմավարության փաստաթղթում: Ակնհայտ է, որ դա պետք է համապատասխանեցվի ձեր կազմակերպության կարիքներին, բայց հուսով եմ, որ այս ձևանմուշը կօգնի ձեզ ստեղծել ձեր սեփական Agile Test ռազմավարության փաստաթուղթը: