Як провести ефективне співбесіду QA-інженера за 35 хвилин

Єгор Павловець методом проб і помилок розробив алгоритм, який дозволяє йому проводити співбесіди з QA-інженерами, вкладаючись в 35 (максимум - в 45) хвилин.

Читати далі...

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

Але іноді складно відмовити собі в задоволенні взяти участь в технічному співбесіді - в якості інтерв'юера. Себе випробувати та на людей подивитися з палаючими очима і зашкалює мотивацією.

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

Зазвичай, коли відкривається позиція джуніор-тестувальника, від бажаючих відбою немає. На інтерв'ю відразу помітно, що 80% претендентів реально сильно підготувалися по теорії. На будь-який стандартний питання у «сильного теоретика» завжди готова відповідь. І виходить, що з 10 осіб - 8 показують приблизно однаковий рівень.

На перших порах ця обставина була нашим головним гальмом. Так, коли починаєш копати, відразу виявляються білі плями. Але такі «розкопки», коли їх доводиться проводити в 80% випадків, віднімають значно більше часу і надовго відривають від гарячої технічної задачі по поточному проекту.

Після серії затяжних співбесід стало зрозуміло, що далі так продовжувати не можна. Проекти «горять», здобувачі не підходять, час марнується.

Після деякого аналізу ми взяли першу спробу поліпшити процес. Так - додали тестове завдання для junior-тестувальників.

Тестове завдання полягало в необхідності протестувати видозмінене додаток із прикладів додатків Android SDK, в яке ми навмисне вносили дефекти. Здобувач повинен був написати звіт по дефектам протягом тижня.

В результаті з 8 фахівців, добре освоїли теорію, відсіялися близько 6. Вибір з решти двох уже пояснювався непрямими показниками (креативність підходу до виконання тестового завдання, оформлення звіту, швидкість виконання завдання).

Одна дівчинка взагалі буквально за вихідні виконала тестове завдання, обстоював близько десятка конкурентів-чоловіків по швидкості і якості виконання. Женя, привіт!

В принципі, цей підхід відмінно працював, якби не одне «але». Тиждень. Чекати цілий тиждень - болісно довго і нудно. Хотілося наймати швидше, за допомогою яких-небудь показників, одержуваних в реальному часі прямо під час співбесіди.

Стало очевидно, що необхідно тестове завдання включати прямо в процес співбесіди. Адже все одно у нас вже є на руках додаток, в якому свідомо відомі всі дефекти.

Питання по теорії теж були ретельно перероблені. Ми вибрали 15 бліц-запитань на 15 хвилин, на скільки з них здобувач відповідає - стільки балів і йде в залік. Відомих дефектів було всього близько 10. Разом максимум 25 балів.

Вийшла своєрідна KPI (Key Performance Indicators, ключові показники ефективності) таблиця претендентів - з теорії та по практиці.

Забавно, але ніхто ні разу не зміг набрати максимум, хоча були люди, які знаходили такі дефекти, про які навіть ми не знали!

За результатами кількох десятків співбесід відразу стало очевидно, що деякі претенденти - відверті базіки, які при всьому чудовому знанні теорії не змогли знайти навіть одного-єдиного дефекту в додатку з двох екранів. І при цьому із запитом на зарплату в 2000 $!

Хлопців з перших трьох позицій на вершині списку ми і найняли до себе в команду. У процесі роботи вони дійсно проявили свій багхантерскій талант. Кожен керівник веде метрики ефективності, так ось ці хлопці знаходили від 80 до 120 дефектів на місяць в такому додатку, як Prestigio eReader.

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

Наприклад, під час швидкого опитування з теорії близько десятка чоловік просто сказали: я нічого не знаю; теорію не буду відповідати - ні на одне питання.

Після прохання протестувати додаток замітки (2 екрани і меню, з серії прикладів в Android SDK) деякі з кандидатів припустили, що ми хочемо скористатися їхньою працею протягом цих 15 хвилин, щоб самим баги не шукати. Від такої дичини в ступор впали вже ми з ейчаром.

Кожній людині, яка за своїми KPI нам точно не підходив, ми не говорили сумнозвісну фразу «ми вам передзвонимо». А відразу вказували на слабкі сторони, які потрібно підкачати, щоб професійно підрости.

Розлучалися майже друзями, оскільки давали реально потрібну для здобувача зворотний зв'язок.

Звичайно, неможливо вкластися в жорстке обмеження 35 хвилин. Але жодне наше співбесіда не тривало довше 45 хвилин.

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

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

До речі, даний KPI підхід відмінно показав себе на всіх рівнях здобувачів на QA позицію - від джуніора до сеньйора. Ми навіть питання не змінювали.

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

1. Що робить QA команда?
2. Що робить QC команда?
3. У чому різниця між QC і QA?
4. Які вам відомі техніки тестування «чорним ящиком», які також використовуються для дизайну тест-кейсів?
5. Ви використовували на практиці тестування методом «білого ящика»?
6. Розкажіть докладніше, які техніки використовуються в методі тестування «білого ящика»?
7. Назвіть обов'язкові критерії тестового плану?
8. Як визначити, що тестування реліз-кандидата завершено?
9. Напишіть команду установки Android-додатки на смартфон за допомогою командного рядка.
10. Напишіть команду видалення Android-додатки за допомогою командного рядка.
11. Ви отримали нове Android-пристрій, зробили перший його запуск, пройшли майстер настройки, але не можете підключити пристрій до комп'ютера. Що не так і як це виправити?
12. Чим ви користуєтеся з інструментів Android-розробника (з SDK і в настройках самого телефону - для розробників)?
13. Як ви фільтруєте висновок логкета, щоб отримувати тільки потрібну інформацію?
14. Що, на ваш погляд, потрібно обов'язково перевіряти в кожному Android-додатку, якщо відсутні специфікації, вимоги і т.д.?
15. Яка різниця між термінами Monkey testing і Ad hoc testing?

Колонка підготовлена за участю Наталі Провалінской