Ця стаття буде цікава тим, хто так само, як і ми зіткнувся з проблемою підбору відповідного спеціаліста в галузі тестування.
Як не дивно, але зі збільшенням кількості ІТ-компаній у нашій республіці збільшується лише кількість гідних програмістів, але не тестувальників. У цю професію рвуться багато хто, але не багато хто розуміє її сенс.
Не можу сказати за всі ІТ-компанії, але ми за своїми фахівцями з якості закріпили роль 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