Сови їдуть у Гоґвортс, або як створити тестове завдання для QA-початківців

17 березня
Дмитро Волошин, QA Engineer
Сови їдуть у Гоґвортс, або як створити тестове завдання для QA-початківців
Колись, ще до приходу в DataArt, я зіткнувся з проблемою найму manual QA з невеликим досвідом або зовсім без стажу роботи. Справа була не в нестачі кандидатів, а в недостатньому рівні підготовки більшості з них — ми шукали людей, здатних швидко підтягти практичні навички та приступити до роботи у проекті. З'ясовувалося це вже на етапі співбесіди, але спілкування з кожним кандидатом займало дуже багато часу. У статті я хочу поділитися досвідом складання тестового завдання, яке нашу проблему розв’язало. Я не закликаю копіювати рішення, що спрацювало в конкретних умовах, але гадаю, що на тлі нашої історії корисно замислитися про підхід до відбору кандидатів, який практикується у вашій команді.

Все почалося з того, що ми кілька тижнів не могли закрити жодну позицію Trainee/Junior QA. Рекрутери розводили руками: на чергову вакансію тільки за сім перших днів надійшло декілька сотень відгуків. Але навіть кандидати з добре розписаними резюме, які підтвердили знання теорії, не могли впоратися з елементарними задачами з технік тестування або не знаходили явні баги при проходженні практичної частини співбесіди.

Глибинна причина була зрозумілою: якраз набирала обертів легенда, ніби тестування є легким способом потрапити в IT. Її охоче зміцнювали численні новостворені курси QA, але рівень підготовки їхніх випускників викликав запитання.

У цій ситуації нам було необхідно якомога швидше переглянути підхід до пошуку QA та придумати жорсткі фільтри потоку кандидатів. Найпростішим рішенням було тестове завдання, яке б надсилалося претендентам перед запрошенням на співбесіду.

Проте, пропонуючи виконати якусь роботу ще до першої зустрічі, завжди слід враховувати наступні фактори:

  • Конкуренція на ринку вакансій є високою, і хороших кандидатів розбирають за лічені години.
  • Виконання завдання вимагає часу, якого з урахуванням першого чинника практично ніколи немає.

Тому ми вирішили надсилати його лише претендентам з мінімальним досвідом або зовсім без нього.

Саме завдання мало відповідати наступним критеріям:

  • Мати структуру, яка дозволить його швидко перевірити.
  • Бути простим для виконання.
  • Мати глибину, за рахунок якої кандидат може продемонструвати рівень знань, що перевищує необхідний мінімум.
  • Не обмежуватися стандартними теоретичними задачами.
  • Забезпечувати можливість швидко дати зворотний зв'язок кандидату, який вклав свій час у його виконання.

ПРОРОБКА РІШЕННЯ

Сформулювавши критерії, ми перейшли до структури тестового завдання. За основу взяли реєстраційну форму відомої платіжної системи, куди додали баги, згруповані за об'єктом тестування. А саме:

  • ФУНКЦІОНАЛЬНІ: базові помилки валідації полів.
  • UI/UX: моменти, що порушують базові патерни, та кнопки, незручні для кліка миші.
  • БЕЗПЕКИ: всілякі SQL-ін'єкції. Якщо сильно постаратися, можна було навіть потрапити в БД.
  • СУМІСНОСТІ: у різних браузерах відображення елементів було модифіковано.
  • ЛОКАЛІЗАЦІЇ: завдання передбачало вдумливе читання англійського тексту.

Оскільки ми чекали від кандидатів і загального розуміння системи, додали деякі логічні суперечності. Наприклад, у завданні була кнопка, що не виконувала ніяких дій, а на введену кандидатом електронну адресу приходив неструктурований лист з адреси thisisdefinitelyspam@mail.com.

Основна ідея фільтрації полягала в тому, щоб одразу виявити тих, хто звертає увагу лише на функціональні проблеми та не бачить інших.

Для тих, хто вирішив би піти глибше та використовувати засоби аналізу коду в браузері, передбачили ще декілька сюрпризів. Тут ми дозволили собі деяку творчу свободу:

  • У коді знаходилося зображення божества пастафаріанства — Летючого Макаронного Монстра.
  • Можна було розкоментувати кнопку "Destroy This World", при натисканні на яку з'являлося зображення прибульця з келихом пива і напис "I'm here just for a beer".
  • У коді футера сторінки був залишений коментар неіснуючого розробника. З ним ми трохи перестаралися — текст був написаний у кращих традиціях мемів Reddit. На щастя, вчасно втрутився HR-департамент: ми прослухали лекцію про двозначні жарти і реакції на них, після чого коментар оперативно відредагували.

Задача виконавця полягала в тому, щоб протестувати форму та оформити знайдені проблеми у форматі баг-репортів англійською. Нам було важливо зрозуміти, наскільки добре кандидат вміє структурувати інформацію.

Кандидату не треба було виконувати завдання на 100 %, достатньо було виявити хоча б половину помилок. Сама структура дозволяла зробити попередню оцінку, лише подивившись на список і оформлення баг-репортів.

РЕЗУЛЬТАТ

Ідея відсівати тих, хто звертає увагу лише на функціональні проблеми, спрацювала. Потік кандидатів, яких ми запрошували, скоротився у 4–5 разів.

Несподіванкою виявилось, що чверть кандидатів не справлялася з оформленням. Деякі припускалися величезної кількості орфографічних помилок в англійській, інші не вміли структурувати інформацію. Були, однак, і кандидати, які знаходили всі вразливості безпеки та пасхалки у коді, але не звертали уваги на функціональні проблеми, логічні нестиковки та дизайн.

Практика показала, що в середньому перевірка одного завдання укладалась у п'ять хвилин. Паралельно вже формувалась відповідь кандидату, яку ми могли швидко надіслати, вказавши, з чим саме він не впорався.

Нагадаю, що суттю завдання було протестувати реєстраційну форму.

Деякі претенденти відразу поверталися до нас із запитанням, що і куди ми реєструємо, — це, безсумнівно, говорило на їхню користь. Спочатку я вигадував нудні відповіді, поки одного разу не запропонував рекрутеру написати: “Ми реєструємо сову для поїздки у Гоґвортс ”. Звіти тих, хто знав, що тестує реєстрацію сови, стало значно цікавіше перевіряти.

Перша версія завдання успішно працювала більше року, поки хтось із викладачів комерційних курсів не зробив її розбір. Студенти стали передавати інформацію друзям, і тест у первісному вигляді втратив сенс. Довелося дещо оновити, а Летючого Макаронного Монстра змінило зображення Кракена. Структура завдання залишилася такою самою, але баги ми розмістили в нових місцях.

ВИСНОВОК

Час, виділений на пошук нових рішень для ефективного відбору, з лишком компенсує його економія на проведенні очних співбесід. У конкретному випадку описаний спосіб зарекомендував себе добре. Однак, перш ніж надсилати кандидатам тестове завдання, потрібно оцінити реалії конкретної локації та поточну кон'юнктуру ринку.

Дефіцит кадрів продовжує зростати, при цьому кількість незалежних курсів скорочується. Багато компаній проводять лекції в університетах та запускають власні навчальні програми, які дозволяють перехопити цікавих кандидатів на більш ранньому етапі. При цьому в містах з великим потоком кандидатів тестові завдання можуть залишатися ефективним інструментом при наборі людей на стартові позиції. Проте, рішення про їхнє використання вимагає аналізу умов локального ринку.

Пропонуючи кандидатам тестові завдання, роботодавець завжди йде на певний ризик. Якщо конкуренція серед вакансій є високою, чи не віддасть потенційний претендент перевагу компанії, яка відразу пропонує прийти на співбесіду? Людина, яка погодилась витратити час ще до першої особистої зустрічі, має бути впевненою, що зробила це не дарма. Значить, їй необхідно оперативно отримати зрозумілий і досить детальний відгук — і таку можливість може забезпечити пророблена структура завдання. Не забувайте, що якість вашого тестового завдання, швидкість відповіді кандидатам і деталізація зворотного зв'язку впливатимуть на відгуки про вашу компанію, як мінімум на локальному ринку.

  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    18 листопада
  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    1 липня
  • Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    25 червня
  • Україна, Одеса
    25 червня