Эй Хабр!
Бізде жаңа маңызды тақырып – IT өнімдерінің сапалы дамуы. HighLoad++ бағдарламасында біз бос емес қызметтерді қалай жылдам жасау керектігі туралы жиі айтамыз, ал Frontend Conf-те баяулатпайтын тамаша пайдаланушы интерфейсі туралы сөйлесеміз. Бізде үнемі тестілеу туралы тақырыптар және әртүрлі процестерді, соның ішінде тестілеуді біріктіру туралы DevOpsConf тақырыптары бар. Бірақ жалпы нені сапа деп атауға болады және онымен қалай жан-жақты жұмыс істеу керек - жоқ.
Осы арқылы түзетейік — біз дамудың әрбір кезеңінде пайдаланушы үшін түпкілікті өнімнің сапасы туралы ойлау мәдениетін дамытамыз. Жауапкершілік саласына назар аудармау және сапаны тек тестерлермен байланыстыру әдеті.
Төменде біз бағдарлама комитетінің басшысымен, Tinkoff.Business тестілеу бөлімінің басшысымен, орыстілді QA қауымдастығының құрушысымен сөйлесеміз. Анастасия Асеева-Нгуен QA индустриясының жағдайы және жаңа конференцияның миссиясы туралы.
- Настя, сәлем. Өзіңіз туралы айтып беріңізші.
Анастасия: Мен банкте тестілеуді басқарамын, мен өте үлкен командаға жауаптымын - біз 90-нан астам адамбыз. Бізде маңызды бизнес бағыты бар, біз заңды тұлғалар үшін экожүйеге жауаптымыз.
Мен механика мен математиканы оқыдым және бастапқыда бағдарламашы болғым келді. Бірақ маған қызықты ұсыныс түскенде, мен өзімді тестілеуші ретінде сынап көруді шештім. Бір қызығы, бұл менің шақыруым болып шықты. Қазір осы саладағы барлық жұмысымды көріп отырмын.
Мен Сапаны қамтамасыз ету пәнін табанды түрде ұстанушымын. Мені қандай өнімдердің жасалатыны, компанияда, ұжымда және негізінен әзірлеу процесінде сапаға қалай қарайтыны бей-жай қалдырмайды.
Маған бұл анық бұл бағыттағы қоғам жеткілікті дәрежеде жетілмеген, кем дегенде Ресейде. Біз сапаны қамтамасыз ету тек өтінімнің талаптарға сәйкестігін тексеру фактісі ғана емес екенін түсінбейміз. Мен бұл жағдайды өзгерткім келеді.
— Сапа кепілдігі және тестілеу деген сөздерді қолданасыз. Қарапайым адамның көз алдында бұл екі термин өте жиі қайталанады. Егер сіз терең қазсаңыз, олар қалай ерекшеленеді?
РђРЅР ° стР° СЃРёСЏ: Керісінше, олардың еш айырмашылығы жоқ. Тестілеу сапаны қамтамасыз ету пәнінің бөлігі болып табылады; бұл тікелей әрекет – менің бір нәрсені сынап жатқанымның өзі. Іс жүзінде тестілеудің көптеген түрлері бар және әртүрлі адамдар тестілеудің әртүрлі түрлеріне жауап береді. Бірақ Ресейде компанияларға тестерлерді жеткізетін аутсорсерлердің толқыны пайда болғанда, тестілеу бір түрге қысқарды.
Көп жағдайда олар тек функционалдық тестілеумен шектеледі: олар әзірлеушілер кодтаған нәрсенің спецификацияға сәйкес келетінін тексереді және бұл бәрі.
— Айтыңызшы, сапаны қамтамасыз етудің тағы қандай пәндері бар? Мұнда тестілеуден басқа тағы не кіреді?
Анастасия: Сапаны қамтамасыз ету - бұл ең алдымен сапалы өнім жасау. Яғни, біз өзімізден өніміміздің қандай сапа белгілері болуы керек деп сұраймыз. Тиісінше, егер біз мұны түсінсек, осы сапа атрибуттарына кім әсер ететінін салыстыра аламыз. Маңызды емес, әзірлеуші, жоба менеджері немесе өнім маманы өнімнің дамуына, оның артта қалуына және стратегиясына әсер ететін адам.
Сынақшы өз рөлін жақсырақ сезінеді. Ол оның міндеті тек талаптарға сәйкестігін тексеру ғана емес, сонымен қатар талаптарды сынау, өнім маманынан келетін тұжырымдарға күмән келтіру және клиенттің барлық жасырын талаптары мен күтулерін ашу екенін түсінеді. Тұтынушыға жаңа функционалдылықты жеткізген кезде, біз олардың үміттерін шынымен ақтап, олардың қиындықтарын шешуіміз керек. Сапаның барлық атрибуттары туралы ойланатын болсақ, клиент риза болады және ол өнімін пайдаланатын компания шынымен оның мүдделерін ойлайтынын және «тек мүмкіндікті шығару үшін» принципі бойынша жұмыс істемейтінін түсінеді.
— Жаңа айтып өткеніңіз өнім маманының міндеті сияқты. Бұл, негізінен, тестілеу туралы емес, сапа туралы емес - бұл жалпы өнімді басқару туралы, солай емес пе?
Анастасия: Соның ішінде. Сапаны қамтамасыз ету бір адам жауапты болатын пән емес. Қазір тестілеудің танымал бағыты бар, деп аталатын тәсіл Agile тестілеу. Оның анықтамасында бұл белгілі бір тәжірибелер жиынтығын қамтитын тестілеуге командалық тәсіл екені анық көрсетілген. Бүкіл команда бұл тәсілді енгізуге жауапты, командада тестілеушінің болуы міндетті емес. Бүкіл команда тұтынушыға құнды жеткізуге және бұл құндылықтың тұтынушылардың күтулеріне сәйкес келуін қамтамасыз етуге бағытталған.
— Сапа айналадағы барлық дерлік пәндермен қиылысады, айналаның бәріне бір шеңберді таңады ма?
Анастасия: Дұрыс. Сапалы өнімді қалай жасағымыз келетіні туралы ойлағанда, біз сапаның әртүрлі атрибуттары туралы ойланамыз. Мысалы, біздің клиентке қажет мүмкіндікті шынымен жасағанымызды қалай тексеруге болады.
Бұл жерде тестілеудің бұл түрі кіреді: UAT (пайдаланушыны қабылдау сынағы). Өкінішке орай, ол Ресейде сирек қолданылады, бірақ кейде SCRUM командаларында соңғы клиент үшін демонстрация ретінде болады. Бұл шетелдік компанияларда жиі кездесетін тестілеу түрі. Функционалдылықты барлық клиенттерге ашпас бұрын, біз алдымен UAT жасаймыз, яғни өнім шынымен үміттерді қанағаттандырады ма және ауруды шешеді ме, жоқ па, тестілеуден өткізетін және дереу кері байланыс беретін соңғы пайдаланушыны шақырамыз. Осыдан кейін ғана барлық басқа клиенттерге масштабтау орын алады.
Яғни, біз бизнеске, соңғы клиентке назар аударамыз, бірақ сонымен бірге технология туралы ұмытпаңыз. Өнімнің сапасы технологияға да байланысты. Егер бізде архитектура нашар болса, біз мүмкіндіктерді жылдам шығара алмаймыз және тұтынушылардың үміттерін қанағаттандыра алмаймыз. Масштабтауға тырысқанда көптеген қателер болуы мүмкін немесе рефакторлау әрекеті кезінде біз бір нәрсені бұзуымыз мүмкін. Мұның бәрі тұтынушылардың қанағаттануына әсер етеді.
Осы тұрғыдан алғанда, архитектура тез өзгертулер енгізуге мүмкіндік беретін және бәрін бұзамыз деп қорықпайтын таза кодты жаза алатындай болуы керек. Қайта қарау итерациялары бірнеше айға созылмауы үшін бізде мұралар көп болғандықтан және ұзақ сынақ кезеңдерін орындау керек.
— Жалпы алғанда, әзірлеушілер, сәулетшілер, өнім ғалымдары, өнім менеджерлері және сынаушылардың өздері тартылған. Сапаны қамтамасыз ету процесіне тағы кім қатысады?
Анастасия: Енді біз бұл мүмкіндікті клиентке жеткіздік деп елестетейік. Өнімнің сапасын өндірісте болған кезде де қадағалау керек екені анық. Бұл кезеңде қателер деп аталатын анық емес сценарийлері бар жағдайлар пайда болуы мүмкін.
Бірінші сұрақ - біз өнімді шығарғаннан кейін бұл қателермен қалай күресеміз? Мысалы, біз стресске қалай қараймыз? Бетті жүктеуге 30 секундтан астам уақыт кетсе, клиент өте риза болмайды.
Бұл жерде қанау ойнайды немесе олар оны қазір атайды, DevOps. Шын мәнінде, бұл өнім өндірісте болған кезде оны басқаруға жауапты адамдар. Бұл бақылаудың әртүрлі түрлерін қамтиды. Тіпті тестілеудің кіші түрі бар - өндірісте тестілеу, біз өзімізге бір нәрсені шығарар алдында сынамауға және оны өндірісте бірден сынауға мүмкіндік береміз. Бұл оқиғаға жылдам әрекет етуге, оған әсер етуге және оны түзетуге мүмкіндік беретін инфрақұрылымды ұйымдастыру тұрғысынан шаралар кешені.
Инфрақұрылым да маңызды. Тестілеу кезінде бізде клиентке бергіміз келетіннің бәрі бар екеніне көз жеткізу мүмкін болмайтын жағдайлар жиі кездеседі. Біз оны өндіріске шығарамыз және айқын емес жағдайларды ұстай бастаймыз. Мұның бәрі сынақтағы инфрақұрылым өндірістегі инфрақұрылымға сәйкес келмейтіндіктен. Бұл тестілеудің жаңа түріне әкеледі - инфрақұрылымды сынау. Бұл әртүрлі конфигурациялар, параметрлер, дерекқорды тасымалдау және т.б.
Бұл сұрақты тудырады - мүмкін команда инфрақұрылымды код ретінде пайдалануы керек.
Өнімнің сапасына инфрақұрылым тікелей әсер етеді деп есептеймін.
Конференцияда нақты іс бар баяндама болады деп сенемін. Код ретінде инфрақұрылымның сапаға қалай әсер ететінін өз тәжірибеңізден айтып беруге дайын болсаңыз, бізге жазыңыз. Инфрақұрылым код ретінде барлық параметрлерді тексеруді және басқа жағдайда мүмкін емес нәрселерді тексеруді жеңілдетеді. Сондықтан сапалы өнімді жасау процесіне операция да қатысады.
— Аналитика мен құжаттама туралы не айтасыз?
Анастасия: Бұл кәсіпорын жүйелеріне көбірек қатысты. Кәсіпорын туралы айтқанда, аналитиктер мен жүйелік талдаушылар сияқты адамдар бірден еске түседі. Оларды кейде техникалық жазушылар деп те атайды. Олар спецификацияны жазу және оны орындау тапсырмасын алады, мысалы, бір айға.
Мұндай құжаттаманы жазу өте ұзақ әзірлеу итерацияларына және нақтылаудың ұзақ итерацияларына әкелетіні бірнеше рет дәлелденді, өйткені тестілеу процесінде қателер анықталады және қайтарулар басталады. Нәтижесінде әзірлеу шығындарын арттыратын көптеген циклдар бар. Бұған қоса, бұл осалдықтарды енгізуі мүмкін. Біз анықтамалық код жазған сияқтымыз, бірақ содан кейін біз тамаша ойластырылған архитектураны бұзатын өзгерістер жасадық.
Түпкі нәтиже - мүлдем жоғары сапалы өнім емес, өйткені патчтар архитектурада пайда болды, кейбір жерлерде код сынақтармен жеткілікті түрде қамтылмаған, өйткені мерзімдер аяқталып жатыр, барлық қателерді тез жабу керек. Мұның бәрі бастапқы спецификацияда жүзеге асырылуы керек барлық тармақтарды ескермегендіктен.
Әзірлеушілер зиянкестер емес және қателері бар кодты әдейі жазбайды.
Егер біз бастапқыда барлық қажетті тармақтарды қамтитын спецификацияны ойластырсақ, онда бәрі дәл қажетінше орындалар еді. Бірақ бұл утопия.
100 беттік мінсіз сипаттаманы жазу мүмкін емес шығар. Сондықтан құжаттаманы жазудың баламалы тәсілдерін ойластыру қажет, спецификациялар, әзірлеушінің дәл қажет нәрсені орындауын қамтамасыз етуге бізді жақындататын тапсырмаларды орнату.
Бұл жерде Agile-дан тәсілдер еске түседі - қабылдау критерийлері бар пайдаланушылардың әңгімелері. Бұл кішігірім итерацияларда дамитын командаларға көбірек қатысты.
— Қолдану мүмкіндігін тексеру, өнімнің ыңғайлылығы, дизайн туралы не айтасыз?
Анастасия: Бұл өте маңызды мәселе, өйткені командада дизайнерлер бар. Көбінесе дизайнерлер қызмет ретінде пайдаланылады - дизайн бөлімі немесе аутсорсинг дизайнері. Дизайнер өнім маманын тыңдап, түсінгенін істегендей болатын жағдайлар жиі кездеседі. Бірақ біз итерацияны бастағанда, іс жүзінде орындалған нәрсе күткендей болмағаны белгілі болды: дизайнер бірдеңені ұмытып кетті, мінез-құлық арқылы толық ойланбады, өйткені ол командада емес, контексте немесе алдыңғы қатарда емес. -соңғы әзірлеуші оның орналасуын толық түсінбеді. Ол үшін бірнеше итерация қажет болуы мүмкін, себебі алдыңғы қатардағы әзірлеуші дизайнды түсінуінде мәселе бар.
Оның үстіне тағы бір мәселе бар. Дизайн жүйелері қазір танымал бола бастады. Олар хайпта, бірақ олардың пайдасы толығымен анық емес.
Мен жобалау жүйелері, бір жағынан, әзірлеуді жеңілдетеді, бірақ екінші жағынан, интерфейске көптеген шектеулер қояды деген пікірді кездестіремін.
Нәтижесінде біз клиент қалаған мүмкіндікті емес, біз үшін қолайлы мүмкіндікті жасаймыз, өйткені бізде оны жасауға болатын белгілі бір текшелер бар.
Менің ойымша, бұл қарап шығуға тұрарлық және дизайнды жеңілдетуге тырысқанда, біз шынымен клиенттің ауырсыну нүктесін шешіп жатырмыз ба деп ойлайтын тақырып.
— Сапаны қамтамасыз етумен байланысты таңқаларлық көптеген тақырыптар бар. Ресейде олардың барлығын талқылайтын конференция бар ма?
Анастасия: Осы жылы 25-ші рет өткізілетін және SQA Days Сапаны қамтамасыз ету конференциясы деп аталатын ең көне сынақ конференциясы бар. Ол негізінен функционалдық тестерлер үшін құралдар мен арнайы тестілеу тәсілдерін талқылайды. Әдетте, SQA күндеріндегі есептер тестілеушілердің өздерінің жауапкершілігі саласындағы нақты салаларды терең зерттейді, бірақ күрделі әрекеттер емес.
Бұл әртүрлі құралдар мен тәсілдерді, дерекқорларды, API интерфейстерін және т.б. тексеруді түсінуге көп көмектеседі. Бірақ сонымен бірге, бір жағынан, бұл жақсы өнімді жасау үшін тек тестілеуден көп нәрсені тартуға итермелемейді. Екінші жағынан, тестерлер өнімнің жаһандық мақсаты мен оның іскерлік құрамдас бөлігі туралы ойлау процесіне көбірек тартылмайды.
Мен үлкен бөлімді басқарамын және жалпы саланың жай-күйін түсінуге мүмкіндік беретін көптеген сұхбаттар жүргіземін. Әдетте, біздің жігіттер кәсіпорындарда жұмыс істейді және олардың жауапкершілігі айқын. Шетелдік жобаларда жұмыс істейтін әріптестер тестілеудің әртүрлі түрлерін пайдаланады: олар жүкті тестілеуді, өнімділікті тексеруді, тіпті кейде қауіпсіздікті тексеруді де жасай алады, өйткені олар командаға өнімнің сапасын қамтамасыз етуге шынымен көмектеседі.
Мен Ресейдегі жігіттердің де бұл сала функционалдық тестілеумен аяқталмайды деп ойлай бастағанын қалаймын.
— Осы мақсатта біз сапаға ажырамас пән ретінде арналған QualityConf жаңа конференциясын ұйымдастырып жатырмыз. Идея туралы толығырақ айтып өтсеңіз, конференцияның негізгі мақсаты қандай?
Анастасия: Біз сапалы өнім жасауға мүдделі адамдар қауымдастығын құрғымыз келеді. Сапаны жақсарту үшін нені өзгерту керектігін нақты түсініп, конференциядан кейін келіп, есептерді тыңдап, кете алатын платформаны ұсыныңыз.
Қазір мен кеңес беруден тестілеу мен сапаға қатысты мәселелер туындаған кезде не істеу керектігі туралы өтінішті жиі естимін. Командалармен қарым-қатынас жасай бастағанда, мәселе тестілеушілердің өзінде емес, процестің қалай құрылымдалғанында екенін көресіз. Мысалы, әзірлеушілер кодты жазуға ғана жауапты деп есептесе, олардың жауапкершілігі тапсырманы тестілеуге тапсырған сәтте аяқталады.
Нашар жазылған, нашар архитектурасы бар сапасыз код жоба үшін үлкен проблемаларға қауіп төндіретіні туралы бәрі ойламайды. Олар қателердің құны туралы ойламайды, өндірісте аяқталатын қателер компания мен команда үшін үлкен шығындарға әкелуі мүмкін. Бұл туралы ойланатын мәдениет жоқ. Конференцияда тарата бастасақ деймін.
Бұл жаңалық емес екенін түсінемін.Сапаның 14 қағидасының авторы Эдвард Деминг қателіктің құны туралы сонау өткен ғасырда жазған. Сапаны қамтамасыз ету пән ретінде осы кітапқа негізделген, бірақ, өкінішке орай, қазіргі заманғы даму бұл туралы ұмытады.
— Тестілеу мен құралдар туралы тікелей тақырыптарды қозғауды жоспарлап отырсыз ба?
Анастасия: Құралдар туралы есептер болатынын мойындаймын. Компаниялар мен командалар өнімге әсер ете алатын әмбебап құралдар бар.
Барлық есептер жаһандық деңгейде бір ортақ миссиямен біріктіріледі: аудиторияға осы тәсілдің, құралдың, әдістің, процестің, сынақ түрі арқылы біз өнімнің сапасына әсер еткенімізді және клиенттің өмірін жақсартқанымызды жеткізу.
Бізде құрал үшін құрал туралы есептер болмайды. Бағдарламаға енгізілген барлық есептерді ортақ мақсат біріктіреді.
— Конференцияның қонағы ретінде көріп отырғандарыңыз кімге қызық болады?
Анастасия: Бізде жобаның, өнімнің, жүйенің тағдыры туралы ойлайтын әзірлеушілерге арналған есептер болады. Сол сияқты, бұл тестерлерді де, менің ойымша, әсіресе менеджерлерді де қызықтырады. Менеджерлер дегенде мен шешім қабылдайтын және өнімнің, жүйенің, команданың тағдыры мен дамуына әсер ете алатын адамдарды айтамын.
Бұл өнімнің немесе жүйенің сапасын қалай жақсартуға болатынын ойлайтын адамдар. Біздің конференцияда олар әртүрлі шаралар кешенімен танысады және оларда қазір не дұрыс емес екенін және нені өзгерту керектігін түсінеді.
Менің ойымша, басты критерий – сапаға бірдеңе дұрыс емес екенін түсініп, оған әсер ету. Бұл бірінші рет болады деп ойлайтын адамдарға біз жете алмайтын шығармыз.
— Жалпы сала тек тестілеу туралы ғана емес, сапа мәдениеті туралы айтуға пісіп-жетілді деп ойлайсыз ба?
Анастасия: Мен жетілдім деп ойлаймын. Қазір көптеген компаниялар дәстүрлі Сарқырама тәсілінен Agile-ге қарай жылжуда. Тұтынушыға назар аудару бар, командалардағы адамдар сапалы өнімді қалай жасау туралы ойлана бастады. Тіпті кәсіпорын компаниялары сапаны жақсартуға қайта көңіл бөлуде.
Қоғамда болып жатқан өтініштердің санына қарап, уақыт жетті деп есептеймін. Мен, әрине, бұл ауқымды революция болатынына сенімді емеспін, бірақ мен санадағы бұл революцияның болғанын қалаймын.
-Келісемін! Мәдениетті сіңіріп, сананы өзгертеміз.
IT өнімдерінің жоғары сапалы дамуы бойынша конференция орын алады 7 маусымда Мәскеуде. Сіз жоғары сапалы өнімді қандай кезеңдерден тұратынын білесіз, бізде өндірістегі қателіктермен сәтті күресу жағдайлары бар, біз өз тәжірибемізде танымал әдістерді сынадық - бізге сіздің тәжірибеңіз қажет. олардың өтініштер 1 мамырға дейін, және Бағдарлама комитеті конференцияның жалпы тұтастығына тақырыпты шоғырландыруға көмектеседі.
Қосылу , онда біз сапа мәселелерін және конференцияны талқылаймыз, жазылыңыз бағдарлама жаңалықтарынан хабардар болу.
Ақпарат көзі: www.habr.com