Sifat uchun kim javobgar?

Hey Xabr!

Bizda yangi muhim mavzu – IT-mahsulotlarni sifatli ishlab chiqish. HighLoad++ da biz tez-tez band xizmatlarni qanday tez qilish haqida gapiramiz, Frontend Confda esa sekinlashmaydigan ajoyib foydalanuvchi interfeysi haqida gapiramiz. Bizda muntazam ravishda test haqida, DevOpsConf esa turli jarayonlarni, jumladan, testlarni birlashtirish haqida mavzularga ega. Ammo umuman sifatni nima deb atash mumkinligi va u bilan qanday qilib har tomonlama ishlash kerakligi haqida - yo'q.

Keling, buni tuzatamiz QualityConf — biz rivojlanishning har bir bosqichida foydalanuvchi uchun yakuniy mahsulot sifati haqida fikr yuritish madaniyatini rivojlantiramiz. O'zingizning mas'uliyat sohangizga e'tibor bermaslik va sifatni nafaqat sinovchilar bilan bog'lash odati.

Kesish ostida biz dastur qo'mitasi rahbari, Tinkoff.Business test bo'limi rahbari, rus tilida so'zlashuvchi QA hamjamiyatining yaratuvchisi bilan gaplashamiz. Anastasiya Aseeva-Nguyen QA sanoatining holati va yangi konferentsiyaning vazifasi haqida.

Sifat uchun kim javobgar?

- Salom Nastya. Iltimos, o'zingiz haqingizda gapirib bering.

Sifat uchun kim javobgar?Anastasiya: Men bankda testlarni boshqaraman, men juda katta jamoa uchun mas'ulman - biz 90 dan ortiq odammiz. Bizda muhim biznes yo'nalishi bor, biz yuridik shaxslar uchun ekotizim uchun javobgarmiz.

Men mexanika va matematikani o'rgandim va dastlab dasturchi bo'lishni xohlardim. Ammo menga qiziqarli taklif tushganida, men o'zimni tester sifatida sinab ko'rishga qaror qildim. G'alati, bu mening chaqiruvim bo'lib chiqdi. Endi men barcha ishlarimni shu sohada ko'raman.

Men Sifat kafolati intizomining ashaddiy tarafdoriman. Men qanday mahsulotlar yaratilishi, kompaniyada, jamoada va, qoida tariqasida, ishlab chiqish jarayonida sifatga qanday munosabatda bo'lishlariga befarq emasman.

Bu menga ayon bu yo‘nalishdagi jamiyat yetarlicha etuk emas, hech bo'lmaganda Rossiyada. Biz har doim ham sifat kafolati nafaqat arizani talablarga muvofiqligini tekshirish haqiqati ekanligini tushunmaymiz. Men bu vaziyatni o'zgartirmoqchiman.

— Sifat kafolati va test so‘zlarini ishlatasiz. Oddiy odamning nazarida bu ikki atama ko'pincha bir-biriga mos keladi. Agar siz chuqur qazsangiz, ular qanday farq qiladi?

Anastasiya: Aksincha, ular hech qanday farq qilmaydi. Sinov sifat kafolati intizomining bir qismidir; bu to'g'ridan-to'g'ri faoliyat - men nimanidir sinab ko'rayotganimning o'zi. Haqiqatdan ham test turlari juda ko'p va har xil turdagi testlar uchun turli odamlar mas'uldir. Ammo bu erda Rossiyada kompaniyalarga testerlarni etkazib beradigan autsorserlar to'lqini paydo bo'lganda, testlar bitta turga qisqartirildi.

Aksariyat hollarda ular faqat funktsional testlar bilan cheklanadi: ular ishlab chiquvchilar kodlagan narsa spetsifikatsiyaga mos kelishini tekshiradilar va tamom.

— Ayting-chi, sifatni taʼminlash boʻyicha yana qanday fanlar bor? Bu erda sinovdan tashqari yana nima bor?

Anastasiya: Sifat kafolati, birinchi navbatda, sifatli mahsulot yaratishdir. Ya'ni, mahsulotimiz qanday sifat xususiyatlariga ega bo'lishi kerakligini o'zimizga so'raymiz. Shunga ko'ra, agar biz buni tushunsak, biz ushbu sifat atributlariga kim ta'sir qilishini solishtirishimiz mumkin. Muhim emas, ishlab chiquvchi, loyiha menejeri yoki mahsulot mutaxassisi mahsulotning rivojlanishiga, uning orqada qolishi va strategiyasiga ta'sir qiluvchi shaxs.

Sinovchi o'z rolini ko'proq anglaydi. Uning vazifasi nafaqat talablarga muvofiqligini sinab ko'rish, balki talablarni sinab ko'rish, mahsulot mutaxassisidan keladigan formulalarni shubha ostiga qo'yish va mijozning barcha yashirin talablari va umidlarini ochib berish ekanligini tushunadi. Mijozimizga yangi funksiyalarni taqdim etganimizda, biz ularning umidlarini chinakam qondirishimiz va ularning dardini hal qilishimiz kerak. Agar biz sifatning barcha atributlari haqida o'ylaydigan bo'lsak, mijoz mamnun bo'ladi va u mahsulotidan foydalanadigan kompaniya haqiqatan ham uning manfaatlariga g'amxo'rlik qilishini va "shunchaki xususiyatni chiqarish uchun" tamoyili bo'yicha ishlamasligini tushunadi.

— Siz ta’riflagan narsa mahsulot mutaxassisining vazifasiga o‘xshaydi. Bu, qoida tariqasida, sinov haqida emas, balki sifat haqida ham emas - bu umuman mahsulotni boshqarish haqida, shunday emasmi?

Anastasiya: Shu jumladan. Sifatni ta'minlash - bu aniq bir shaxs javobgar bo'lgan intizom emas. Endi testda mashhur yo'nalish mavjud, deb nomlangan yondashuv Agile testi. Uning ta'rifi aniq aytilishicha, bu ma'lum bir amaliyotlar to'plamini o'z ichiga olgan testlarga jamoaviy yondashuv. Ushbu yondashuvni amalga oshirish uchun butun jamoa mas'uldir, hatto jamoada sinovchi bo'lishi shart emas. Butun jamoa mijozga qiymat yetkazib berishga va bu qiymat mijozlar kutganiga mos kelishini ta'minlashga qaratilgan.

— Aniqlanishicha, sifat deyarli barcha atrofdagi fanlar bilan kesishib, atrofdagi hamma narsaga asos soladimi?

Anastasiya: To'g'ri. Sifatli mahsulotni qanday yaratmoqchi ekanligimiz haqida o'ylaganimizda, biz sifatning turli atributlari haqida o'ylay boshlaymiz. Masalan, mijozimizga kerak bo'lgan xususiyatni haqiqatan ham yaratganimizni qanday tekshirish mumkin.

Ushbu turdagi testlar bu erda amalga oshiriladi: UAT (foydalanuvchini qabul qilish testi). Afsuski, u Rossiyada kamdan-kam qo'llaniladi, lekin ba'zida SCRUM jamoalarida oxirgi mijoz uchun demo sifatida mavjud. Bu xorijiy kompaniyalarda keng tarqalgan sinov turi. Funksionallikni barcha mijozlarga ochishdan oldin, biz birinchi navbatda UATni amalga oshiramiz, ya'ni mahsulot haqiqatan ham kutganlarga javob beradimi va og'riqni hal qiladimi yoki yo'qligini tekshiradigan va darhol fikr bildiradigan oxirgi foydalanuvchini taklif qilamiz. Shundan keyingina barcha boshqa mijozlar uchun masshtablash amalga oshiriladi.

Ya'ni, biz biznesga, yakuniy mijozga e'tibor qaratamiz, lekin ayni paytda texnologiya haqida unutmang. Mahsulot sifati ham ko'p jihatdan texnologiyaga bog'liq. Agar bizda yomon arxitektura bo'lsa, biz xususiyatlarni tezda chiqara olmaymiz va mijozlar talablarini qondira olmaymiz. O'lchovni o'tkazishga urinayotganda juda ko'p xatolar bo'lishi mumkin yoki qayta tiklashga urinishda biz biror narsani buzishimiz mumkin. Bularning barchasi mijozlar ehtiyojini qondirishga ta'sir qiladi.

Shu nuqtai nazardan qaraganda, arxitektura shunday bo'lishi kerakki, biz tezda o'zgartirishlar kiritishimizga va hamma narsani buzishimizdan qo'rqmaslikka imkon beradigan toza kod yozishimiz mumkin. Bizda juda ko'p meros borligi sababli qayta ko'rib chiqish iteratsiyalari bir necha oyga cho'zilmaydi va biz uzoq sinov bosqichlarini bajarishimiz kerak.

— Umuman olganda, ishlab chiquvchilar, arxitektorlar, mahsulot olimlari, mahsulot menejerlari va sinovchilarning o'zlari allaqachon ishtirok etishgan. Sifatni ta'minlash jarayonida yana kim ishtirok etadi?

Anastasiya: Endi tasavvur qilaylik, biz bu xususiyatni mijozga yetkazib berdik. Shubhasiz, mahsulot sifati allaqachon ishlab chiqarishda ham kuzatilishi kerak. Ushbu bosqichda noaniq stsenariylarga ega bo'lgan vaziyatlar paydo bo'lishi mumkin, bu xatolar deb ataladi.

Birinchi savol shundaki, biz mahsulotni allaqachon chiqarganimizdan keyin bu xatolar bilan qanday kurashishimiz mumkin? Biz, masalan, stressga qanday munosabatda bo'lamiz? Agar sahifani yuklash uchun 30 soniyadan ko'proq vaqt kerak bo'lsa, mijoz juda xursand bo'lmaydi.

Bu erda ekspluatatsiya paydo bo'ladi yoki ular buni hozir deyishadi, DevOps. Darhaqiqat, bular mahsulot ishlab chiqarilayotgan paytda uni ishlatish uchun mas'ul bo'lgan odamlardir. Bunga turli xil monitoring turlari kiradi. Hatto sinovning kichik turi ham mavjud - ishlab chiqarishda sinov, biz o'zimizga biror narsani ishga tushirishdan oldin sinab ko'rmaslikka va uni darhol ishlab chiqarishda sinab ko'rishga ruxsat berganimizda. Bu infratuzilmani tashkil etish nuqtai nazaridan bir qator chora-tadbirlar bo'lib, sizga voqeaga tezda javob berish, unga ta'sir qilish va uni tuzatish imkonini beradi.

Infratuzilma ham muhim ahamiyatga ega. Ko'pincha shunday holatlar mavjudki, sinov paytida biz mijozga berishni xohlagan hamma narsaga ega ekanligimizga ishonch hosil qilishning iloji bo'lmaydi. Biz uni ishlab chiqarishga chiqaramiz va noaniq vaziyatlarni ushlay boshlaymiz. Va barchasi, chunki sinovdagi infratuzilma ishlab chiqarishdagi infratuzilmaga mos kelmaydi. Bu testning yangi turiga olib keladi - infratuzilmani sinovdan o'tkazish. Bular turli xil konfiguratsiyalar, sozlamalar, ma'lumotlar bazasini ko'chirish va boshqalar.

Bu savolni tug'diradi - ehtimol jamoa infratuzilmani kod sifatida ishlatishi kerak.

Men infratuzilma mahsulot sifatiga bevosita ta'sir qiladi, deb hisoblayman.

Umid qilamanki, konferentsiyada haqiqiy ish bilan hisobot bo'ladi. Infratuzilma kod sifatida sifatga qanday ta'sir qilishini o'z tajribangizdan aytib berishga tayyor bo'lsangiz, bizga yozing. Kod sifatida infratuzilma barcha sozlamalarni tekshirishni va aks holda imkonsiz bo'lgan narsalarni sinab ko'rishni osonlashtiradi. Shu sababli, sifatli mahsulotni ishlab chiqish jarayonida operatsiya ham ishtirok etadi.

— Tahlil va hujjatlar haqida nima deyish mumkin?

Anastasiya: Bu ko'proq korporativ tizimlarga tegishli. Korxona haqida gapirganda, tahlilchilar va tizim tahlilchilari kabi odamlar darhol yodga keladi. Ular ba'zan texnik yozuvchilar deb ataladi. Ular spetsifikatsiyani yozish va uni bajarish uchun topshiriq oladi, masalan, bir oy.

Bir necha bor isbotlanganki, bunday hujjatlarni yozish juda uzoq rivojlanish iteratsiyasiga va uzoq vaqt takomillashtirish iteratsiyasiga olib keladi, chunki sinov jarayonida xatolar aniqlanadi va qaytish boshlanadi. Natijada, rivojlanish xarajatlarini oshiradigan ko'plab halqalar mavjud. Bundan tashqari, bu zaifliklarni keltirib chiqarishi mumkin. Biz mos yozuvlar kodini yozganga o'xshaymiz, lekin keyin biz mukammal o'ylangan arxitekturani buzadigan o'zgarishlar kiritdik.

Yakuniy natija butunlay yuqori sifatli mahsulot emas, chunki arxitekturada yamalar allaqachon paydo bo'lgan, ba'zi joylarda kod testlar bilan etarli darajada qamrab olinmagan, chunki muddatlar tugaydi, barcha xatolar tezda yopilishi kerak. Va barchasi, chunki asl spetsifikatsiya amalga oshirilishi kerak bo'lgan barcha fikrlarni hisobga olmagan.

Ishlab chiquvchilar zararkunandalar emas va ataylab xatolar bilan kod yozmaydilar.

Agar biz dastlab barcha kerakli fikrlarni qamrab oladigan spetsifikatsiyani o'ylab ko'rganimizda, hamma narsa kerak bo'lganda amalga oshirilgan bo'lar edi. Ammo bu utopiya.

100 betlik mukammal spetsifikatsiyani yozish mumkin emas. Shunung uchun hujjatlarni yozishning muqobil usullari haqida o'ylash kerak, spetsifikatsiyalar, bizni ishlab chiquvchi kerakli narsani bajarishini ta'minlashga yaqinlashtiradigan vazifalarni belgilash.

Bu erda Agile-dan yondashuvlar yodga tushadi - qabul qilish mezonlari bilan foydalanuvchi hikoyalari. Bu kichik iteratsiyalarda rivojlanadigan jamoalar uchun ko'proq qo'llaniladi.

— Yaroqlilik sinovi, mahsulotning qulayligi, dizayn haqida nima deyish mumkin?

Anastasiya: Bu juda muhim nuqta, chunki jamoada dizaynerlar bor. Ko'pincha dizaynerlar xizmat sifatida ishlatiladi - dizayn bo'limi yoki autsorsing dizayneri tomonidan. Ko'pincha dizayner mahsulot mutaxassisini tinglagan va o'zi tushungan narsani qilgandek tuyuladigan holatlar mavjud. Ammo biz iteratsiyani boshlaganimizda, aslida qilingan narsa kutilgan narsa emasligi ma'lum bo'ldi: dizayner nimanidir unutgan, xatti-harakati haqida to'liq o'ylamagan, chunki u jamoada emas va kontekstda yoki old tomonda emas. -end dasturchi uning tartibini to'liq tushunmagan. Front-end ishlab chiqaruvchisi dizaynni tushunishi bilan bog'liq muammo bo'lganligi sababli bir nechta iteratsiya talab qilinishi mumkin.

Bundan tashqari, yana bir muammo bor. Dizayn tizimlari endi mashhurlikka erishmoqda. Ular shov-shuvli, ammo ularning foydalari unchalik aniq emas.

Dizayn tizimlari, bir tomondan, rivojlanishni soddalashtiradi, lekin boshqa tomondan, ular interfeysga juda ko'p cheklovlar qo'yadi, degan fikrga duch kelaman.

Natijada, biz mijoz xohlagan xususiyatni emas, balki biz uchun qulay bo'lgan xususiyatni yaratamiz, chunki bizda allaqachon buni qilishimiz mumkin bo'lgan ma'lum kublar mavjud.

Menimcha, bu ko'rib chiqishga arziydigan mavzu va dizaynni osonlashtirishga urinishda biz mijozning og'riqli nuqtasini hal qilyapmizmi, deb o'ylayman.

- Sifat kafolati bilan bog'liq hayratlanarli mavzular mavjud. Rossiyada ularning hammasi muhokama qilinadigan konferentsiya bormi?

Anastasiya: Bu yil 25-marta bo'lib o'tadigan va SQA Days Sifat kafolati konferentsiyasi deb ataladigan eng qadimgi sinov konferentsiyasi mavjud. U asosan funktsional testerlar uchun vositalar va maxsus test yondashuvlarini muhokama qiladi. Qoidaga ko'ra, SQA kunlaridagi hisobotlarda sinovchilarning o'zlari mas'uliyat sohasidagi aniq yo'nalishlar chuqur o'rganiladi, ammo murakkab faoliyat emas.

Bu turli xil vositalar va yondashuvlarni, ma'lumotlar bazalarini, API'larni va hokazolarni qanday sinab ko'rishni tushunishda ko'p yordam beradi. Ammo, shu bilan birga, bir tomondan, bu yaxshi mahsulotni yaratishda shunchaki sinovdan ko'proq narsani jalb qilishga undamaydi. Boshqa tomondan, testerlar mahsulotning global maqsadi va uning biznes tarkibiy qismi haqida o'ylash jarayonida ko'proq ishtirok etmaydilar.

Men katta bo'limni boshqaraman va umuman sanoatning holati haqida ma'lumot beradigan ko'plab intervyular o'tkazaman. Qoidaga ko'ra, bizning yigitlarimiz korxonalarda ishlaydi va ularning mas'uliyati aniq. Xorijiy loyihalarda ishlaydigan hamkasblar har xil turdagi testlardan foydalanadilar: ular o'zlari yuk testini, ishlash testini va hatto ba'zan xavfsizlik testlarini o'tkazishi mumkin, chunki ular haqiqatan ham jamoaga mahsulot sifatini ta'minlashga yordam beradi.

Men Rossiyadagi yigitlar ham sanoat funktsional testlar bilan tugamaydi deb o'ylashni istardim.

— Shu maqsadda biz sifatga ajralmas fan sifatida bag‘ishlangan QualityConf yangi konferensiyasini tashkil qilmoqdamiz. G‘oya haqida to‘liqroq gapirib bersangiz, anjumandan ko‘zlangan asosiy maqsad nima?

Anastasiya: Biz sifatli mahsulotlar ishlab chiqarishga qiziqqan odamlar jamoasini yaratmoqchimiz. Ular kelishlari, hisobotlarni tinglashlari va konferentsiyadan keyin sifatni yaxshilash uchun nimani o'zgartirish kerakligini aniq tushunib, ketishlari mumkin bo'lgan platformani taklif qiling.

Bugungi kunda men tez-tez konsaltingdan test va sifat bilan bog'liq muammolar mavjud bo'lganda nima qilish kerakligi haqida so'rovni eshitaman. Jamoalar bilan muloqot qilishni boshlaganingizda, muammo testerlarning o'zida emas, balki jarayon qanday tuzilganida ekanligini ko'rasiz. Misol uchun, ishlab chiquvchilar faqat kod yozish uchun mas'ul deb hisoblaganlarida, ularning mas'uliyati topshiriqni testga topshirgan paytda tugaydi.

Yomon arxitekturaga ega yomon yozilgan, past sifatli kod loyiha uchun katta muammolarga tahdid solishi haqida hamma ham o'ylamaydi. Ular xatolarning narxi haqida o'ylamaydilar, ishlab chiqarishda tugaydigan xatolar kompaniya va jamoa uchun katta xarajatlarga olib kelishi mumkin. Bu haqda o'ylash uchun madaniyat yo'q. Konferentsiyada tarqatishni boshlashimizni xohlayman.

Men bu yangilik emasligini tushunaman.Sifatning 14 ta qoidasi muallifi Edvard Deming o‘tgan asrda xatoning narxi haqida yozgan edi. Sifat kafolati intizom sifatida ushbu kitobga asoslanadi, ammo, afsuski, zamonaviy rivojlanish buni unutadi.

— Test va vositalar haqida toʻgʻridan-toʻgʻri mavzularga toʻxtalishni rejalashtiryapsizmi?

Anastasiya: Tan olaman, asboblar haqida hisobotlar bo'ladi. Kompaniyalar va jamoalar mahsulotga ta'sir qilishi mumkin bo'lgan juda universal vositalar mavjud.

Barcha hisobotlar global miqyosda bitta umumiy vazifa bilan birlashtiriladi: auditoriyaga ushbu yondashuv, vosita, usul, jarayon, sinov turi yordamida mahsulot sifatiga ta'sir qilganimizni va mijozning hayotini yaxshilaganimizni etkazish.

Bizda, albatta, vosita uchun vosita haqida xabarlar bo'lmaydi. Dasturga kiritilgan barcha hisobotlarni yagona maqsad birlashtiradi.

— Nima haqida gapirayotganingiz, kimlarni anjuman mehmoni sifatida ko‘rayotganingiz kimga qiziq bo‘ladi?

Anastasiya: O'z loyihasi, mahsuloti, tizimining taqdiri haqida qayg'uradigan ishlab chiquvchilar uchun hisobotlarimiz bo'ladi. Xuddi shunday, bu testerlar va menimcha, ayniqsa menejerlar uchun qiziqarli bo'ladi. Menejerlar deganda men qaror qabul qiladigan va mahsulot, tizim, jamoaning taqdiri va rivojlanishiga ta'sir ko'rsatadigan odamlarni nazarda tutyapman.

Bu mahsulot yoki tizim sifatini qanday yaxshilashni qiziqtirgan odamlardir. Bizning konferentsiyamizda ular turli xil chora-tadbirlar to'plami bilan tanishadilar va ularda nima noto'g'ri ekanligini va nimani o'zgartirish kerakligini tushunishlari mumkin.

Menimcha, asosiy mezon - sifatda nimadir noto'g'ri ekanligini tushunish va unga ta'sir qilishni xohlash. Buni birinchi marta amalga oshiradi, deb o'ylaydigan odamlar bilan bog'lana olmaymiz.

— Sizningcha, butun sanoat nafaqat sinov, balki sifat madaniyati haqida gapirishga tayyormi?

Anastasiya: Menimcha, men etuk bo'ldim. Endi ko'plab kompaniyalar Agile tomon an'anaviy sharshara yondashuvidan voz kechishmoqda. Mijozlarga e'tibor qaratiladi, jamoalardagi odamlar haqiqatan ham sifatli mahsulotni qanday yaratish haqida o'ylashni boshlaydilar. Hatto korxona kompaniyalari ham sifatni yaxshilashga e'tibor qaratmoqda.

Jamiyatda paydo bo'layotgan so'rovlar soniga qarab, vaqt keldi, deb o'ylayman. Albatta, bu keng ko'lamli inqilob bo'lishiga ishonchim komil emas, lekin men bu ongda inqilob sodir bo'lishini istardim.

- Kelishilgan! Biz madaniyatni singdiramiz va ongni o'zgartiramiz.

IT-mahsulotlarni yuqori sifatli rivojlantirish bo'yicha konferentsiya QualityConf amalga oshiriladi 7 iyun kuni Moskvada. Yuqori sifatli mahsulotni qaysi bosqichlar tashkil etishini bilasiz, bizda ishlab chiqarishdagi xatolar bilan muvaffaqiyatli kurashgan holatlar mavjud, biz amaliyotimizda mashhur usullarni sinab ko'rdik - bizga sizning tajribangiz kerak. Yuborish ularning arizalar 1-maygacha, va Dastur qo'mitasi konferentsiyaning umumiy yaxlitligi uchun mavzuni yo'naltirishga yordam beradi.

ga ulaning suhbat, unda biz sifat masalalari va konferentsiyani muhokama qilamiz, obuna bo'lamiz Telegram kanalidastur yangiliklaridan xabardor bo'lish.

Manba: www.habr.com

a Izoh qo'shish