Прывітанне, Хабр!
У нас новая важная тэма - якасная распрацоўка IT-прадуктаў. Мы часта гаворым на HighLoad++, як зрабіць нагружаныя сэрвісы хуткімі, а на Frontend Conf — класны карыстацкі інтэрфейс, які не тармозіць. У нас рэгулярна ёсць тэмы пра тэсціраванне, і DevOpsConf пра аб'яднанне розных працэсаў, уключаючы тэсціраванне. А пра тое, што можна назваць якасць у цэлым, і як над ёй комплексна працаваць – не.
Выправім гэта на - будзем развіваць культуру думаць аб якасці канчатковага прадукта для карыстальніка на кожнай стадыі распрацоўкі. Звычку не зацыклівацца на сваёй зоне адказнасці, і асацыяваць якасць не толькі з тэсціроўшчыкамі.
Пад катом пагаворым з кіраўніком праграмнага камітэта, кіраўніком тэсціравання ў Тинькофф.Бизнес, стваральнікам рускамоўнай QA-супольнасці Анастасіяй Асеевай-Нгуен аб стане галіны QA і місіі новай канферэнцыі.
- Насця, прывітанне. Раскажы, калі ласка, пра сябе.
Анастасія: Я кірую тэсціраваннем у банку, адказваю за вельмі вялікую каманду — нас больш за 90 чалавек. У нас важная бізнес-лінія, мы адказваем за экасістэму для юрыдычных асоб.
Я вучылася на мехмаце і першапачаткова хацела стаць праграмістам. Але калі ў мяне з'явілася цікавая прапанова, я вырашыла паспрабаваць сябе ў ролі тэсціроўшчыка. Як ні дзіўна, гэта аказалася маім пакліканнем. Цяпер усю сваю працу я бачу менавіта ў гэтай галіне.
Я заўзяты адэпт дысцыпліны Quality Assurance. Мне неабыякава, якія прадукты ствараюцца, як ставяцца да якасці ў кампаніі, у камандзе і, у прынцыпе, у працэсе распрацоўкі.
Для мяне відавочна, што супольнасць у гэтым напрамку недастаткова спелая, прынамсі ў Расіі. Не заўсёды мы разумеем, што забеспячэнне якасці - гэта не толькі сам факт тэсціравання прыкладання на адпаведнасць патрабаванням. Мне б хацелася змяніць гэтую сітуацыю.
- Ты ўжываеш словы Quality Assurance і тэсціраванне. У вачах абывацеля гэтыя два тэрміны вельмі часта перасякаюцца. Чым яны адрозніваюцца, калі капаць глыбока?
Анастасія: Хутчэй, не адрозніваюцца. Тэставанне - частка дысцыпліны Quality Assurance, гэта непасрэдная дзейнасць - сам факт таго, што я нешта тэстую. Відаў тэсціравання насамрэч вельмі шмат, і за розныя віды тэсціравання адказваюць самыя розныя людзі. Але ў нас у Расіі, калі з'явілася хваля аўтсорсераў, якія пастаўляюць тэсціроўшчыкаў у кампаніі, тэсціраванне звялося да адзінага ўвазе.
У большасці выпадкаў абмяжоўваюцца толькі функцыянальным тэсціраваннем: правяраюць, што тое, што накадзілі распрацоўшчыкі, адпавядае спецыфікацыі і ўсё.
- Раскажы, калі ласка, якія яшчэ ёсць дысцыпліны забеспячэння якасці? Што яшчэ, акрамя тэсціравання, сюды ўваходзіць?
Анастасія: Quality Assurance – гэта, у першую чаргу, пра стварэнне якаснага прадукта. Гэта значыць, мы задаемся пытаннем, якімі атрыбутамі якасці павінен валодаць наш прадукт. Адпаведна, калі мы гэта разумеем, дык можам супаставіць, хто ўплывае на гэтыя атрыбуты якасці. Не важна, распрацоўшчык, проджект-менеджэр або прадуктолаг - Гэта чалавек, які ўплывае на развіццё прадукта, на яго бэклог, на яго стратэгію.
Тэстыравальнік лепш пачынае ўсведамляць сваю ролю. Ён разумее, што яго задача не толькі тэставаць на адпаведнасць патрабаванням, але і тэставаць патрабаванні, падвяргаць сумневу фармулёўкі, якія зыходзяць ад прадуктолага, выкрываць усе няяўныя патрабаванні і чаканні кліента. Калі мы пастаўляем новую функцыянальнасць нашаму кліенту, мы павінны сапраўды задаволіць яго чаканні і вырашыць яго боль. Калі мы будзем думаць аб усіх атрыбутах якасці, кліент будзе задаволены і будзе разумець, што кампанія, чыім прадуктам ён карыстаецца, сапраўды клапоціцца аб яго інтарэсах, а не працуе па прынцыпе "абы выпусціць фічу".
- Здаецца, тое, што ты зараз апісала, - гэта задача прадуктолага. Гэта, у прынцыпе, не пра тэставанне і не пра якасць - гэта наогул пра product management, не?
Анастасія: У тым ліку. Quality Assurance - гэта не дысцыпліна, за якую адказвае адзін канкрэтны чалавек. Цяпер ёсць папулярны кірунак у тэсціраванні, падыход, які называецца Спрытнае тэсціраванне. У яго вызначэнні прама гучыць, што гэта камандны падыход да тэсціравання, які ўключае ў сябе пэўны набор практык. За рэалізацыю гэтага падыходу адказвае ўся каманда, нават не абавязкова, каб у камандзе быў тэсціроўшчык. Уся каманда арыентавана на тое, каб даставіць каштоўнасць кліенту, і каб гэтая каштоўнасць адпавядала яго чаканням.
- Атрымліваецца, што якасць перасякаецца ці ледзь не з усімі навакольнымі дысцыплінамі, накладваючы рамкі на ўсё вакол?
Анастасія: Дакладна. Калі мы задумваемся аб тым, што хочам стварыць якасны прадукт, мы пачынаем думаць аб розных атрыбутах якасці. Напрыклад, як праверыць, што мы сапраўды зрабілі фічу, якая патрэбна нашаму кліенту.
Тут усплывае такі від тэставання, як UAT (user aceptance testing). Нажаль, у Расіі ён рэдка практыкуецца, але часам прысутнічае ў SCRUM-камандах, як дэма для канчатковага кліента. У замежных кампаніях гэта дастаткова распаўсюджаны від тэсціравання. Перад тым, як адкрыць функцыянальнасць для ўсіх кліентаў, мы спачатку робім UAT, гэта значыць запрашаем канчатковага спажыўца, які праводзіць тэставанне і адразу дае фідбэк - ці сапраўды прадукт адпавядае чаканням і вырашае боль. Толькі пасля гэтага адбываецца маштабаванне на ўсіх астатніх кліентаў.
Гэта значыць, мы арыентуемся на бізнес, на канчатковага кліента, але пры гэтым не забываем пра тэхналогію. Ад тэхналогій таксама моцна залежыць якасць прадукта. Калі ў нас будзе дрэнная архітэктура, мы не зможам хутка выпускаць фічы і адпавядаць чаканням кліента. Можа быць шмат багаў пры спробе маштабаваць, ці пры спробе зрабіць рэфактарынг мы можам нешта зламаць. Гэта ўсё будзе ўплываць на задаволенасць кліента.
З гэтага пункту гледжання, архітэктура павінна быць такой, каб мы маглі пісаць чысты код, які дазволіць хутка ўносіць змены і не баяцца, што мы ўсё разламаем. Каб ітэрацыі дапрацоўкі не расцягваліся на некалькі месяцаў проста таму, што ў нас так шмат лёсу, і трэба рабіць працяглыя этапы тэставання.
— Разам ужо задзейнічаны распрацоўшчыкі, архітэктары, прадуктолагі, продакт-менеджэры, самі тэсціроўшчыкі. Хто яшчэ задзейнічаны ў працэсе забеспячэння якасці?
Анастасія: Цяпер уявім, што мы ўжо даставілі кліенту фічу. Відавочна, за якасцю прадукта трэба сачыць, і калі ён ужо ў прадакшэне. На гэтым этапе могуць выявіцца сітуацыі з невідавочнымі сцэнарамі, так званыя багі.
Першае пытанне - як мы працуем з гэтымі багамі пасля таго, як ужо выпусцілі прадукт? Як мы, напрыклад, рэагуем на нагрузку? Кліент будзе не вельмі задаволены, калі старонка загружаецца больш за 30 секунд.
Тут уступае ў гульню эксплуатацыя ці, як зараз завуць, DevOps. Па факце гэта людзі, якія адказваюць за эксплуатацыю прадукта, калі ён ужо на продзе. Сюды ўваходзяць розныя віды маніторынгу. Ёсць нават падвід тэставання - тэставанне на продзе, калі мы дазваляем сабе нешта не тэставаць да выкаткі і тэстуем гэта адразу на продзе. Гэта шэраг мерапрыемстваў з пункту гледжання арганізацыі інфраструктуры, якія даюць магчымасць хутка адрэагаваць на інцыдэнт, паўплываць на яго, выправіць.
Інфраструктура таксама важная. Часта бываюць сітуацыі, калі падчас тэсту немагчыма пераканацца, што ў нас сапраўды ўсё тое, што мы хацелі б даць кліенту. Выкочваем на прод - і пачынаем лавіць невідавочныя сітуацыі. А ўсё таму, што інфраструктура ў цесцю не адпавядае інфраструктуры на продзе. Адсюль выцякае новы від тэсціравання. тэсціраванне інфраструктуры. Гэта розныя канфігурацыі, наладкі, міграцыя баз дадзеных і г.д.
Адсюль узнікае пытанне - магчыма, камандзе трэба выкарыстоўваць інфраструктуру як код.
Я веру ў тое, што інфраструктура напрамую ўплывае на якасць прадукта.
Спадзяюся, на канферэнцыі будзе даклад з рэальным кейсам. Напішыце нам, калі гатовыя на сваім вопыце расказаць, як інфраструктура як код уплывае на якасць. Інфраструктура як код дазваляе прасцей правяраць усе наладкі і тэставаць тое, што інакш проста немагчыма. Таму ў працэс распрацоўкі якаснага прадукта залучаецца і эксплуатацыя.
- А што наконт аналітыкі і дакументацыі?
Анастасія: Гэта адносіцца больш да enterprise сістэм. Калі мы гаворым пра enterprise, адразу ў галаву прыходзяць такія людзі, як аналітыкі і сістэмныя аналітыкі. Часам іх называюць тэхнічнымі пісьменнікамі. Яны атрымліваюць заданне на напісанне спецыфікацыі і выконваюць яго, напрыклад, месяц.
Неаднаразова даказана, што напісанне такой дакументацыі прыводзіць у вельмі працяглым ітэрацыям распрацоўкі і працяглым ітэрацыям дапрацоўкі, таму што падчас тэставанняў выяўляюцца багі, пачынаюцца звароты. У выніку з'яўляецца вельмі шмат завес, якія павялічваюць кошт распрацоўкі. Акрамя таго, гэта можа ўнесці ўразлівасці. Мы быццам бы напісалі эталонны код, але потым унеслі змены, якія ламаюць ідэальна прадуманую архітэктуру.
У выніку атрымліваецца не зусім якасны прадукт, таму што ў архітэктуры ўжо з'явіліся латкі, код у некаторых месцах нядосыць пакрыты тэстамі, таму што тэрміны падціскаюць, трэба хутчэй зачыніць усе багі. А ўсё таму, што ў першапачатковай спецыфікацыі не былі ўлічаны ўсе моманты, якія трэба рэалізаваць.
Распрацоўнікі - не шкоднікі і не пішуць спецыяльна код з памылкамі.
Калі б мы першапачаткова прадумалі спецыфікацыю, у якой былі б асветлены ўсе неабходныя моманты, тое ўсё было б рэалізавана менавіта так, як і трэба. Але гэта ўтопія.
Мусіць, напісаць ідэальную спецыфікацыю на 100 старонак немагчыма. Таму трэба задумацца аб альтэрнатыўных спосабах напісання дакументацыі, спецыфікацыі, пастаноўкі задач, якія б набліжалі нас да таго, каб распрацоўшчык рабіў менавіта тое, што трэба.
Тут у галаву прыходзяць падыходы з Agile - карыстацкія гісторыі з aceptance крытэрамі. Гэта больш дастасавальна для каманд, якія развіваюцца маленькімі ітэрацыямі.
- Што на рахунак usability-тэставанні, выгоды выкарыстання прадукта, дызайну?
Анастасія: Гэта вельмі важны момант, таму ў камандзе ёсць дызайнеры. Часцей за ўсё дызайнерамі карыстаюцца як сэрвісам - альбо аддзел дызайнераў, альбо дызайнер на аўтсорсе. Часта сустракаюцца сітуацыі, што быццам бы дызайнер паслухаў прадуктолага і зрабіў тое, што зразумеў. Але калі прыступаем да ітэрацыі, высвятляецца, што насамрэч зроблена не тое, што чакалі: дызайнер нешта забыўся, не да канца прадумаў паводзіны, таму што ён не ў камандзе і не ў кантэксце, ці фронтэнд распрацоўшчык не да канца зразумеў яго макет. Можа спатрэбіцца некалькі ітэрацый толькі з-за таго, што ёсць праблема з разуменнем дызайну фронтэнд-распрацоўшчыкам.
Плюс ёсць яшчэ адна праблема. Цяпер набіраюць папулярнасць дызайн-сістэмы. Яны на хайпе, але выгада ад іх не зусім відавочная.
Я сутыкаюся з меркаваннем, што дызайн-сістэмы, з аднаго боку, спрашчаюць распрацоўку, з другога боку – накладваюць вельмі шмат абмежаванняў на інтэрфейс.
У выніку мы робім не такую фічу, якую кліент хоча атрымаць, а такую, якая зручная нам, таму што ў нас ужо ёсць пэўныя кубікі, з якіх мы можам яе зрабіць.
Мне здаецца, на гэтую тэму варта звярнуць увагу і задумацца, ці сапраўды ў спробе спрасціць працу над дызайнам мы вырашаем кліенцкую боль.
- Атрымліваецца дзіўна шмат тэм, звязаных Quality Assurance. У Расіі ёсць канферэнцыя, на якой усе іх можна абмеркаваць?
Анастасія: Ёсць самая старая канферэнцыя па тэсціраванню, якая сёлета пройдзе 25-ы раз і так і называецца — Канферэнцыя па забеспячэнні якасці SQA Days. У асноўным на ёй абмяркоўваюцца інструменты і канкрэтныя падыходы тэсціравання для функцыянальных тэсціроўшчыкаў. Як правіла, у дакладах на SQA Days глыбока разглядаюцца канкрэтныя вобласці ў зоне адказнасці саміх тэсціроўшчыкаў, але не комплексныя мерапрыемствы.
Гэта выдатна дапамагае разабрацца ў розных інструментарыях і падыходах, як тэсціраваць базы дадзеных, API і г.д. Але пры гэтым, з аднаго боку, не матывуе залучаць у стварэнне больш якаснага прадукта не толькі тэставанне. А з другога - тэсціроўшчыкі не становяцца больш ўцягнутыя ў працэс, каб думаць аб глабальнай мэты прадукту і яго бізнес-складніку.
Я кірую вялікім аддзелам, праводжу шмат сумоўяў, якія насамрэч дазваляюць прадставіць стан галіны ў цэлым. Як правіла, нашы хлопцы працуюць у enterprise, і ў іх дакладная зона адказнасці. Калегі, якія працуюць у замежных праектах, выкарыстоўваюць розныя віды тэсціравання: самі могуць рабіць нагрузачнае тэсціраванне, тэсціраванне прадукцыйнасці, і нават часам тэсціраванне бяспекі (security testing), таму што яны сапраўды дапамагаюць камандзе забяспечваць прадукт якасцю.
Мне б хацелася, каб у нас у Расіі хлопцы таксама пачалі задумвацца аб тым, што на функцыянальным тэсціраванні галіна не заканчваецца.
- Для гэтага мы і арганізуем новую канферэнцыю QualityConf, якая прысвечана якасці, як цэласнай дысцыпліне. Раскажы пра задумку падрабязней, у чым асноўная мэта канферэнцыі?
Анастасія: Мы хочам стварыць супольнасць людзей, зацікаўленых рабіць якасныя прадукты. Прапанаваць пляцоўку, куды яны змогуць прыйсці, паслухаць даклады і выйсці пасля канферэнцыі з канкрэтным разуменнем, што трэба памяняць у сябе дзеля паляпшэння якасці.
Часта зараз чую запыт ад кансалтынгу, што рабіць, калі ёсць праблемы з тэсціраваннем, з якасцю. Калі пачынаеш мець зносіны з камандамі, бачыш, што праблема не ў саміх тэсціроўшчыках, а ў тым, як выбудаваны працэс. Напрыклад, калі распрацоўшчыкі лічаць, што яны адказныя толькі за напісанне кода, іх адказнасць заканчваецца роўна ў той момант, калі яны перадалі задачу ў тэсціраванне.
Не ўсе задумваюцца аб тым, што дрэнна напісаны няякасны код з дрэннай архітэктурай пагражае вялікімі праблемамі для праекту. Не задумваюцца аб кошце памылак, аб тым, што багі, якія патрапілі ў прадакшэн, могуць выліцца ў вялікія выдаткі для кампаніі і каманды. Няма культуры думаць аб гэтым. Жадаю, каб на канферэнцыі мы пачалі яе распаўсюджваць.
Я разумею, што гэта не інавацыя. Эдвард Дэмінг, аўтар 14 пастулатаў якасці, пісаў пра кошт памылкі яшчэ ў мінулым стагоддзі. На гэтай кнізе грунтуецца Quality Assurance, як дысцыпліна, але, нажаль, сучасная распрацоўка, забывае пра гэта.
— А тэмы непасрэдна пра тэсціраванне і інструменты плануеце закрануць?
Анастасія: Дапускаю, што будуць даклады пра інструменты. Ёсць дастаткова ўніверсальныя прылады, з дапамогай якіх кампаніі і каманды могуць паўплываць на прадукт.
Усе даклады глабальна будуць аб'яднаны адной агульнай місіяй: данесці да аўдыторыі, што з дапамогай гэтага падыходу, інструмента, метаду, працэсу, віду тэсціравання мы паўплывалі на якасць прадукта і палепшылі жыццё кліента.
У нас сапраўды не будзе дакладаў пра прыладу дзеля прылады. Усе даклады, якія трапяць у праграму, будуць аб'яднаны агульнай мэтай.
- Каму будзе цікава тое, пра што ты кажаш, каго бачыш у якасці гасцей канферэнцыі?
Анастасія: У нас будуць даклады для распрацоўшчыкаў, якім неабыякавы лёс свайго праекта, прадукту, сістэмы. Аналагічна будзе цікава тэсціроўшчыкам і, як мне здаецца, асабліва менеджэрам. Пад мэнэджэрамі я маю на ўвазе людзей, якія прымаюць рашэнне і могуць уплываць на лёс і развіццё прадукта, сістэмы, каманды ў тым ліку.
Гэта людзі, якія задаюцца пытаннем - як павысіць якасць прадукту, сістэмы. На нашай канферэнцыі яны даведаюцца пра розныя комплексы мерапрыемстваў і змогуць зразумець, што ў іх зараз не так, што трэба памяняць.
Думаю, галоўны крытэр - разумець, што з якасцю нешта не так, і хацець на гэта паўплываць. Мусіць, з першага разу дастукацца да людзей, якія лічаць, што і так сыдзе, нам не атрымаецца.
— Як ты думаеш, індустрыя ў цэлым саспела для таго, каб пагаварыць не проста аб тэсціраванні, а аб культуры якасці?
Анастасія: Я лічу, што саспела. Цяпер шматлікія кампаніі адыходзяць ад традыцыйнага Waterfall-падыходу ў бок Agile. Ідзе арыентацыя на кліента, людзі ў камандах сапраўды пачынаюць задумвацца аб тым, як стварыць якасны прадукт. Нават у enterprise-кампаніях адбываецца пераарыентацыя на павышэнне якасці.
Мяркуючы па колькасці запытаў, якія ўзнікаюць у супольнасці, я лічу, што ўжо час. Не ўпэўнена вядома, што гэта будзе маштабная рэвалюцыя, але мне хацелася б, каб гэты пераварот у свядомасці здарыўся.
- Дамовіліся! Будзем прывіваць культуру і пераварочваць прытомнасць.
Канферэнцыя пра якасную распрацоўку IT-прадуктаў адбудзецца у Маскве 7 чэрвеня. Ведаеце, з якіх этапаў складаецца якасны прадукт, у запасе ёсць кейсы паспяховай барацьбы з багамі на продзе, на сваёй практыцы праверылі папулярныя методыкі - нам патрэбен ваш вопыт. свае заяўкі да 1 траўня, а Праграмны камітэт дапаможа сфакусаваць тэму для агульнай цэласнасці канферэнцыі.
падключайцеся да , у якім абмяркоўваем пытанні якасці і канферэнцыю, падпісвайцеся на , Каб быць у курсе навін праграмы.
Крыніца: habr.com