Ո՞վ է պատասխանատու որակի համար:

Հե՜յ Հաբր։

Մենք ունենք նոր կարևոր թեմա՝ ՏՏ արտադրանքի որակյալ զարգացում։ HighLoad++-ում մենք հաճախ խոսում ենք այն մասին, թե ինչպես արագ դարձնել զբաղված ծառայությունները, իսկ Frontend Conf-ում մենք խոսում ենք հաճելի ինտերֆեյսի մասին, որը չի դանդաղեցնում: Մենք պարբերաբար թեմաներ ունենք թեստավորման մասին, և DevOpsConf-ը՝ տարբեր գործընթացների, ներառյալ թեստավորման, համադրման մասին: Բայց այն մասին, թե ընդհանրապես ինչ կարելի է որակել, և ինչպես համակողմանիորեն աշխատել դրա վրա՝ ոչ։

Եկեք սա շտկենք QualityConf — մշակման յուրաքանչյուր փուլում օգտագործողի համար վերջնական արտադրանքի որակի մասին մտածելու մշակույթ կզարգացնենք: Ձեր պատասխանատվության ոլորտի վրա չկենտրոնանալու սովորությունը և որակը ոչ միայն փորձարկողների հետ կապելը:

Կտրվածքի տակ մենք կխոսենք ծրագրի հանձնաժողովի ղեկավարի, Tinkoff.Business-ի թեստավորման ղեկավարի, ռուսալեզու QA համայնքի ստեղծողի հետ: Անաստասիա Ասեևա-Նգուեն QA արդյունաբերության վիճակի և նոր համաժողովի առաքելության մասին։

- Նաստիա բարև: Խնդրում եմ պատմեք ձեր մասին:

АнастасияԵս ղեկավարում եմ թեստավորումը բանկում, ես պատասխանատու եմ շատ մեծ թիմի համար. մենք ավելի քան 90 հոգի ենք: Մենք ունենք կարևոր բիզնես գիծ, ​​մենք պատասխանատու ենք իրավաբանական անձանց էկոհամակարգի համար։

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

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

Ինձ համար դա ակնհայտ է համայնքն այս ուղղությամբ բավականաչափ հասուն չէ, համենայն դեպս Ռուսաստանում։ Մենք միշտ չէ, որ հասկանում ենք, որ որակի ապահովումը ոչ միայն հայտի պահանջներին համապատասխանության փորձարկման փաստն է: Ես կցանկանայի փոխել այս իրավիճակը։

— Դուք օգտագործում եք Որակի ապահովում և թեստավորում բառերը: Սովորական մարդու աչքում այս երկու տերմինները շատ հաճախ համընկնում են: Ինչպե՞ս են դրանք տարբերվում, եթե խորը փորեք:

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

Շատ դեպքերում դրանք սահմանափակվում են միայն ֆունկցիոնալ փորձարկումներով. նրանք ստուգում են, որ այն, ինչ մշակողները կոդավորել են, համապատասխանում է ճշգրտմանը և վերջ:

- Խնդրում եմ, ասեք մեզ, թե որակի ապահովման ի՞նչ այլ առարկաներ կան: Ուրիշ ի՞նչ, բացի թեստավորումից, ներառված է այստեղ:

АнастасияՈրակի ապահովումն առաջին հերթին որակյալ արտադրանք ստեղծելն է: Այսինքն՝ մենք ինքներս մեզ հարցնում ենք, թե ինչ որակի հատկանիշներ պետք է ունենա մեր ապրանքը։ Համապատասխանաբար, եթե մենք դա հասկանանք, կարող ենք համեմատել, թե ով է ազդում այս որակի հատկանիշների վրա: Կարևոր չէ, մշակող, ծրագրի ղեկավար կամ արտադրանքի մասնագետ անձ է, ով ազդում է արտադրանքի զարգացման, դրա հետաձգվածության և ռազմավարության վրա:

Փորձարկողն ավելի գիտակցում է իր դերը: Նա հասկանում է, որ իր խնդիրն է ոչ միայն ստուգել պահանջների համապատասխանությունը, այլ նաև պահանջները ստուգել, ​​կասկածի տակ դնել արտադրանքի մասնագետի կողմից ստացված ձևակերպումները և բացահայտել հաճախորդի բոլոր անուղղակի պահանջներն ու ակնկալիքները: Երբ մենք նոր գործառույթներ ենք մատուցում մեր հաճախորդին, մենք պետք է իսկապես արդարացնենք նրանց սպասելիքները և լուծենք նրանց ցավը: Եթե ​​մտածենք որակի բոլոր ատրիբուտների մասին, հաճախորդը գոհ կմնա և կհասկանա, որ այն ընկերությունը, որի արտադրանքը նա օգտագործում է, իսկապես մտածում է իր շահերի մասին և չի աշխատում «միայն հատկանիշը թողարկելու» սկզբունքով։

— Թվում է, թե ձեր նկարագրածը ապրանքի մասնագետի խնդիրն է։ Սա, սկզբունքորեն, թեստավորման և որակի մասին չէ, ընդհանրապես արտադրանքի կառավարման մասին է, չէ՞:

Анастасия: Այդ թվում. Որակի ապահովումը կարգապահություն չէ, որի համար պատասխանատու է մեկ կոնկրետ անձ: Հիմա կա թեստավորման հանրաճանաչ ուղղություն, որը կոչվում է մոտեցում Արագաշարժ փորձարկում. Նրա սահմանման մեջ հստակ ասվում է, որ սա թեստավորման թիմային մոտեցում է, որը ներառում է որոշակի պրակտիկա: Ամբողջ թիմը պատասխանատու է այս մոտեցման իրականացման համար, նույնիսկ պարտադիր չէ, որ թիմում լինի փորձարկող: Ողջ թիմը կենտրոնացած է հաճախորդին արժեք մատուցելու և հաճախորդների սպասելիքները բավարարելու վրա:

— Ստացվում է, որ որակը հատվում է գրեթե բոլոր շրջապատող առարկաների հետ՝ շրջանակներ տալով շրջապատող ամեն ինչին։

Анастасия: Ճիշտ. Երբ մենք մտածում ենք, թե ինչպես ենք ուզում ստեղծել որակյալ արտադրանք, մենք սկսում ենք մտածել որակի տարբեր հատկանիշների մասին: Օրինակ՝ ինչպես ստուգել, ​​որ մենք իսկապես ստեղծել ենք այն գործառույթը, որն անհրաժեշտ է մեր հաճախորդին:

Ահա թե որտեղ է այս տեսակի թեստավորումը. UAT (օգտագործողի ընդունման թեստավորում): Ցավոք սրտի, այն հազվադեպ է կիրառվում Ռուսաստանում, բայց երբեմն առկա է SCRUM թիմերում՝ որպես վերջնական հաճախորդի ցուցադրություն: Սա արտասահմանյան ընկերություններում թեստավորման բավականին տարածված տեսակ է: Նախքան ֆունկցիոնալությունը բացելը բոլոր հաճախորդների համար, մենք նախ անում ենք UAT, այսինքն՝ հրավիրում ենք վերջնական օգտագործողին, ով փորձարկում է և անմիջապես արձագանքում է. Միայն դրանից հետո է տեղի ունենում մասշտաբավորում բոլոր մյուս հաճախորդների համար:

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

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

— Ընդհանուր առմամբ, արդեն ներգրավված են մշակողները, ճարտարապետները, արտադրանքի գիտնականները, արտադրանքի մենեջերները և փորձարկողները: Էլ ո՞վ է ներգրավված որակի ապահովման գործընթացում:

АнастасияՀիմա եկեք պատկերացնենք, որ մենք արդեն տրամադրել ենք գործառույթը հաճախորդին: Ակնհայտ է, որ ապրանքի որակը պետք է վերահսկվի նույնիսկ այն ժամանակ, երբ այն արդեն արտադրվում է: Այս փուլում կարող են հայտնվել ոչ ակնհայտ սցենարներով իրավիճակներ, այսպես կոչված, սխալներ:

Առաջին հարցն այն է, թե ինչպես ենք մենք վարվում այս սխալների հետ այն բանից հետո, երբ մենք արդեն թողարկել ենք արտադրանքը: Ինչպե՞ս ենք մենք, օրինակ, արձագանքում սթրեսին: Հաճախորդն այնքան էլ ուրախ չի լինի, եթե էջը բեռնելու համար տևի ավելի քան 30 վայրկյան:

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

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

Սա հարց է առաջացնում. գուցե թիմը պետք է օգտագործի ենթակառուցվածքը որպես կոդ:

Կարծում եմ, որ ենթակառուցվածքներն ուղղակիորեն ազդում են արտադրանքի որակի վրա։

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

-Ի՞նչ կասեք վերլուծության և փաստաթղթերի մասին:

АнастасияՍա ավելի շատ վերաբերում է ձեռնարկությունների համակարգերին: Երբ մենք խոսում ենք ձեռնարկության մասին, մարդիկ, ինչպիսիք են վերլուծաբանները և համակարգերի վերլուծաբանները, անմիջապես գալիս են մտքում: Նրանց երբեմն անվանում են տեխնիկական գրողներ։ Նրանք հանձնարարություն են ստանում գրել հստակեցում և լրացնել այն, օրինակ, մեկ ամսով։

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

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

Մշակողները վնասատու չեն և դիտմամբ սխալներով կոդ չեն գրում:

Եթե ​​մենք ի սկզբանե մտածեինք հստակեցման միջոցով, որը կներառեր բոլոր անհրաժեշտ կետերը, ապա ամեն ինչ կիրականացվեր ճիշտ այնպես, ինչպես անհրաժեշտ էր: Բայց սա ուտոպիա է։

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

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

— Ի՞նչ կասեք օգտագործելիության փորձարկման, արտադրանքի օգտագործման, դիզայնի մասին:

АнастасияՍա շատ կարևոր կետ է, քանի որ թիմում կան դիզայներներ: Ամենից հաճախ դիզայներներն օգտագործվում են որպես ծառայություն՝ կա՛մ դիզայնի բաժնի կողմից, կա՛մ աութսորսսված դիզայների կողմից: Հաճախ լինում են իրավիճակներ, երբ թվում է, թե դիզայները լսել է արտադրանքի մասնագետին և արել է այն, ինչ նա հասկացել է։ Բայց երբ սկսում ենք կրկնությունը, պարզվում է, որ այն, ինչ իրականում արվել է, այն չէր, ինչ ակնկալվում էր. դիզայները մոռացել է ինչ-որ բան, ամբողջությամբ չի մտածել վարքի մասին, քանի որ նա թիմում չէ, համատեքստում կամ առջևում չէ: -end մշակողը լիովին չի հասկացել դրա դասավորությունը: Այն կարող է մի քանի կրկնություններ պահանջել միայն այն պատճառով, որ դիզայնը հասկանալու առաջնային ծրագրավորողի հետ խնդիր կա:

Բացի այդ, կա ևս մեկ խնդիր. Դիզայնի համակարգերը այժմ դառնում են ժողովրդականություն: Նրանք հիացմունքի մեջ են, բայց դրանցից օգուտները լիովին ակնհայտ չեն:

Հանդիպում եմ այն ​​կարծիքին, որ դիզայներական համակարգերը մի կողմից պարզեցնում են զարգացումը, բայց մյուս կողմից ինտերֆեյսի վրա շատ սահմանափակումներ են դնում։

Արդյունքում մենք պատրաստում ենք ոչ թե հաճախորդի ուզած ֆունկցիան, այլ այն, որը հարմար է մեզ, քանի որ մենք արդեն ունենք որոշակի խորանարդներ, որոնցից կարող ենք այն պատրաստել։

Կարծում եմ, որ սա մի թեմա է, որի վրա արժե նայել և մտածել, թե արդյոք դիզայնը հեշտացնելու փորձի մեջ մենք իրականում լուծում ենք հաճախորդի ցավի կետը:

— Որակի ապահովման հետ կապված զարմանալի թվով թեմաներ կան: Ռուսաստանում կա՞ կոնֆերանս, որտեղ բոլորը կարելի է քննարկել։

АнастасияԿա ամենահին թեստավորման համաժողովը, որն այս տարի կանցկացվի 25-րդ անգամ և կոչվում է SQA Days Quality Assurance Conference: Այն հիմնականում քննարկում է գործիքները և հատուկ փորձարկման մոտեցումները ֆունկցիոնալ փորձարկողների համար: Որպես կանոն, SQA Days-ի հաշվետվությունները խորապես ուսումնասիրում են կոնկրետ ոլորտները հենց փորձարկողների պատասխանատվության ոլորտում, բայց ոչ բարդ գործունեությունը:

Սա շատ է օգնում հասկանալու տարբեր գործիքներ և մոտեցումներ, ինչպես փորձարկել տվյալների բազաները, API-ները և այլն: Բայց միևնույն ժամանակ, մի կողմից, դա չի դրդում ավելի լավ արտադրանքի ստեղծմանը ներգրավել ավելին, քան պարզապես փորձարկումը: Մյուս կողմից, փորձարկողներն ավելի չեն ներգրավվում գործընթացում՝ մտածելու ապրանքի գլոբալ նպատակի և դրա բիզնես բաղադրիչի մասին:

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

Ես կցանկանայի, որ Ռուսաստանի տղաները նույնպես սկսեն մտածել, որ արդյունաբերությունը չի ավարտվում ֆունկցիոնալ փորձարկումներով:

— Այդ նպատակով մենք կազմակերպում ենք նոր կոնֆերանս՝ QualityConf, որը նվիրված է որակին՝ որպես անբաժանելի դիսցիպլինա։ Կպատմե՞ք ավելին գաղափարի մասին, ո՞րն է համաժողովի հիմնական նպատակը։

АнастасияՄենք ցանկանում ենք ստեղծել մարդկանց համայնք, որը հետաքրքրված է որակյալ ապրանքների պատրաստմամբ: Առաջարկեք հարթակ, որտեղ նրանք կարող են գալ, լսել զեկույցներ և հեռանալ համաժողովից հետո՝ հստակ հասկանալով, թե ինչ է պետք փոխել որակը բարելավելու համար:

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

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

Ես հասկանում եմ, որ սա նորամուծություն չէ: Էդվարդ Դեմինգը, որակի 14 դրույթների հեղինակը, գրել է սխալի արժեքի մասին դեռ անցյալ դարում: Որակի ապահովումը որպես դիսցիպլին հիմնված է այս գրքի վրա, բայց, ցավոք, ժամանակակից զարգացումը մոռանում է դրա մասին:

— Նախատեսու՞մ եք ուղղակիորեն շոշափել թեստավորման և գործիքների վերաբերյալ թեմաներ:

АнастасияԵս ընդունում եմ, որ գործիքների մասին զեկույցներ կլինեն։ Կան բավականին ունիվերսալ գործիքներ, որոնցով ընկերությունները և թիմերը կարող են ազդել արտադրանքի վրա:

Բոլոր զեկույցները համաշխարհային մասշտաբով կմիավորվեն մեկ ընդհանուր առաքելությամբ՝ փոխանցել լսարանին, որ այս մոտեցման, գործիքի, մեթոդի, գործընթացի, թեստավորման տեսակի օգնությամբ մենք ազդել ենք արտադրանքի որակի վրա և բարելավել հաճախորդի կյանքը:

Մենք հաստատ չենք ունենա հաշվետվություններ գործիքի մասին հանուն գործիքի: Ծրագրում ներառված բոլոր զեկույցները կմիավորվեն ընդհանուր նպատակով.

— Ո՞ւմ կհետաքրքրի, թե ինչի մասին է խոսքը, ո՞ւմ եք տեսնում որպես համաժողովի հյուրեր։

АнастасияՄենք կունենանք հաշվետվություններ մշակողների համար, ովքեր մտածում են իրենց նախագծի, արտադրանքի, համակարգի ճակատագրի մասին: Նմանապես, այն կհետաքրքրի թեստավորողներին և, ինձ թվում է, հատկապես մենեջերներին: Մենեջեր ասելով ես նկատի ունեմ մարդկանց, ովքեր որոշումներ են կայացնում և կարող են ազդել նաև արտադրանքի, համակարգի, թիմի ճակատագրի և զարգացման վրա:

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

Կարծում եմ՝ հիմնական չափանիշը հասկանալն է, որ ինչ-որ բան այն չէ որակի հետ և ուզում ես ազդել դրա վրա։ Մենք, հավանաբար, չենք կարողանա հասնել այն մարդկանց, ովքեր կարծում են, որ դա տեղի կունենա հենց առաջին անգամ:

— Ի՞նչ եք կարծում, արդյունաբերությունն ամբողջությամբ պատրաստ է խոսելու ոչ միայն թեստավորման, այլ որակի մշակույթի մասին:

АнастасияԿարծում եմ՝ հասունացել եմ։ Այժմ շատ ընկերություններ հեռանում են ավանդական Waterfall մոտեցումից Agile-ի նկատմամբ: Գոյություն ունի հաճախորդների կենտրոնացում, թիմերում մարդիկ իսկապես սկսում են մտածել, թե ինչպես ստեղծել որակյալ արտադրանք: Նույնիսկ ձեռնարկատիրական ընկերությունները կրկին կենտրոնանում են որակի բարելավման վրա:

Դատելով համայնքում հնչող խնդրանքների քանակից՝ կարծում եմ, որ ժամանակն է։ Ես, իհարկե, վստահ չեմ, որ սա լայնածավալ հեղափոխություն է լինելու, բայց ես կցանկանայի, որ գիտակցության մեջ այս հեղափոխությունը տեղի ունենար։

- Համաձայնեցին! Մենք մշակույթ ենք սերմանելու, գիտակցությունը փոխելու ենք։

Համաժողով՝ նվիրված ՏՏ արտադրանքի բարձրորակ զարգացմանը QualityConf տեղի է ունեցել հունիսի 7-ին Մոսկվայում. Դուք գիտեք, թե որ փուլերն են կազմում բարձրորակ արտադրանքը, մենք ունենք արտադրության մեջ սխալների դեմ հաջողությամբ պայքարելու դեպքեր, մենք մեր պրակտիկայում փորձարկել ենք հանրաճանաչ մեթոդներ. մեզ անհրաժեշտ է ձեր փորձը: Ուղարկել իրենց դիմումները մինչև մայիսի 1-ը, և Ծրագրի հանձնաժողովը կօգնի կենտրոնացնել թեման համաժողովի ընդհանուր ամբողջականության համար:

Միացեք զրուցել, որում քննարկում ենք որակի հարցերը և համաժողովը, բաժանորդագրվեք Telegram ալիքծրագրի նորություններին արդի մնալու համար:

Source: www.habr.com