Гэты артыкул будзе цікавая тым, хто гэтак жа як і мы сутыкнуўся з праблемай падбору падыходнага спецыяліста ў галіне тэсціравання.
Як ні дзіўна, але з павелічэннем колькасці ІТ-кампаній у нашай рэспубліцы павялічваецца толькі колькасць годных праграмістаў, але не тэсціроўшчыкаў. У гэтую прафесію рвуцца многія, але не многія разумеюць яе сэнс.
Не магу сказаць за ўсе ІТ-кампаніі, але мы за сваімі спецыялістамі ў галіне якасці замацавалі ролю QA / QC. Яны ўваходзяць у склад каманды распрацоўшчыкаў і ўдзельнічаюць на ўсіх этапах распрацоўкі, пачынаючы ад даследавання і заканчваючы выпускам новай версіі.
Тэстыравальнік ў камандзе, яшчэ на этапе планавання павінен абдумаць усе функцыянальныя і нефункцыянальныя патрабаванні да прыёмкі карыстацкай гісторыі. Ён павінен не горш праграмістаў, а нават лепш, разбірацца ў эксплуатацыйных характарыстыках прадукта і дапамагаць камандзе не прымаць няслушных рашэнняў яшчэ на этапе планавання. Тэстыравальнік павінен мець дакладнае ўяўленне аб тым, як рэалізуемая функцыянальнасць будзе працаваць і якія падводныя камяні могуць быць. Тэст-планы і тэст-кейсы нашы тэсціроўшчыкі складаюць самі, гэтак жа як і рыхтуюць усе неабходныя стэнды для тэставання. Тэставаць па гатовай спецыфікацыі як monkey-кликер, не наш варыянт. Працуючы ўнутры каманды, ён павінен дапамагчы выпусціць дастойны прадукт і своечасова забіць трывогу, калі нешта пайшло не так.
З чым мы сутыкнуліся, калі шукалі тэсціроўшчыкаў
На этапе вывучэння мноства рэзюмэ, здавалася, што ёсць спецыялісты з прыдатным для нас вопытам і праблем з выбарам тэсціроўшчыка ў нашу каманду не будзе. Але, пры асабістых сустрэчах мы ўсё больш сутыкаліся з кандыдатамі, якія ў рэчаіснасці былі даволі далёкія ад свету інфармацыйных тэхналогій (напрыклад, не маглі расказаць прынцыпы ўзаемадзеяння браўзэра і вэб-сервера, асновы бяспекі, рэляцыйныя і нерэляцыйныя базы даных, не мелі ўяўлення аб віртуалізацыі. і кантэйнерызацыі), але пры гэтым ацэньвалі сябе на ўзроўні Senior QA. Правёўшы не адзін дзясятак сумоўяў мы прыйшлі да высновы, што колькасць падыходных менавіта нам спецыялістаў у рэгіёне нікчэмна малая.
Далей, я раскажу якія крокі мы рабілі і на якія граблі наступалі, каб знайсці тых самых, доўгачаканых змагароў за якасць.
Як мы спрабавалі выправіць сітуацыю
Намучыўшыся з сорсінгам гатовых адмыслоўцаў, мы сталі прыстрэльвацца па найблізкіх абласцях:
- Спрабавалі прымяніць асэсмент-практыкі для выяўлення сярод процьмы "уйтивайтишников", тых самых, з каго зможам вырасціць моцных спецыялістаў.
Групе патэнцыйных кандыдатаў, з прыблізна аднолькавым узроўнем ведаў, мы прапаноўвалі выканаць заданні. Назіраючы за іх разумовым працэсам імкнуліся вылучыць самага перспектыўнага кандыдата.
У тым ліку, мы прыдумалі заданні на праверку ўважлівасці, разумення магчымасцей тэхналогій і асаблівасцях мультыкультурнасці:
- Праводзілі мітапы для тэсціроўшчыкаў, каб пашырыць межы разумення прафесіі ў існуючага кантынгенту.
Раскажу крыху пра кожнага з іх.
Ufa Software QA and Testing Meetup #1 – гэта наша першая спроба сабраць неабыякавых да прафесіі і заадно зразумець ці цікава будзе публіцы тое, што мы жадаем данесці да іх. У асноўным, нашы даклады былі аб тым, з чаго лепш пачынаць, калі ўжо ты вырашыў стаць тэсціроўшчыкам. Дапамагчы пачаткоўцам адкрыць вочы і зірнуць на тэставанне "па-даросламу". Мы распавядалі аб кроках, якія трэба зрабіць пачаткоўцам тэсціроўшчыкам, каб уліцца ў прафесію. Пра тое, што такое якасць і як яе дабіцца ў рэальных умовах. А таксама, што такое аўтаматычнае тэсціраванне і, дзе яго мэтазгодней прымяняць.
Далей, з інтэрвалам у 1-2 месяцы, мы правялі яшчэ два мітапы. Удзельнікаў ужо было разы ў два больш. На "Ufa Software QA and Testing Meetup # 2" мы глыбей акунуліся ў прадметную вобласць. Распавялі пра багтрэкінгавыя сістэмы, пра тэставанне UI/UX, закранулі Docker, Ansible, а таксама распавялі аб магчымых канфліктах паміж распрацоўшчыкам і тэстыравальнікам і спосабах іх дазволу.Наш трэці мітап Ufa Software QA and Testing Meetup # 3 ускосна дакранаўся працы тэстыравальнікаў, але быў карысны для таго, каб своечасова нагадаць праграмістам аб іх тэхнічна-арганізацыйным абавязку: нагрузачнае тэставанне, e2e тэставанне, Selenium у аўтатэставанні, уразлівасцяў.
Увесь гэты час мы вучыліся рабіць звычайнае святло і гук у вяшчаннях з нашых мерапрыемстваў:
→
→
→ - І ў канцы вырашылі паспрабаваць правесці хакатон для тэстыравальнікаў
Як рыхтаваліся і праводзілі хакатон для тэсціроўшчыкаў
Для пачатку паспрабавалі зразумець, што гэта за "звер" такі і як яго звычайна праводзяць. Як высветлілася, мерапрыемствы падобнага роду ў РФ праводзілі не так шмат разоў, і ідэй запазычыць няма дзе. Па-другое, не хацелася адразу, у сумнеўнае на першы погляд мерапрыемства, укладваць шмат рэсурсаў. Таму вырашылі, што будзем рабіць кароткія міні хакатоны, не на ўвесь цыкл працы QA, а на асобныя этапы.
Асноўны наш галаўны боль - гэта недахоп у мясцовых тэсціроўшчыкаў практыкі па фарміраванні выразных карт тэсціравання. Не надаюць часу даследаванням на этапе да рэалізацыі карыстацкіх гісторый і стварэнню зразумелых для распрацоўшчыкаў крытэрыяў прыёмкі па функцыянальным і нефункцыянальным патрабаванням, UI/UX, бяспецы, працоўным і віновым нагрузкам. Таму, мы вырашылі, для першага разу, прайсціся па самай цікавай і творчай частцы іх працы - аналіз і фарміраванне патрабаванняў на перадпраектным даследаванні.
Прыкінулі патэнцыйную колькасць удзельнікаў і вырашылі, што нам трэба мінімум 5 бэклогаў на MVP-рэлізы, 5 прадуктаў і 5 чалавек, якія будуць выконваць ролю ўладальнікаў прадуктаў, расшыфроўваць бізнес-патрэбы і прымаць рашэнні па абмежаваннях.
Вось што ў нас атрымалася: .
Асноўная ідэя была прыдумаць тэмы максімальна далёкія ад усёй паўсядзённай працы ўдзельнікаў і даць ім абшар для творчага палёту фантазіі.
Якія памылкі мы дапусцілі і што можна зрабіць лепш
Ужыванне асэсмент-практык, так папулярных у вобласці прыёму прадаўцоў і мэнэджараў ніжняга звяна, аднялі велізарную колькасць сіл, але не дазволілі нам надаць дастатковую ўвагу кожнаму ўдзельніку і ацаніць яго здольнасці. У цэлым, такі варыянт падбору стварае негатыўны вобраз кампаніі, паколькі даволі шмат чалавек атрымліваюць недастатковы фідбэк і ў далейшым фармуюць у сябе і ў іншых, эфект самадурства наймальніка (камунікацыі ў ІТ-супольнасцях вельмі развіты). У выніку, у нас засталося літаральна два патэнцыйныя кандыдаты з вельмі аддаленай перспектывай.
Вось мітапы справа добрая. Ствараецца шырокая база для прапрацоўкі, павялічваецца агульны ўзровень удзельнікаў. Кампанія становіцца ўсё больш вядомай на рынку. Але, працаёмкасць такіх пачынанняў не малая. Трэба дакладна разумець, што ў год на правядзенне мітапаў будзе сыходзіць прыкладна 700-800 чалавека-гадзін.
Што тычыцца хакатона тэсціроўшчыкаў. Такога роду мерапрыемствы яшчэ не паспелі надакучыць, бо ў адрозненні ад хакатонаў для распрацоўшчыкаў, праводзяцца нашмат радзей. Плюс гэтай задумы ў тым, каб у незануднай манеры можна абмяняцца вялікім аб'ёмам практычных ведаў і даволі дакладна вызначыць узровень кожнага ўдзельніка.
Прааналізаваўшы вынікі мерапрыемства, мы зразумелі, што памылак дапусцілі кучу:
- Самай недаравальнай памылкай было меркаваць, што нам хопіць 4-5 гадзін. У выніку, толькі ўступная і знаёмства з бэклогамі занялі амаль 2 гадзіны.
Праца з уладальнікамі прадуктаў на пачатковым этапе і час, каб пагрузіцца ў прадметную вобласць, заняло яшчэ столькі ж. Так што на ўсебаковую прапрацоўку карт тэсціравання астатняга часу відавочна не хапіла. - Часу і сіл на дэталёвы фідбэк па кожнай карце зусім не хапіла, паколькі была ўжо ноч. Таму, гэтая частка відавочна намі была правалена, а першапачаткова меркавалася як самая каштоўная ў хакатоне.
- Ацэньваць якасць прапрацоўкі мы вырашылі простым галасаваннем усіх удзельнікаў, вылучыўшы на кожную каманду па 3 галасы, якія яны маглі аддаць за найбольш якасныя работы. Магчыма, лепей было б арганізаваць журы.
Чаго дабіліся
Сваю задачу мы часткова вырашылі і зараз у нас працуюць 4 бравых прыгажуна, якія затуляюць тылы 4 каманд распрацоўкі. Значнага пула патэнцыйных моцных кандыдатаў і адчувальных змен ва ўзроўні QA-супольнасці горада пакуль не заўважылі. Але, некаторыя зрухі ёсць і гэта не можа не цешыць.
Крыніца: habr.com