Պատկերացրեք, որ դուք ծրագրավորող եք, և փորձարկողը ձեզ բերում է սխալ, որը հայտնաբերվել է ռեգրեսիայի ժամանակ: Դուք ցանկանում եք շտկել այս սխալը, ուստի խնդրում եք տոմս ստեղծել: Դուք արդեն պատկերացնում եք, թե ինչպես կվերցնեք այն, կկապեք ձգման հարցումները և ավելացնեք գնահատականներ, որպեսզի ապրանքի մենեջերը որևէ հարց չունենա:  Անցնում է որոշ ժամանակ, հայտնվում է նոր տոմս, բայց ներսում ընդամենը մի երկու տող կա և սքրինշոթ։ Հառաչելով՝ դուք փորձում եք վերարտադրել սխալը՝ օգտագործելով այս տեղեկատվությունը, բայց սխալ չկա: Փորձում ես մի քանի անգամ, բայց վերջում գրում ես փորձարկողին, որ սխալը չի կարող վերարտադրվել, և սկսվում է պարզաբանումների նոր փուլ։  Դուք ժամանակ եք ծախսում, որը կարող էր օգտագործվել նոր առաջադրանքների վրա աշխատելու, այլ սխալներ շտկելու կամ նույնիսկ   վերափոխում կոդը: դիտելու համար, թե ինչպես է անիմե  Իմ անունը   է. Ես   ն եմ և կփորձեմ կիսվել իմ տեսակետով այն մասին, թե ինչն է լավ վրիպակի մասին հաշվետվություն: Կներեք երկար ներածության համար. եկեք սկսենք: Եվգենի Դոմնին QA-   Վերնագիր  Տոմսի վերնագրում փորձեք պատասխանել երեք հարցի.   Որտեղ է դա տեղի ունենում:   Ի՞նչ է պատահում։   Ի՞նչ հանգամանքներում:  Փորձառու ծրագրավորողին միայն պետք է մի հայացք նետի վերնագրին՝ խնդիրը հասկանալու համար: Օրինակ.   Մուտքի էջ. սխալ գաղտնաբառ մուտքագրելիս դաշտը ընդգծված չէ   Շրջակա միջավայր  Ես հաճախ եմ տեսել, որ թեստավորողները մոռանում են տոմսում նշել, թե որ միջավայրում է խնդիրը տեղի ունեցել: Սա հատկապես կարևոր է UI-ի հետ կապված տոմսերի դեպքում, որտեղ վեբ կայքի հասցեն կամ ցանցի հարցումը տեսանելի չէ: Միշտ նշեք սա: Եթե տոմսի մեջ առանձին դաշտ կա, լավ է, դրեք այնտեղ: Եթե ոչ, նշեք այն վերարտադրման քայլերում, օրինակ.   Մուտք գործեք բեմական միջավայր՝ ադմինիստրատորի հաշվի միջոցով:  Խոսելով քայլերի մասին...   Վերարտադրման քայլերը  Ամենակարևոր բաժիններից մեկը սխալների վերարտադրության հրահանգներն են: Ես կնշեմ երկու մասի վրա, որոնց վրա պետք է ուշադրություն դարձնել՝ քայլերի ձևաչափումը (տեսողական) և բովանդակությունը (տվյալների ներսում):  Տեսողական մաս   Պահպանել կառուցվածքը  Սխալների հաշվետվությունների տարբեր տարբերակներ կան, բայց դասականորեն դրանք պետք է պարունակեն հետևյալ բաժինները.  Քայլեր  Ակնկալվող արդյունք  Փաստացի արդյունք  Օգտագործեք այս կառուցվածքը և միշտ հավատարիմ մնացեք դրան: Սա այն դեպքերից է, երբ միանմանությունը կօգնի կազմակերպել ձեր մտքերը խնդիրը նկարագրելիս:   Օգտագործեք համարակալված ցուցակ  Քանդեք քայլերը՝ օգտագործելով համարակալված ցուցակը: Երբեմն փորձարկողները գրում են մանրամասն նկարագրություններ, բայց որպես տեքստի շարունակական բլոկի: Մի արեք սա: Բոլորի համար շատ ավելի հեշտ կլինի կարդալ, եթե քայլերն առանձնացվեն։  Հնարավորության դեպքում գրեք առանց քերականական սխալների:  Այժմ անցնենք այս քայլերի բովանդակությանը։  Ընդհանուր իմաստը նկարագրություններում  Պետք չէ յուրաքանչյուր գործողություն բաժանել առանձին քայլի, եթե դա կարևոր չէ սխալը վերարտադրելու համար. սա դժվար է կարդալ և օգտագործել գործնականում: Մի վախեցեք ներառել բազմաթիվ գործողություններ մեկ քայլով: Ի՞նչ նկատի ունեմ:    : Վատ  Գնացեք  test.com/login  Կտտացրեք մուտքի դաշտը  Մուտքագրեք մուտքը  Կտտացրեք գաղտնաբառի դաշտը  Մուտքագրեք գաղտնաբառը    : Լավ  Գնացեք   և մուտք գործեք ցանկացած հաշիվ test.com/login  Մենք քայլերը չենք բաժանում այն բաների, որոնք մշակողը բնականաբար կանի` հետևելով ստանդարտ հոսքին: Երբ ես սկսում էի, մտածում էի, որ յուրաքանչյուր գործողություն իր քայլի կարիք ունի, բայց դա անհրաժեշտ չէ:   Խուսափեք երկիմաստությունից  Միշտ լրացրեք քայլերը յուրաքանչյուր քայլում ստուգելու հատուկ խնդրանքով և գրեք սեղմելու համար հատուկ կոճակը (հատկապես եթե կան նույնանուն կոճակներ):   Ներառեք թեստի տվյալները  Տրամադրեք մուտքի տվյալներ, եթե սխալը կապված է ձեր հաշվի հետ, և մի հապաղեք ներառել փորձնական բեռներ, որոնք օգնում են վերարտադրել վրիպակը:   Կրկին վերանայեք ձեր քայլերը  Երբեմն, դուք գրում եք քայլերը սխալին հանդիպելուց անմիջապես հետո, բայց կարող է պարզվել, որ դուք բաց եք թողել քայլը լիարժեք հասկանալու համար, կամ սխալը չի կարող հետագայում վերարտադրվել: Այդ դեպքում հնարավոր է, որ ավելի ճշգրիտ քայլերի կարիք լինի։   Ակնկալվող արդյունք  Առանձին բաժինը ակնկալվող արդյունքն է, որտեղ մենք նկարագրում ենք (զարմանալի չէ) արդյունքը, որը ակնկալվում է, երբ քայլերը կատարվեն: Այստեղ շատ հատուկ առաջարկներ չկան, բացի այն, որ այս բաժինը պետք է գոյություն ունենա. մշակողը պետք է հասկանա, թե ինչ վարքագծի պետք է հանգեցնի ֆունկցիոնալությունը: «Ամեն ինչ պետք է լավ աշխատի» արտահայտությունները չեն կտրում այն, գրեք կոնկրետ վարքագիծը:   Փաստացի արդյունք  Այստեղ մենք գրում ենք, թե իրականում ինչ է տեղի ունեցել, երբ հետևել ենք քայլերին: Այստեղ կարևոր է նաև յուրահատկությունը: Պարզապես մի գրեք «ամեն ինչ կոտրվեց» (չնայած, որ հավանաբար այդպես է եղել): Նկարագրեք այն ցուցանիշները, որոնք ցույց են տալիս, որ ամեն ինչ կոտրվել է: Օրինակ՝       GET /accounts հարցումով վերադարձվում է 500 սխալ , և UI-ն արգելափակված է: Օգտագործողը չի կարող դուրս գալ էջից կամ սեղմել տարրերի վրա:   Էջի թարմացումը կրկին գործարկում է հարցումը և հանգեցնում է նույն սխալին:  Այլ կերպ ասած, նկարագրեք իրական ազդեցությունը և ինչպես է այն ազդում օգտագործողի հոսքի վրա:   Լրացուցիչ ֆայլեր  Սա առանձին հատված է, որը արժանի է հիշատակման: Այստեղ դուք կցում եք լրացուցիչ տեղեկություններ, որոնք նկարագրում են սխալը: Ես գիտեմ որոշ մշակողների, ովքեր վերարտադրման քայլեր կարդալու սիրահար չեն և անմիջապես անցնում են իրական արդյունքին և լրացուցիչ նյութերին, որոնք բացատրում են դա:  Սխալի սքրինշոթներ  Ավելի լավ է մեկ անգամ տեսնել, քան հարյուր անգամ լսել: Սա հիանալի միջոց է տեսողականորեն ցույց տալու, թե ինչ է տեղի ունենում և որտեղ: Միշտ փորձեք կցել սքրինշոթ:  Հայց  Եթե կա հարցում, որտեղ սխալ է տեղի ունեցել, այն միշտ պետք է ներառվի տոմսի մեջ: Այնուամենայնիվ, հարցումները պարունակում են շատ տարբեր պարամետրեր: Ես կարևորում եմ հետևյալը ներառելու համար.    – հարցումն ինքնին, որը կարող եք ստանալ բրաուզերի Ցանց բաժնից, որտեղ կատարվում է թեստավորումը: Սխալի URL    –   ,   ,   ,   և այլն: Կան բազմաթիվ մեթոդներ, ինչպես որ կան հարցումներ նույն URL-ով, բայց տարբեր մեթոդներով: Մի մոռացեք նշել այն տոմսի մեջ: Մեթոդ GET POST TRACE OPTION    ևս մեկ կարևոր կետ: Դուք հավանաբար չեք մոռանա այն, բայց մի մոռացեք նշել, թե ինչ կոդը է վերադարձվել սերվերից: Սխալի կոդը    – սա այն տվյալներն են, որոնք մենք ուղարկել ենք մեր հարցումով սերվերին: Սա չկա ամեն հարցում (օրինակ՝ HEAD-ը կամ GET-ը չունեն), բայց դա կարող է լինել սխալի պատճառը: Payload    - սերվերի պատասխանը: Երբեմն այն պարունակում է ամբողջ սխալը, նույնիսկ ցույց տալով, թե որտեղ է այն տեղի ունեցել, մինչդեռ երբեմն դա պարզապես լռելյայն տեղապահ է, որը ստեղծվել է հետին պլանում այդ տեսակի սխալի համար: Համոզվեք, որ ներառեք սա. դա ծրագրավորողին շատ ժամանակ կխնայի: Պատասխան  Վահանակով տեղեկամատյաններ  Երբեմն վահանակում սխալներ են հայտնաբերվում, և դրանք կարող են ավելացվել տոմսին: Միգուցե դուք արդեն արել եք դա, բայց ես պարզապես նշեմ, որ տեքստի մեծ բլոկը միշտ կարող է պահպանվել որպես   ֆայլ և ավելացնել տոմսին: Սա բարելավում է ինչպես տեղեկամատյանների, այնպես էլ բուն տոմսի ընթեռնելիությունը: .log   Այս ամենը լավ է և լավ, բայց...  Այս ամենը լավ է, բայց որտեղի՞ց ժամանակ կգտնենք ամեն ինչ այսքան գեղեցիկ տեսք տալու համար: Վերջնաժամկետները մոտենում են, մենեջերը բարկանում է, արտադրության մեջ արգելափակող կա, և ինձ խնդրում են նստել և գրել ամեն ինչ: Ես ուղղակի հաղորդագրություն կուղարկեմ մշակողին, և վերջ:  Սա տրամաբանական փաստարկ է, որը կարող է առաջանալ։ Ես պատրանքներ չեմ կրում թեստերի կատարյալ աշխարհի մասին, որտեղ բավական ժամանակ է հատկացվում թեստավորմանը, ամեն ինչ ընթանում է ընթացքով, և պահպանվում է մանրակրկիտ և որակյալ փաստաթղթավորում: Ես հասկանում եմ. հաճախ դա ժամանակի ճեղքվածք է, այրվում է... լավ, աչքեր, և ամեն ինչ ժամանակին կատարելու մրցավազք:  Փոքր սխալները սովորաբար կուտակվում են, ավելի շատ ժամանակ են խլում համատեքստի փոփոխության պատճառով և հանգեցնում վատ պրակտիկայի: Եթե մենք սկսենք աստիճանաբար կատարել բարելավումներ և վերահսկել, թե ինչպես են դրանք աշխատում, մենք կկարողանանք ստեղծել գործընթաց, որն ավելի կայուն, ստանդարտացված և կանխատեսելի կլինի բոլոր մասնակիցների համար:  Ծրագրի մենեջերը կհասկանա, թե ինչ է կատարվում արտադրանքի հետ՝ առանց բոլորին թարմացումների ձգելու անհրաժեշտության, մշակողը ստիպված չի լինի փորձարկողից պարզաբանումներ խնդրել վերարտադրման պայմանների վերաբերյալ և չի հեռացնի նրանց փորձարկումից, իսկ շահագրգիռ կողմերը, իրենց հերթին, հստակ պատկերացում ունենալ արտադրանքի առաջընթացի մասին:  Այս հոդվածն ավելի շատ ուղղված է սկսնակների համար, ովքեր սկսում են կամ արդեն սկսել են իրենց ուղին թեստավորման մեջ: Կարծում եմ, որ փոքր քայլերը հանգեցնում են մեծ արդյունքների, և այս հոդվածի առաջարկությունները կհանգեցնեն վրիպակների ավելի բարձր որակի հաշվետվությունների:   Եթե ունեք հարցեր, առաջարկներ, անհամաձայնություններ կամ բողոքներ, ազատ զգալ թողեք դրանք մեկնաբանություններում, ինձ հետաքրքրում է ձեր կարծիքը:

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Այս աուդիոն պատրաստվել է պատմության բնօրինակ լեզվով:

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

About Author

ՄԵԿՆԱԲԱՆՈՒԹՅՈՒՆՆԵՐ

ԿԱԽՎԵԼ ՏԵԳՍԵՐ

ԱՅՍ ՀՈԴՎԱԾԸ ՆԵՐԿԱՅԱՑՎԵԼ Է Մ

Related Stories

Hypernative Bolsters Bitcoin L2 Security as Stacks Ecosystem Gets Real-Time Protection

Toufi Saliba: The Architect Behind HyperCycle's Decentralized Network of AI

HyperCycle Announces Strategic Split into Two Distinct Operations

HyveDA Secures $50 Million in Pre-Deposits After Symbiotic Mainnet Launch

Hypernative Bolsters Bitcoin L2 Security as Stacks Ecosystem Gets Real-Time Protection

Toufi Saliba: The Architect Behind HyperCycle's Decentralized Network of AI

HyperCycle Announces Strategic Split into Two Distinct Operations

HyveDA Secures $50 Million in Pre-Deposits After Symbiotic Mainnet Launch

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps