Ніяких завдань «додому»: як компанії оцінюють знання джуніор-тестувальників

Згідно з даними Djinni, конкуренція серед кандидатів без досвіду в IT знизилася на 20 %. Водночас конкуренція на вакансії серед Manual QA, де потрібно хоча б 5 років досвіду, у жовтні вища, ніж серед кандидатів без досвіду. Так, маємо 110 кандидатів без досвід на одну вакансію проти 150 кандидатів з досвідом 5+ років на одну вакансію.

Однак і серед 110 конкурентів треба виділитися. Припустимо, ви вже оформили своє резюме за всіма правилами та дійшли до етапу тестового завдання й технічної співбесіди. Як під час перевірки показати себе з найкращого боку? Розповідають фахівці з N-iX, Uklon, Infopulse та Uptech.

Якими бувають тестові для тестувальників та як їх оцінюють

Більшість компанії не дає QA тестове завдання «додому»: від кандидатів очікують виконання таски безпосередньо під час інтерв’ю. Це потрібно для того, щоб подивитися на реальні скіли й те, як спеціаліст уміє розв’язувати завдання у реальному часі.

Саме так тестують кандидатів у N-iX. Зазвичай їм пропонують такі завдання:

• тест на знання SQL (вміння використати JOIN або GROUP BY);
• деякі функціональні вимоги до використання BVA та EP;
• тестування екрана входу до системи (будь-який приклад);
• тестування будь-якого екрана на функціональні, UI- та юзабіліті-помилки.

Тестове завдання від QA джуніор-рівня оцінюють таким чином:

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

Святослав Дюганчук, Test Engineer в N-iX, додає, що перед перевіркою тестового завдання в резюме або у портфоліо дивляться, який досвід має кандидат у написанні тест-кейсів:

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

Святослав Дюганчук, Test Engineer в N-iX

В Uklon також відійшли від підходу давати тестове завдання кандидату «додому»:

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

Віталій Павліченко, QA Technical Lead в Uklon

Спеціаліст поділився, що, за їхніми спостереженнями, якщо дати тестове завдання «додому», людині з імовірністю в 90 % допомагатимуть або друзі, або нейромережі, і зрештою це не буде ефективно:

«Тому ми тестуємо кандидатів одразу на зустрічі, “по-гарячому”. Як тестові завдання, так і запитання будують на очікуваннях від позиції. Якщо йдеться про джуніора, то це інженер, який здатний ефективно слідувати процесам, що вже склалися в команді, під невеликим рев’ю (або зовсім без нього). Який досить добре знає теорію. І якщо казати про тестові завдання для QA-інженерів, то вони завжди пов'язані з практичним застосуванням цих знань, а також навичок комунікації та розв'язання проблем».

Чому може не бути тестових та які знання перевіряють на технічному інтерв’ю

Якщо ви вже встигли засмутитися, то не варто. Існують і інші опції. Наприклад, в компанії Infopulse не практикують виконання тестових завдань для кандидатів на посаду тестувальника: на думку компанії, інформацію про знання та навички кандидата можна перевірити під час технічного інтерв’ю.

Наразі ми працюємо над стандартизацією проведення інтерв’ю через систему Greenhouse, в якій використано шаблони запитань за скіл-матрицею, яка є власною розробкою компанії Infopulse. Ми не вбачаємо потреби у наданні жодних тестових завдань під час процедури добору кандидатів

Олексій Остапов, Head of Test Automation Subpractice в Infopulse

Оскільки джуніор QA здебільшого не має багатого практичного досвіду, в компанії Uptech до уваги беруть знання базової QA-теорії:

• навіщо потрібне тестування;
• що таке якість;
• який життєвий цикл бага;
• склад баг-репортів;
• чеклісти й тест-кейси;
• базові техніки тест-дизайну.

Важливим є розуміння та вміння використовувати широковживані інструменти для тестування, як-от Swagger, Postman, проксі, девтулзи тощо.

Добре, коли кандидат мінімум цікавиться автоматизацією тестування (оскільки QA-інженери нашого департаменту розвиваються як General QA), вміє тестувати мануально та за потреби може автоматизувати регресію

Олексій Попов, Engineering Manager / QA Engineer в Uptech

В N-iX поділилися списком необхідних знань для джуніор-тестувальників:

• основи архітектури програмного забезпечення (клієнт-сервер, фронтенд-бекенд);
• SDLC на практиці;
• знання та досвід роботи з основними техніками проєктування тестів;
• знання та досвід роботи з основними типами тестування (functional, smoke, regression, performance, acceptance, UI, usability);
• best practices у написанні тест-кейсів, TC-шаблонів;
• best practices у внесенні багів, Bug template;
• знання та використання принципів тестування.

Надія Третяк, Senior Team Manager в N-iX, каже, що джуніор-кандидат також повинен:

• добре знати базові техніки тестування й тестові типи;
• мати аналітичні скіли, щоб тестувати вичерпність вимог (повноту, недвозначність, неповторюваність);
• мати структуроване мислення;
• вміти користуватися інструментами для написання SQL statements;
• бонусом буде, якщо джуніор має досвід з інструментами проджект-менеджменту й тест-менеджмент-тулзами для трекінгу багів і тест-кейсів.

Ще дуже добре, якщо джуніор має базове розуміння бекенд-тестування через Postman. І завжди під час виконання тестового важливо зрозуміти, чи джуніор озвучив найпріоритетніші тест-кейси, баги. В такому разі видно ефективне використання часоресурсів чи ні

Надія Третяк, Senior Team Manager в N-iX

Чи важливі софт-скіли для тестувальника

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

В Infopulse виділяють дві основні риси:

• Чесність. Багато людей в резюме згадують багато речей, а коли в процесі розмови просимо розповісти детальніше — людина губиться, бо або не знає технологію або користувалася нею тривалий час. Це «червоний прапорець».
• Прямолінійність. Якщо кандидат чогось не знає, він може сказати про це відверто. Це економить час та демонструє повагу до інтерв'юера. Якщо кандидат просто хвилюється, ми завжди намагаємося допомогти, направити хід думок. Але з досвіду, що менше людина впевнена у тих компетенціях, які вона прагне видати за правду, то більше буде стрес-фактору під час розмови. Легко відрізнити хвилювання та ситуацію, коли людина не має знань.

Святослав Дюганчук, Test Engineer в N-iX, ділиться, що на його практиці бували випадки, коли кандидат не знає теорії, але практичні завдання виконує дуже добре. І тут розв’язання ситуації йде на розсуд менеджера — він звертає увагу на софт-скіли та потім ухвалює рішення.

Поради для джуніорів від компаній

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

Віталій Павліченко, QA Technical Lead в Uklon

Поради для джуніор-тестувальників від Святослава Дюганчука, Test Engineer в N-iX:

• Прийдіть до розуміння того, що було вивчено, — вмійте поєднати теорію з практикою. Щоб не виникало такого, що є теоретичні знання, але не зрозуміло, навіщо вони й де їх можна використовувати.
• Створіть портфоліо. Це можуть бути приклади тест-кейсів або баг-репортів, які можна показувати (не підпадають під NDA) в GitLab або GitHub. Це також означатиме, що ви вмієте працювати з цими інструментами.
• Створіть собі дошку в JIRA та вчіться там працювати. Це безплатно, якщо в команді до 10 користувачів.
• Пишіть запити до бази даних: як прості, так і запити, де використано дві або більше таблиць.
• Вчіться тестувати API. За останні два-три роки з’явилося більше застосунків, де необхідне тестування бекенду. Тому розуміти, вміти тестувати API й використовувати Postman буде дуже великим плюсом.

Раджу орієнтуватися на ISTQB-теорію, поставити безоплатні тули для написання SQL-стейтментів, потестити відкриті АРІ через Postman, поставити Swagger, записатися й пройти якісні курси з Manual and Automation QA. Ідеально — поволонтерити й потестити для когось чийсь сайт і набути досвіду

Надія Третяк, Senior Team Manager в N-iX

Спеціалістка каже, що також як варіант можна тренуватися у написанні тест-кейсів в Excel за будь-яким вебзастосунком — це допоможе набити руку. Ще ідея для втілення: передивитися відео на YouTube про клієнт-серверну архітектуру та розібрати в ріквест-ріспонс.

І наостанок, поради для тестувальників-початківців від Uptech:

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