Ինչպես գրել լավ սխալների մասին հաշվետվություններ. Առաջարկություններ

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

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

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

Իմ անունը Եվգենի Դոմնին է. Ես QA- ն եմ և կփորձեմ կիսվել իմ տեսակետով այն մասին, թե ինչն է լավ վրիպակի մասին հաշվետվություն: Կներեք երկար ներածության համար. եկեք սկսենք:

Վերնագիր

Տոմսի վերնագրում փորձեք պատասխանել երեք հարցի.

1. Որտեղ է դա տեղի ունենում:
2. Ի՞նչ է պատահում։
3. Ի՞նչ հանգամանքներում:

Փորձառու ծրագրավորողին միայն պետք է մի հայացք նետի վերնագրին՝ խնդիրը հասկանալու համար: Օրինակ.

Մուտքի էջ. սխալ գաղտնաբառ մուտքագրելիս դաշտը ընդգծված չէ

Շրջակա միջավայր

Ես հաճախ եմ տեսել, որ թեստավորողները մոռանում են տոմսում նշել, թե որ միջավայրում է խնդիրը տեղի ունեցել: Սա հատկապես կարևոր է UI-ի հետ կապված տոմսերի դեպքում, որտեղ վեբ կայքի հասցեն կամ ցանցի հարցումը տեսանելի չէ: Միշտ նշեք սա: Եթե տոմսի մեջ առանձին դաշտ կա, լավ է, դրեք այնտեղ: Եթե ոչ, նշեք այն վերարտադրման քայլերում, օրինակ.

Մուտք գործեք բեմական միջավայր՝ ադմինիստրատորի հաշվի միջոցով:

Խոսելով քայլերի մասին...

Վերարտադրման քայլերը

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

Տեսողական մաս

Պահպանել կառուցվածքը

Սխալների հաշվետվությունների տարբեր տարբերակներ կան, բայց դասականորեն դրանք պետք է պարունակեն հետևյալ բաժինները.

1. Քայլեր
2. Ակնկալվող արդյունք
3. Փաստացի արդյունք

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

Օգտագործեք համարակալված ցուցակ

Քանդեք քայլերը՝ օգտագործելով համարակալված ցուցակը: Երբեմն փորձարկողները գրում են մանրամասն նկարագրություններ, բայց որպես տեքստի շարունակական բլոկի: Մի արեք սա: Բոլորի համար շատ ավելի հեշտ կլինի կարդալ, եթե քայլերն առանձնացվեն։

Հնարավորության դեպքում գրեք առանց քերականական սխալների:

Այժմ անցնենք այս քայլերի բովանդակությանը։

Ընդհանուր իմաստը նկարագրություններում

Պետք չէ յուրաքանչյուր գործողություն բաժանել առանձին քայլի, եթե դա կարևոր չէ սխալը վերարտադրելու համար. սա դժվար է կարդալ և օգտագործել գործնականում: Մի վախեցեք ներառել բազմաթիվ գործողություններ մեկ քայլով: Ի՞նչ նկատի ունեմ:

Վատ :

1. Գնացեք test.com/login

2. Կտտացրեք մուտքի դաշտը

3. Մուտքագրեք մուտքը

4. Կտտացրեք գաղտնաբառի դաշտը

5. Մուտքագրեք գաղտնաբառը

   
   

Լավ :

1. Գնացեք test.com/login և մուտք գործեք ցանկացած հաշիվ

Մենք քայլերը չենք բաժանում այն բաների, որոնք մշակողը բնականաբար կանի` հետևելով ստանդարտ հոսքին: Երբ ես սկսում էի, մտածում էի, որ յուրաքանչյուր գործողություն իր քայլի կարիք ունի, բայց դա անհրաժեշտ չէ:

Խուսափեք երկիմաստությունից

Միշտ լրացրեք քայլերը յուրաքանչյուր քայլում ստուգելու հատուկ խնդրանքով և գրեք սեղմելու համար հատուկ կոճակը (հատկապես եթե կան նույնանուն կոճակներ):

Ներառեք թեստի տվյալները

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

Կրկին վերանայեք ձեր քայլերը

Երբեմն, դուք գրում եք քայլերը սխալին հանդիպելուց անմիջապես հետո, բայց կարող է պարզվել, որ դուք բաց եք թողել քայլը լիարժեք հասկանալու համար, կամ սխալը չի կարող հետագայում վերարտադրվել: Այդ դեպքում հնարավոր է, որ ավելի ճշգրիտ քայլերի կարիք լինի։

Ակնկալվող արդյունք

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

Փաստացի արդյունք

Այստեղ մենք գրում ենք, թե իրականում ինչ է տեղի ունեցել, երբ հետևել ենք քայլերին: Այստեղ կարևոր է նաև յուրահատկությունը: Պարզապես մի գրեք «ամեն ինչ կոտրվեց» (չնայած, որ հավանաբար այդպես է եղել): Նկարագրեք այն ցուցանիշները, որոնք ցույց են տալիս, որ ամեն ինչ կոտրվել է: Օրինակ՝

GET /accounts հարցումով վերադարձվում է 500 սխալ , և UI-ն արգելափակված է: Օգտագործողը չի կարող դուրս գալ էջից կամ սեղմել տարրերի վրա:

Էջի թարմացումը կրկին գործարկում է հարցումը և հանգեցնում է նույն սխալին:

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

Լրացուցիչ ֆայլեր

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

Սխալի սքրինշոթներ

Ավելի լավ է մեկ անգամ տեսնել, քան հարյուր անգամ լսել: Սա հիանալի միջոց է տեսողականորեն ցույց տալու, թե ինչ է տեղի ունենում և որտեղ: Միշտ փորձեք կցել սքրինշոթ:

Հայց

Եթե կա հարցում, որտեղ սխալ է տեղի ունեցել, այն միշտ պետք է ներառվի տոմսի մեջ: Այնուամենայնիվ, հարցումները պարունակում են շատ տարբեր պարամետրեր: Ես կարևորում եմ հետևյալը ներառելու համար.

• Սխալի URL – հարցումն ինքնին, որը կարող եք ստանալ բրաուզերի Ցանց բաժնից, որտեղ կատարվում է թեստավորումը:

• Մեթոդ – GET , POST , TRACE , OPTION և այլն: Կան բազմաթիվ մեթոդներ, ինչպես որ կան հարցումներ նույն URL-ով, բայց տարբեր մեթոդներով: Մի մոռացեք նշել այն տոմսի մեջ:

• Սխալի կոդը ևս մեկ կարևոր կետ: Դուք հավանաբար չեք մոռանա այն, բայց մի մոռացեք նշել, թե ինչ կոդը է վերադարձվել սերվերից:

• Payload – սա այն տվյալներն են, որոնք մենք ուղարկել ենք մեր հարցումով սերվերին: Սա չկա ամեն հարցում (օրինակ՝ HEAD-ը կամ GET-ը չունեն), բայց դա կարող է լինել սխալի պատճառը:

• Պատասխան - սերվերի պատասխանը: Երբեմն այն պարունակում է ամբողջ սխալը, նույնիսկ ցույց տալով, թե որտեղ է այն տեղի ունեցել, մինչդեռ երբեմն դա պարզապես լռելյայն տեղապահ է, որը ստեղծվել է հետին պլանում այդ տեսակի սխալի համար: Համոզվեք, որ ներառեք սա. դա ծրագրավորողին շատ ժամանակ կխնայի:

Վահանակով տեղեկամատյաններ

Երբեմն վահանակում սխալներ են հայտնաբերվում, և դրանք կարող են ավելացվել տոմսին: Միգուցե դուք արդեն արել եք դա, բայց ես պարզապես նշեմ, որ տեքստի մեծ բլոկը միշտ կարող է պահպանվել որպես .log ֆայլ և ավելացնել տոմսին: Սա բարելավում է ինչպես տեղեկամատյանների, այնպես էլ բուն տոմսի ընթեռնելիությունը:

Այս ամենը լավ է և լավ, բայց...

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

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

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

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

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

Եթե ունեք հարցեր, առաջարկներ, անհամաձայնություններ կամ բողոքներ, ազատ զգալ թողեք դրանք մեկնաբանություններում, ինձ հետաքրքրում է ձեր կարծիքը: