«Якщо кандидат каже про тестування як легкий спосіб увійти в ІТ, для мене це одразу стоп-сигнал», – Олексій Станкевич

Manual Software Test Engineer – позиція, яку традиційно  шукають на джоб-платформах тестувальники-початківці.

На шляху до омріяного оферу новачок проходить первинну співбесіду з рекрутером, а після на нього чекає технічне інтерв’ю з техлідом. Саме технічна частина викликає найбільше переживань та напруги. Але як то кажуть, попереджений значить озброєний. Тому ми вирішили розпитати про тонкощі проходження технічної співбесіди техліда департаменту QA/Software Testing у CHI Software Олексія Станкевича.

Олексію, з чого ти починаєш співбесіду?

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

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

• «Тому що це легкий спосіб увійти в ІТ»
• «Я хочу стати розробником (або менеджером проєктів), але вирішив почати з тестування, так легше»
• «На тестуванні можна швидко піднятися й більше заробляти»

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

Вже після цього розпочинаю основну частину з технічними питаннями.

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

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

• Як опрацювати вимоги до продукту? Іншими словами, як перевірити надані до продукту вимоги на здатність до тестування?
• Який життєвий цикл тестування має продукт? Маються на увазі етапи планування й контролю, аналізу та дизайну, імплементації та виконання, оцінки критеріїв виходу й звітності.
• Які знаєш рівні тестування? Серед них компонентний, інтеграційний, системний, приймальний.
• Які існують види тестування? 
• Які техніки тест-дизайну ти знаєш? Тобто моделювання набору тестових випадків – тест-кейсів.
• Перелічи популярні системи баг-трекінгу. Основними є Jira, Trello, RedMine.
• Також ряд питань про основи ведення тестової документації.

Що далі?

Пропоную щось на логіку та практику. Наприклад, описати рівні тестування на побутовому рівні. Це може бути пральна машина. Давайте разом її поетапно розберемо згідно з рівнями тестування:

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

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

Системний рівень. Машинку зібрали, порошок засипали, електропроводи та шланги підключили, закинули речі та натиснули кнопку старту. Чи розпочалося прання? Чи качається вода? Чи не висипається порошок з відсіку? Тобто повністю слідкуємо за процесом. На цьому ж етапі перевіряємо, чи співпадають дії, описані в інструкції, з тими, що виконали ми.

Приймальний рівень. Віддаємо готову пральну машину користувачеві й отримуємо від нього фідбек щодо роботи агрегату.

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

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

До видів можемо додати й стрес-тестування: натискаємо на ручку з усієї сили й слідкуємо за тим, як вона себе поведе – зламається чи витримає тиск.  Або згинаємо її за принципом «80 на 20», тобто не в повну силу, а відсотків на 80. Таким чином перевіряємо гнучкість ручки.

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

Які ще практичні задачі ти можеш запропонувати на співбесіді?

Щоб з’ясувати, як кандидат розуміє, що таке баг, баг-репорт та як він його пояснює, я прошу описати певний баг. Наприклад, не активується мейл у формі для відправки листа. Якщо кандидат назве цей баг типу «Поле email пусте», то це буде непрофесійно. Пусте? То й що? Розробник має розуміти суть проблеми навіть із назви. 

Такий баг слід було назвати на кшталт «Реєстрація > поле email > відсутня валідація на пусте поле». І це елементарно, але дуже показово. Водночас в описі багу має бути фактичний результат (що саме наразі працює некоректно) та очікуваний результат (як має бути після виправлення).

На що звертаєш увагу після технічних питань?

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

Яку найголовнішу пораду даси новачкам, які тільки розпочали свій шлях у тестуванні й чекають на перші співбесіди?

Розуміти, що перші інтерв’ю можуть бути невдалими. Мій досвід тому приклад. Я прийшов у тестування після психологічної освіти та танцювальної кар’єри. Потім зрозумів, що шукаю стабільності та розвитку в новій сфері. Обрав ІТ, визначився з напрямом – тестування. 

Прийшов на свою першу співбесіду після курсів і отримав чітку відповідь інтерв’юера: «Ти ще не готовий». Я поцікавився, як зрозуміти, що ти вже готовий. На що він відповів: «Коли бачитимеш будь-які, навіть найнепомітніші неточності навкруги, можеш сміливо ступати на шлях тестувальника». Так і сталося. Незабаром я став помічати дрібні помилки в елементарних рекламних об’явах у транспорті.

І ще – прокачуй свої хард скіли. Щодо тестувальників існує стереотип, що вони просто клікають мишкою, «гуляючи» по додатку чи веб-сайту, який створили розробники, та зовнішньо чи інтуїтивно оцінюють роботу продукту. Такий візуально-інтуїтивний етап, звичайно, також існує, але в цілому робота тестувальника – це великий багаж технічних знань та умінь.

Про них ми з моїм колегою Олександром Горшковим розповідаємо на курсі Manual Software Engineering. На курсі ти отримаєш все необхідне, щоб претендувати на позицію Junior Software Testing Engineer: структуровану теорію, методології та інструменти. Приєднуйся!