Планка для джуна-QA за 12 років: що змінилося і навіщо все це справді питають

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

Це не легенда і не «розповіді про старі добрі часи». Це була нормальна практика. Людей не вистачало, ринок ріс швидше, ніж встигали навчати, і компанії брали за здатність думати, а решти планували довчити на місці.

Сьогодні на ту саму позицію просять техніки тест-дизайну, розуміння HTTP, вміння написати SQL-запит із join, базове уявлення про XSS і SQL-ін'єкції, досвід із Postman, а часом ще й «плюсом буде автоматизація».

Питання, яке в такій ситуації виникає першим — це взагалі законно? Розберемо чесно: частина цих вимог обґрунтована, частина ні, і корисно розрізняти.

Чому планка піднялася

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

Змінилася сама робота. QA дванадцять років тому — це здебільшого людина, яка клікає інтерфейс за сценарієм і заводить баги. Сьогодні той самий джун відкриває DevTools, дивиться в Network, іде в Postman перевірити, що повернув бекенд, і в базу — переконатися, що збереглося. Не тому, що так модно, а тому, що продукт став розподіленим і половина дефектів живе не на екрані.

Скоротився час на навчання. Команди менші, релізи частіші. Раніше джун міг півроку тихо вростати поруч із сеньйором. Тепер від нього хочуть користі з другого спринту, і компанії намагаються купити цю готовність на вході.

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

Останній пункт важливий, і про нього чесно скажемо в кінці. Але спершу — про те, що в списку опинилося не дарма.

Навіщо це насправді питають

Техніки тест-дизайну

Найчастіше їх вважають теорією заради теорії: вивчив еквівалентне розбиття, розповів, забув.

Насправді техніка відповідає на єдине питання, яке вам поставлять у роботі: чому ти перевірив саме це і чому цього достатньо.

Без техніки відповідь звучить як «ну я поклацав основні сценарії». Це не аргумент — його неможливо ні перевірити, ні оскаржити. З технікою відповідь така: «поле приймає від 18 до 65, я перевірив по одному значенню з кожного класу і межі — шість тестів замість ста двадцяти, і от чому решта нічого не додасть».

Друге, менш очевидне: техніки — це спосіб вкластися в час. Тестувати все не можна ніколи. Тест-дизайн — це інструмент обґрунтованого скорочення, а не академічна дисципліна.

SQL

Найпоширеніше непорозуміння: «навіщо тестувальнику база, я ж перевіряю інтерфейс».

Інтерфейс показує те, що намалював фронтенд. Він не показує, що насправді записалося.

Класична ситуація: користувач зберігає профіль, сторінка каже «збережено», ви йдете далі. А в базі поле лишилося порожнім, бо бекенд повернув 200 на запит, який нічого не змінив. Через тиждень це знаходить клієнт.

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

Реально потрібний джуну обсяг невеликий: select з where, сортування, join на дві таблиці, count і group by. Це не «знання SQL», це чотири конструкції.

API і HTTP

Тут причина найпростіша. Основна робота джуна-QA — не знайти дефект, а локалізувати його.

«Не працює» — це не баг-репорт. Розробник витратить годину, щоб з'ясувати те, що ви могли з'ясувати за хвилину: пішов запит чи ні, що прийшло у відповідь, це 400 через ваші дані чи 500 через їхній код.

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

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

XSS, SQL-ін'єкції та базова безпека

Здається найбільш «не для джуна» пунктом. Але причина тут не в глибині, а в ціні помилки.

Пропущений баг у верстці — це баг. Пропущена XSS — це інцидент: витік даних, повідомлення користувачам, іноді штраф. Різниця не в складності, а в наслідках.

При цьому найпростіші перевірки коштують нічого. Вставити <script>alert(1)</script> у поле імені й подивитися, чи виконається. Спробувати лапку в пошуку й побачити, чи не впаде запит із помилкою бази. Це чек-лист на п'ять пунктів, який робиться за десять хвилин і закриває найдешевший клас атак.

Від джуна не чекають пентесту. Чекають, що він не пропустить очевидне.

Знання середовищ і логів

Питання про dev/staging/prod і про те, як подивитися логи, теж викликають подив. Причина знову практична: половина «багів» — це не баги, а неправильне середовище, старий білд або конфіг.

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

А що з цього — надлишок

Тепер чесна частина.

Питання про рівні моделі OSI, реплікацію в SQL Server, різницю між SIP і PRI на позиції джуна-мануальника — це не перевірка готовності до роботи. Це або списаний звідкись перелік, або спроба відсіяти хоч якось, коли відгуків двісті.

Ознака здорової співбесіди проста: на кожне питання інтерв'юер може відповісти, як це знадобиться в перший місяць роботи. «Ти будеш перевіряти дані в базі» — може. «Ти будеш налаштовувати реплікацію» — на джунській позиції навряд.

Якщо на співбесіді таких питань більшість, це говорить не про вас, а про процес найму в компанії. І це нормальна причина не шкодувати про відмову.

Що з цим робити

Планка не опуститься — попереднє співвідношення людей і вакансій не повернеться. Але список реально потрібного значно коротший, ніж виглядає у вакансіях.

Мінімум, який закриває більшість джунських співбесід:

• Тест-дизайн — еквівалентне розбиття, межі, таблиця рішень. З готовими прикладами на конкретних полях, а не визначеннями.
• HTTP — методи, класи статус-кодів, вкладка Network у DevTools, вміння сказати, на чиєму боці помилка.
• API — Postman, GET і POST, читання відповіді, перевірка того, чого немає в інтерфейсі.
• SQL — select, where, order by, join, count із group by. Чотири конструкції.
• Безпека — чек-лист із п'яти пунктів: XSS у полях вводу, лапка в пошуку, доступ до чужого запису за id в URL, маскування пароля, повідомлення про помилку, яке не розкриває існування логіна.
• Баг-репорт — і розуміння, що передумови важливіші за скриншот.

Це кілька тижнів зосередженої підготовки, а не рік навчання. Основна частина відмов трапляється не тому, що людина цього не знає, а тому, що знає у форматі «чув про це», а не «можу застосувати й пояснити навіщо».

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

---

Якщо потрібен матеріал для підготовки — у нас зібрані питання для Manual QA з розборами відповідей, окремо для junior і middle — читати можна вільно. А щоб проговорити відповіді вголос і почути оцінку, потрібен акаунт: три інтерв'ю на місяць безкоштовні.