Ինչպես մոտենալ QA հարցազրույցի չորս ամենատարածված հարցերի կատեգորիային, և ինչպիսին է ուժեղ պատասխանը ամեն մեկի համար։
Որոշ հարցեր QA հարցազրույցներում այնքան հաճախ են հանդիպում, որ նախապես մտածված պատասխան պատրաստելը արժե ծախսած ժամանակը։ Խոսքը գրված պատասխանները անգիր անելու մասին չէ — intervyu-ողները դա սովորաբար նկատում են — այլ լավ պատասխանի ձևը իմանալու մասին, որ ստիպված չլինեք այն ճնշման տակ զրոյից կառուցել։
Այս հոդվածում կանդրադառնանք հարցերի չորս տարածված կատեգորիայի և ամեն մեկին մոտենալու ձևին․
Այս հարցը ստուգում է ձեր գործընթացը, ոչ միայն test case-երի վերջնական ցանկը։ Ուժեղ պատասխանը սկսվում է ֆունկցիայի և դրա պահանջների մասին հստակեցնող հարցերով (intervyu-ողները սովորաբար ուզում են սա տեսնել, ոչ թե բաց թողնել), հետո համակարգված անցնում է test տեսակների միջով՝ functional, negative, boundary և, եթե relevant է, non-functional ասպեկտներ, ինչպիսին է performance-ը կամ accessibility-ը, փոխարենը՝ ուղիղ ցանկի անցնելու։ Բարձրաձայն նկարագրեք ձեր տրամաբանությունը․ «ես կսկսեի հիմնական սցենարից, քանի որ...» ավելի շատ բան է ցույց տալիս, քան լուռ թվարկված case-երը։
Լավ պատասխանը համառոտ ընդգրկում է չորս բան՝ ինչ էր bug-ը, ինչպես եք գտել այն, ինչ ազդեցություն կունենար, եթե դուրս գար production, և ինչպես եք հայտնել այն։ Առաջնահերթություն տվեք bug-ին, որը ցույց է տալիս դատողություն, ոչ միայն ակնհայտին — նուրբ եզրային դեպք, որը նկատել եք ուշադիր թեստավորմամբ, կամ դեպք, երբ ստիպված եք եղել համոզել developer-ին, որ severity-ն ավելի բարձր է, քան նա սկզբում կարծում էր, ավելի ուժեղ տպավորություն է թողնում, քան մի աննշան typo։
Այս հարցերը ստուգում են ձեր հասկացության ճշգրտությունը, ոչ միայն տերմինների անգիր իմացությունը — տարածված զույգերը ներառում են verification vs. validation, smoke vs. sanity testing, և severity vs. priority։ Պատասխանեք ամեն մեկի կարճ, ճշգրիտ սահմանումով, հետո կոնկրետ օրինակով, որը ցույց է տալիս, թե երբ է իրապես կիրառելի ամեն մեկը գործնականում, ոչ թե միայն երկար սահմանումով։
Հարցեր, ինչպիսիք են «խոսեք դեպքի մասին, երբ համաձայն չէիք developer-ի հետ» կամ «ինչպես եք հաղթահարում սեղմ ժամկետները», գնահատում են, թե ինչպես եք աշխատում թիմում, ոչ միայն ինչպես եք թեստավորում ծրագրաշար։ Օգտակար կառուցվածք է համառոտ նկարագրել իրավիճակը, ինչ կոնկրետ եք արել, և ինչ էր արդյունքը, կենտրոնանալով ձեր սեփական գործողությունների ու տրամաբանության վրա, ոչ թե մեղադրելով գործընկերոջը կամ գործընթացը, նույնիսկ իրապես բարդ իրավիճակ նկարագրելիս։
Ինչպես պատրաստվել QA հարցազրույցի
Defect Severity and Priority