Класичні задачі співбесід: поле, форма, олівець

Зміст

«Протестуйте це поле вводу». «Як би ви тестували форму логіну?» «Ось олівець — ваші дії?» Ці задачі звучать на співбесідах QA десятиліттями, і кандидати досі на них сипляться — не тому, що не знають технік, а тому, що не вміють зібрати техніки в структуровану відповідь. Інтерв'юер не чекає повного переліку кейсів: він за п'ять хвилин дивиться, як ти думаєш — чи є в голові система, чи лише випадковий набір «а ще можна ввести емодзі».

Ця глава — фінальна в розділі про тест-дизайн і збирає докупи все, що було до неї: класи еквівалентності, граничні значення, таблиці рішень, переходи станів і досвідні техніки. Тут — повний розбір задач «протестуй X»; коли інші глави сайту згадують такі задачі, вони посилаються сюди.

Що насправді перевіряє задача «протестуй X»

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

Тому оцінюється не кількість названих кейсів, а поведінка:

Чи уточнює кандидат контекст, перш ніж відповідати. Питання «а що це за поле і хто ним користується?» — уже плюс.
Чи є структура. Відповідь рухається від важливого до другорядного, кейси згруповані за технікою чи типом перевірки, а не вискакують хаотично.
Чи стоїть за кейсами техніка. «Перевірю 0, 1, 100 і 101» цінне тоді, коли кандидат може пояснити: це межі діапазону, баги люблять межі.
Чи вміє кандидат зупинитися й аргументувати, чому набір достатній. Вичерпне тестування неможливе — це один із семи принципів тестування, і задача «протестуй X» перевіряє, чи кандидат живе за ним, а не лише цитує.

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

Структура сильної відповіді: уточнення → пріоритети → техніки

Сильна відповідь на будь-яке «протестуй X» має однаковий скелет:

Крок 1 — уточнення. Два-три питання, не допит на пів години: що це за об'єкт і навіщо він (поле кількості товару? пошук? коментар?); хто користувач; чи є вимоги або обмеження (діапазон, обов'язковість, формат); де межа відповідальності (тестуємо лише UI чи й серверну валідацію?). Якщо інтерв'юер каже «вимог немає, вигадуйте самі» — це теж відповідь: тоді кандидат явно фіксує власні припущення («припустімо, це поле кількості товару, ціле число від 1 до 100») і тестує вже їх. Озвучене припущення — ознака зрілості; мовчазне — джерело суперечок.

Крок 2 — пріоритети. Спершу — те, заради чого об'єкт існує: базовий позитивний сценарій. Поле приймає валідне значення і зберігає його; логін пускає користувача з правильними даними; олівець пише. Кандидат, який почав з SQL-ін'єкцій і забув перевірити, що поле взагалі працює, провалив пріоритезацію — а саме вона в реальному спринті вирішує, що встигнуть перевірити до релізу. Далі — негативні сценарії за спаданням імовірності та болючості наслідків.

Крок 3 — техніки, названі вголос. Не «ще перевірю отаке», а «за класами еквівалентності тут три невалідні класи, з кожного беру одного представника». Саме прив'язка кейсів до технік відрізняє системну відповідь від начитаного переліку. Який арсенал до якого типу задачі — окрема тема глави «Вибір і комбінування технік».

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

«Протестуйте поле вводу»

Розберімо на робочому припущенні: поле «кількість товару» в кошику, ціле число від 1 до 100, обов'язкове. Далі — техніки по черзі, кожна відповідає на своє питання.

Техніка	На яке питання відповідає	Приклади кейсів
Класи еквівалентності	Які групи значень система обробляє однаково?	валідне (42); менше за мінімум; більше за максимум; не число; порожнє
Граничні значення	Де саме проходить межа і чи немає off-by-one?	0, 1, 100, 101
Небезпечні дані	Що ламає обробку рядка як такого?	пробіли, `-1`, `2.5`, `1e2`, ведучі нулі, дуже довгий рядок, кирилиця, емодзі
Передбачення помилок	Де розробники зазвичай помиляються саме тут?	вставка з буфера замість набору, зміна значення стрілками, швидке подвійне збереження

Класи еквівалентності дають каркас: один представник з валідного класу і по одному з кожного невалідного — причому кожен невалідний окремим тестом, інакше перший спрацьований захист замаскує решту. Граничні значення уточнюють каркас там, де баги живуть найчастіше: для діапазону 1–100 це чотири точки — 0, 1, 100, 101. Класика «скільки тестів для поля 1–100» розібрана в главі «Граничні значення».

Третій шар — дані, які ламають не бізнес-правило, а саму обробку вводу: порожній рядок проти рядка з пробілів, +1 і -1, дробові, наукова нотація 1e2, значення довжиною в тисячі символів, невидимі unicode-символи. Повний каталог такої «небезпечної класики» — у главі «Тестові дані». Сюди ж — рядки на кшталт ' OR 1=1 та <script>: на співбесіді досить сказати, що поле має нейтралізувати службові символи, а не виконувати їх; самі атаки — тема розділу про безпеку.

Окремо — питання рівнів: валідація на фронтенді (атрибути type="number", min, max, required) не скасовує серверної, бо запит можна надіслати повз UI. Сильний кандидат промовляє це явно: «перевірю, що межі тримає не лише браузер, а й API». Це той абзац відповіді, який відрізняє middle від trainee.

Задача про поле має пряме продовження в автоматизації: класи й межі природно лягають у параметризований тест, де кожен невалідний клас — окремий кейс з власною назвою:

// Кожен невалідний клас — окремий тест: перший фейл не ховає решту
const invalidQuantities = [
  { value: '0', reason: 'нижче мінімуму' },
  { value: '101', reason: 'вище максимуму' },
  { value: '', reason: 'порожнє обовʼязкове поле' },
  { value: 'abc', reason: 'не число' },
  { value: '2.5', reason: 'дробове замість цілого' },
];

for (const { value, reason } of invalidQuantities) {
  test(`поле «кількість» відхиляє: ${reason}`, async ({ page }) => {
    await page.goto('/cart');
    await page.getByLabel('Кількість').fill(value);
    await page.getByRole('button', { name: 'Зберегти' }).click();
    await expect(page.getByRole('alert')).toContainText('від 1 до 100');
  });
}

«Протестуйте форму логіну»

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

Комбінації входів — таблиця рішень. Дві умови (логін валідний/ні, пароль валідний/ні) дають чотири правила: пускати лише при обох валідних. До них — життєві варіації невалідного: неіснуючий користувач, чужий пароль до існуючого логіна, правильний пароль в іншому регістрі, пробіли на краях (обрізаються чи ні — питання до вимог). Як будувати й згортати такі комбінації — глава «Таблиці рішень».

Стани і переходи. Логін — це машина станів: розлогінений → залогінений → сесія протухла → повторний вхід. Перевірки: куди редіректить після входу; що бачить залогінений користувач на сторінці логіну; що стається з відкритою вкладкою після логауту в сусідній; чи повертає система на сторінку, з якої вигнало по таймауту сесії. Механіка сесій і cookie розібрана в главі «Кукі, сесії та сховище браузера», техніка — у «Переходах станів».

Безпека — оглядово, але помітно. Пароль маскується і не потрапляє в URL; повідомлення про помилку не підказує, що саме неправильне — «невірний логін чи пароль», інакше форма стає інструментом перебору імен користувачів (user enumeration); після серії невдалих спроб — обмеження частоти або блокування (чи є така вимога — питання на крок уточнення). Глибина тут не потрібна — потрібен сигнал, що кандидат знає про цей вимір; деталі живуть у розділі про безпеку.

UX і периферія. Вхід по Enter, фокус на першому полі, коректна поведінка автозаповнення браузера, «запам'ятати мене», лінк відновлення пароля (це окремий флоу — на співбесіді досить його назвати, не розгортаючи).

Порядок озвучення — знову за пріоритетом: спершу чотири комбінації таблиці рішень, потім стани сесії, потім безпека і UX. Це і є відповідь «за техніками», а не потік свідомості.

Фізичні об'єкти: олівець, ліфт, банкомат

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

Олівець. Крок уточнення тут — головний: олівець для кого? Шкільний, художній, будівельний? Від відповіді залежить усе: для художника критична градація твердості, для дитини — нетоксичність покриття. Далі перевірки групуються природно: функціональні (пише на папері, лінія суцільна, стирається гумкою, стругається); характеристики (твердість відповідає маркуванню, довжина/діаметр — заявленим); нефункціональні (міцність грифеля при падінні, зручність тримати годину, стійкість напису до води); негативні та експлуатаційні (волога, спека, тиск понад норму); сумісність (типи паперу, стандартні стругачки). Інтерв'юер чує знайому структуру: класи умов використання, межі характеристик, негативні сценарії — техніки ті самі, змінився лише об'єкт.

Ліфт. Це задача на переходи станів: стоїть з відчиненими дверима → зачиняє двері → їде → відчиняє. Цікаві місця — конфліктні події: виклик під час руху, кнопка «відчинити» в момент зачинення, одночасні виклики з різних поверхів, перевантаження, аварійна зупинка, поведінка при зникненні живлення. Плюс нефункціональне: час очікування, місткість, доступність для людей на візках.

Банкомат. Задача на таблиці рішень (картка валідна × PIN правильний × коштів достатньо × ліміт не вичерпано) плюс стани (сесія з таймаутом: що стається з карткою і грошима, якщо користувач пішов) плюс безпека (ліміт невдалих спроб PIN — класично три, повернення картки, екран не показує баланс стороннім). Гроші роблять пріоритети очевидними: спершу сценарії, де користувач може втратити кошти або картку.

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

Скільки кейсів достатньо

Улюблене продовження інтерв'юера: «то скільки тестів ви напишете для цього поля?» Пастка в тому, що правильна відповідь — не число, а спосіб його отримати.

Аргументація будується так: вичерпний перебір неможливий і не потрібний — усередині класу еквівалентності всі значення рівноцінні, тож достатньо по одному представнику з кожного класу плюс точки на межах плюс кейси під конкретні ризики. Для поля 1–100 це виходить приблизно так: один валідний представник, межові 0/1/100/101 (представники валідного класу на межах і невалідних одразу за ними), по одному на кожен нечисловий клас (порожнє, текст, дробове) — разом 8–9 кейсів. Число саме по собі нічого не варте; вага у фразі «кожен кейс ловить свій клас дефектів, жоден не дублює інший».

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

Типові помилки

Одразу сипати кейсами. Виглядає як досвід і швидкість, а насправді — відсутність системи: без уточнень кандидат тестує об'єкт, якого немає в задачі, і інтерв'юер бачить хаотичний перелік замість методу.
Назвати 50 кейсів без пріоритетів. Виглядає як ретельність, а насправді — нездатність відрізнити критичне від екзотики. Реальний спринт не дає часу на все; кандидата без пріоритетів доведеться пріоритезувати комусь іншому.
Почати з екзотики й забути happy path. Емодзі, ін'єкції, довгі рядки — а «поле приймає валідне значення і зберігає його» так і не прозвучало. Виглядає як глибина, а насправді — провалений перший пріоритет.
Промовляти назви технік без застосування. «Тут я б використав класи еквівалентності» — і жодного класу. Виглядає як знання теорії, а насправді — завчені слова; інтерв'юер завжди попросить показати класи, і пауза після цього питання коштує дорожче, ніж якби техніку не згадували.
Тестувати лише UI. Кандидат перевіряє браузерну валідацію і зупиняється, хоча запит повз UI понесе на сервер будь-що. Виглядає як повний розбір поля, а насправді — половина поверхні.
Мовчазні припущення. Кандидат вирішив, що поле — це пошук, інтерв'юер мав на увазі кількість товару; десять хвилин відповіді — у смітник. Озвучене припущення коштує одне речення і рятує всю відповідь.

Підсумок

Задача «протестуй X» перевіряє метод, а не пам'ять: уточнення → пріоритети → техніки → аргументована межа достатності.
Перше питання завжди про контекст і вимоги; якщо вимог немає — припущення формулюються вголос.
Перший кейс — завжди базовий позитивний сценарій; негативні йдуть за спаданням ризику.
Кожен кейс прив'язаний до техніки й ловить власний клас дефектів; кейс, який нічого нового не ловить, — зайвий.
Кількість тестів не називається з повітря — вона виводиться з класів, меж і ризиків, і так само аргументовано скорочується, коли часу мало.

Що питають на співбесіді

Типові формулювання: «протестуйте це поле вводу», «як би ви тестували форму логіну?», «протестуйте олівець / ліфт / банкомат / двері», «скільки тестів потрібно для поля з діапазоном 1–100?», «а якщо у вас час лише на три перевірки?», «які техніки ви щойно застосували?».

Інтерв'юер дивиться на порядок дій: чи прозвучали уточнювальні питання до першого кейсу; чи почалася відповідь з позитивного сценарію; чи згруповані кейси за техніками і чи може кандидат назвати техніку за власним кейсом; чи вміє він зупинитися й пояснити, чому набір достатній. Окремий сигнал сеньйорності — згадка про рівні (UI проти API), про ризик як критерій глибини і спокійна реакція на «а тепер скоротіть удвічі». Формат подачі відповіді на співбесіді загалом — тема розділу про співбесіди; тут головне, що змістовна частина відповіді будується рівно з технік цього розділу.

Джерела

Силабус ISTQB CTFL 4.0 — глава застосовує розділи 4.2 (Black-Box Test Techniques) і 4.4 (Experience-based Test Techniques).
MDN: атрибути елемента input — довідник обмежень поля на рівні браузера.
MDN: клієнтська валідація форм — чому фронтенд-валідація не заміняє серверну.
OWASP Authentication Cheat Sheet — канонічні вимоги до форм автентифікації, включно з повідомленнями про помилки.
Playwright: параметризація тестів — як класи еквівалентності перетворюються на набір автотестів.

Що насправді перевіряє інтерв'юер, коли просить «протестуйте це поле вводу»?

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

З чого має починатися відповідь на будь-яке «протестуй X»?

З уточнення, а не з кейсів. Два-три питання, не допит на пів години: що це за об'єкт і навіщо він; хто користувач; чи є вимоги або обмеження (діапазон, обов'язковість, формат); де межа відповідальності — тестуємо лише UI чи й серверну валідацію. Питання «а що це за поле і хто ним користується?» — уже плюс у очах інтерв'юера, бо показує, що кандидат не кидається тестувати об'єкт, якого немає в задачі. Далі скелет однаковий для будь-якого об'єкта: уточнення → пріоритети → техніки → межа достатності.

Інтерв'юер відповідає: «вимог немає, вигадуйте самі». Що робити?

Це теж відповідь: кандидат явно фіксує власні припущення й тестує вже їх. Наприклад: «припустімо, це поле кількості товару в кошику, ціле число від 1 до 100, обов'язкове» — одне речення, і далі вся відповідь має точку опори. Озвучене припущення — ознака зрілості, мовчазне — джерело суперечок: якщо кандидат подумки вирішив, що поле — це пошук, а інтерв'юер мав на увазі кількість товару, десять хвилин відповіді йдуть у смітник. Той самий принцип працює і в реальному спринті з неповними вимогами.

Який кейс має прозвучати першим і чому?

Базовий позитивний сценарій — те, заради чого об'єкт існує: поле приймає валідне значення і зберігає його, логін пускає користувача з правильними даними, олівець пише. Кандидат, який почав із SQL-ін'єкцій і забув перевірити, що поле взагалі працює, провалив пріоритезацію — а саме вона в реальному спринті вирішує, що встигнуть перевірити до релізу. Після позитивного сценарію йдуть негативні — за спаданням імовірності та болючості наслідків.

Протестуйте поле «кількість товару» з діапазоном від 1 до 100. Як побудуєте відповідь?

Чотири шари, кожен від своєї техніки. Класи еквівалентності дають каркас: валідне значення (42), менше за мінімум, більше за максимум, не число, порожнє — по одному представнику з кожного класу. Граничні значення уточнюють каркас там, де баги живуть найчастіше: 0, 1, 100, 101. Третій шар — небезпечні дані, які ламають не бізнес-правило, а саму обробку рядка: пробіли, -1, 2.5, 1e2, ведучі нулі, дуже довгий рядок, кирилиця, невидимі unicode-символи; сюди ж ' OR 1=1 і <script> — досить сказати, що поле має нейтралізувати службові символи, а не виконувати їх. Четвертий — передбачення помилок: вставка з буфера замість набору, зміна значення стрілками, швидке подвійне збереження. І окремо про рівні: перевірю, що межі тримає не лише браузер, а й API. Завершити — межею достатності: набір покриває всі класи, межі та головні ризики.

Скільки тестів потрібно для поля з діапазоном 1–100?

Пастка в тому, що правильна відповідь — не число, а спосіб його отримати. Вичерпний перебір неможливий і не потрібний: усередині класу еквівалентності всі значення рівноцінні, тож достатньо по одному представнику з кожного класу, плюс точки на межах, плюс кейси під конкретні ризики. Для поля 1–100 це один валідний представник, межові 0/1/100/101, по одному на кожен нечисловий клас (порожнє, текст, дробове) — разом 8–9 кейсів. Число саме по собі нічого не варте; вага у фразі «кожен кейс ловить свій клас дефектів, жоден не дублює інший».

Чому кожен невалідний клас треба перевіряти окремим тестом?

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

Чи достатньо перевірити, що браузер не пропускає невалідні значення?

Ні — це половина поверхні. Атрибути на кшталт type="number", min, max, required працюють лише в UI, а запит можна надіслати повз браузер — через curl, Postman чи власний скрипт, — і тоді єдиний захист це серверна валідація. Тому фронтенд-валідація не скасовує серверної, і сильний кандидат промовляє це явно: «перевірю, що межі тримає не лише браузер, а й API». Саме цей абзац відповіді відрізняє middle від trainee.

Як би ви тестували форму логіну?

Скелет той самий — уточнення, пріоритети, техніки, — але набір технік інший, бо тут два поля, кнопка, стан сесії й безпекові наслідки. Комбінації входів — таблиця рішень: логін валідний/ні × пароль валідний/ні дає чотири правила, пускати лише при обох валідних; до них життєві варіації — неіснуючий користувач, чужий пароль до існуючого логіна, правильний пароль в іншому регістрі, пробіли на краях. Стани й переходи: розлогінений → залогінений → сесія протухла → повторний вхід; куди редіректить після входу, що бачить залогінений на сторінці логіну, що стається з відкритою вкладкою після логауту в сусідній. Безпека оглядово: пароль маскується і не потрапляє в URL, повідомлення про помилку не підказує, що саме неправильне, після серії невдалих спроб — обмеження частоти. Плюс UX: вхід по Enter, фокус на першому полі, автозаповнення, «запам'ятати мене». Порядок озвучення — за пріоритетом: спершу чотири комбінації, потім стани, потім безпека і UX.

Чому повідомлення про помилку логіну не має уточнювати, що саме неправильне — логін чи пароль?

Бо інакше форма стає інструментом перебору імен користувачів (user enumeration): якщо на неіснуючий логін система каже «користувача не знайдено», а на існуючий — «невірний пароль», зловмисник дізнається, які акаунти існують, ще до жодної вдалої спроби. Правильна поведінка — однакове повідомлення «невірний логін чи пароль» для всіх невалідних комбінацій. На співбесіді тут не потрібна глибина — потрібен сигнал, що кандидат знає про цей вимір; деталі атак — тема розділу про безпеку.

Як підійти до задачі «протестуйте олівець»?

Головний крок тут — уточнення: олівець для кого? Шкільний, художній, будівельний — від відповіді залежить усе: для художника критична градація твердості, для дитини — нетоксичність покриття. Далі перевірки групуються природно: функціональні (пише на папері, лінія суцільна, стирається гумкою, стругається); характеристики (твердість відповідає маркуванню, довжина й діаметр — заявленим); нефункціональні (міцність грифеля при падінні, зручність тримати годину, стійкість напису до води); негативні та експлуатаційні (волога, спека, тиск понад норму); сумісність (типи паперу, стандартні стругачки). Інтерв'юер має почути знайому структуру: класи умов використання, межі характеристик, негативні сценарії — техніки ті самі, змінився лише об'єкт.

«Протестуйте ліфт» — яка техніка тут головна?

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

Як розкласти задачу «протестуйте банкомат»?

Це комбінація трьох технік. Каркас — таблиця рішень: картка валідна × PIN правильний × коштів достатньо × ліміт не вичерпано. Далі стани: сесія з таймаутом — що стається з карткою і грошима, якщо користувач пішов посеред операції. І безпека: ліміт невдалих спроб PIN (класично три), гарантоване повернення картки, екран не показує баланс стороннім. Гроші роблять пріоритети очевидними: спершу сценарії, де користувач може втратити кошти або картку, і лише потім усе інше.

«А якщо у вас час лише на три перевірки?» — як відповідати?

Ріжемо за ризиком, промовляючи ціну кожного скорочення. Залишаються: валідне значення (без нього фіча мертва — все інше не має сенсу), одна межа (найімовірніший баг — off-by-one), один невалідний клас із найгіршим наслідком. Уміння скоротити набір, пояснивши, які класи лишилися непокриті й чим це загрожує, цінується вище за вміння його роздути — бо саме таке скорочення тестувальник робить перед кожним релізом. Це дзеркальна перевірка зрілості до питання «скільки тестів потрібно».

«Які техніки ви щойно застосували?» — навіщо інтерв'юер це питає?

Він перевіряє, чи кейси виросли з технік, чи техніки приліплені до кейсів заднім числом. Сильна відповідь прив'язує кожну групу кейсів до техніки ще під час переліку: «за класами еквівалентності тут три невалідні класи, з кожного беру одного представника», «0 і 101 — це точки одразу за межами діапазону». Якщо ж кандидат промовив «тут я б використав класи еквівалентності» і не назвав жодного класу, це питання його топить: пауза після нього коштує дорожче, ніж якби техніку взагалі не згадували. Правило просте: назвав техніку — покажи її застосування на своєму ж кейсі.

Назвіть типові провали кандидатів у задачах «протестуй X».

Їх шість, і кожен виглядає краще, ніж є. Одразу сипати кейсами — виглядає як досвід, а насправді відсутність системи: без уточнень тестується об'єкт, якого немає в задачі. Назвати 50 кейсів без пріоритетів — виглядає як ретельність, а насправді нездатність відрізнити критичне від екзотики. Почати з емодзі та ін'єкцій і забути happy path — виглядає як глибина, а насправді провалений перший пріоритет. Промовляти назви технік без застосування — виглядає як знання теорії, а насправді завчені слова. Тестувати лише UI — виглядає як повний розбір, а насправді половина поверхні, бо запит повз UI понесе на сервер будь-що. І мовчазні припущення — кандидат тестує не той об'єкт, який мав на увазі інтерв'юер, хоча озвучення припущення коштує одне речення.

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

Кейс 1. «Протестуйте поле вводу»: транскрипт із розміткою кроків

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

Інтерв'юер: Ось поле вводу. Протестуйте його.

Кандидат: Спершу пара питань. Що це за поле і хто ним користується? Чи є вимоги — діапазон, обов'язковість, формат?

Інтерв'юер: Вимог немає, вигадуйте самі.

Кандидат: Тоді фіксую припущення: це поле «кількість товару» в кошику, ціле число від 1 до 100, обов'язкове. Починаю з головного — поле приймає валідне значення, скажімо 42, і зберігає його. Далі за класами еквівалентності: чотири невалідні класи — менше за мінімум, більше за максимум, не число, порожнє — і з кожного беру одного представника окремим тестом, щоб перший спрацьований захист не замаскував решту. Межі уточнюю граничними значеннями: 0, 1, 100, 101. Третій шар — дані, що ламають саму обробку вводу: рядок із пробілів, 2.5, 1e2, дуже довгий рядок, невидимі unicode-символи; службові послідовності на кшталт ' OR 1=1 поле має нейтралізувати, а не виконувати. І окремо перевірю, що межі тримає не лише браузер, а й API — запит можна надіслати повз UI. Цей набір покриває всі класи, всі межі й головні ризики; глибше пішов би, якби поле стосувалося грошей чи безпеки.

Чому ця відповідь набирає бали:

Питання до першого кейсу. Кандидат не тестує об'єкт, вигаданий у власній голові, — а коли вимог не дали, озвучує припущення одним реченням. Тепер навіть якщо інтерв'юер мав на увазі інше поле, відповідь усе одно зарахується: метод видно.
Перший кейс — позитивний. «Поле приймає 42 і зберігає» прозвучало до всієї екзотики. Це і є пріоритезація, яку інтерв'юер шукає: без працюючого happy path решта не має сенсу.
Кожна група кейсів названа технікою. Не «ще перевірю отаке», а «за класами еквівалентності — чотири невалідні класи». Питання «які техніки ви щойно застосували?» кандидата вже не заскочить.
Фінальна фраза — межа достатності. Відповідь не обірвалася, коли скінчилися ідеї, — вона завершилась аргументом про покриття і ризик. Це різниця між «поки не висохне маркер» і мисленням покриттям.

Кейс 2. Форма логіну: таблиця рішень → параметризований тест

Дві умови — логін валідний/ні, пароль валідний/ні — дають чотири правила. Це каркас відповіді на співбесіді й водночас готовий план автотестів.

Правило	Логін	Пароль	Очікування
1	валідний	валідний	вхід, редірект у кабінет
2	валідний	невалідний	відмова, спільне повідомлення
3	невалідний	валідний	відмова, те саме повідомлення
4	невалідний	невалідний	відмова, те саме повідомлення

Три негативні правила природно лягають у параметризований тест — кожне правило окремим кейсом, а «те саме повідомлення» перетворюється на асерт:

// Правила 2–4 таблиці рішень: відмова + однакове повідомлення для всіх
const invalidLogins = [
  { email: 'real.user@example.com', password: 'wrong-pass', rule: 'чужий пароль до існуючого логіна' },
  { email: 'no.such.user@example.com', password: 'CorrectPass1', rule: 'неіснуючий користувач' },
  { email: 'no.such.user@example.com', password: 'wrong-pass', rule: 'обидва невалідні' },
];

for (const { email, password, rule } of invalidLogins) {
  test(`логін відхиляє: ${rule}`, async ({ page }) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill(email);
    await page.getByLabel('Пароль').fill(password);
    await page.getByRole('button', { name: 'Увійти' }).click();
    // спільний текст без підказки, що саме неправильне, — захист від user enumeration
    await expect(page.getByRole('alert')).toHaveText('Невірний логін чи пароль');
    await expect(page).toHaveURL(/\/login/);
  });
}

Що дивитися і чому:

Однакове повідомлення — це теж асерт. Якщо на неіснуючий логін форма відповідає «користувача не знайдено», а на чужий пароль — «невірний пароль», вона стала інструментом перебору імен користувачів. Асерт на спільний текст у всіх трьох правилах ловить це раніше за пентест.
Кожне правило — окремий тест із власною назвою. Звіт одразу показує, який саме захист зламався; злиплий тест «логін не пускає з поганими даними» цієї інформації не дає.
Таблиця — лише перший блок відповіді. Стани сесії (редірект після входу, логаут у сусідній вкладці, таймаут) — окремі перевірки поверх таблиці; на співбесіді їх досить назвати наступним пріоритетом.

Кейс 3. «А тепер лише три тести»: що лишити й що це коштує

Поле «кількість товару», 1–100, повний набір — 8–9 кейсів. Інтерв'юер тисне: часу на три. Ріжемо за ризиком і промовляємо ціну.

Залишаю	Що ловить	Чому саме він
Валідне значення (42) зберігається	фіча взагалі працює	без нього решта перевірок безглузда — це сенс існування поля
Межа: 100 приймається, 101 — ні	off-by-one у порівнянні	найімовірніший клас багів — на межах діапазону
Порожнє обов'язкове поле відхиляється	збереження без значення	найгірший наслідок серед невалідних класів: сміття в замовленні

Що дивитися і чому:

Ціна скорочення промовляється вголос. Непокритими лишилися нижня межа (0/1), нечислові класи (abc, 2.5) і небезпечні дані — це визнаний ризик, а не забутий. Саме ця фраза відрізняє усвідомлене скорочення від зрізаних кутів.
Вибір повторює логіку реального релізу. «Валідний сценарій + найімовірніший баг + найболючіший наслідок» — та сама формула, за якою ріжеться регрес, коли реліз сьогодні ввечері. Інтерв'юер чує не теорію, а робочу звичку.
Число тестів нікого не цікавить. І 9, і 3 — правильні відповіді, поки кандидат може показати, з яких класів, меж і ризиків число виведене і що було відрізано свідомо.

Скелет відповіді

Знаю чотири кроки сильної відповіді на «протестуй X»: уточнення → пріоритети → техніки → межа достатності.
Розумію, що задача навмисно недовизначена й оцінює поведінку (питання, структура, техніки, вміння зупинитися), а не кількість кейсів.
Можу назвати два-три уточнювальні питання: що це за об'єкт і навіщо, хто користувач, які вимоги, де межа відповідальності (лише UI чи й сервер).
Знаю, що робити з «вимог немає, вигадуйте самі»: озвучити припущення вголос («припустімо, це поле кількості, ціле 1–100») і тестувати вже його.
Розумію, чому перший кейс — завжди базовий позитивний сценарій, а негативні йдуть за спаданням ризику.

Поле вводу

Можу розкласти поле 1–100 за техніками: класи еквівалентності дають каркас, межі — точки 0/1/100/101, небезпечні дані — обробку рядка, передбачення помилок — типові промахи розробників.
Знаю, чому кожен невалідний клас перевіряється окремим тестом: перший спрацьований захист замаскує решту.
Пам'ятаю «небезпечну класику»: пробіли, -1, 2.5, 1e2, ведучі нулі, довжелезний рядок, кирилиця, невидимий unicode, а ' OR 1=1 і <script> — як сигнал про нейтралізацію службових символів.
Можу пояснити, чому фронтенд-валідація (type, min, max, required) не скасовує серверної: запит можна надіслати повз UI.

Форма логіну

Можу побудувати таблицю рішень: логін валідний/ні × пароль валідний/ні = чотири правила, пускати лише при обох валідних.
Знаю життєві варіації невалідного входу: неіснуючий користувач, чужий пароль до існуючого логіна, інший регістр пароля, пробіли на краях.
Розглядаю логін як машину станів: розлогінений → залогінений → сесія протухла → повторний вхід; редіректи, логаут у сусідній вкладці, таймаут.
Можу назвати безпековий мінімум: маскування пароля, пароль не в URL, спільне повідомлення про помилку без підказки (user enumeration), обмеження невдалих спроб.

Фізичні об'єкти

Знаю, що для олівця головний крок — уточнення «для кого», а перевірки групуються: функціональні, характеристики, нефункціональні, негативні/експлуатаційні, сумісність.
Розкладаю ліфт через переходи станів і можу назвати конфліктні події: виклик під час руху, «відчинити» при зачиненні, одночасні виклики, перевантаження, зникнення живлення.
Розкладаю банкомат: таблиця рішень (картка × PIN × кошти × ліміт) + стани з таймаутом + безпека; пріоритет — сценарії втрати грошей або картки.
Можу промовити висновок вголос: об'єкт не має значення — будь-що розкладається на умови використання, межі, стани й комбінації.

Кількість кейсів і типові провали

Можу вивести 8–9 кейсів для поля 1–100 з класів, меж і ризиків, а не назвати число з повітря; кожен кейс ловить свій клас дефектів.
Знаю відповідь на «часу лише на три тести»: валідне значення, одна межа, найгірший невалідний клас — і промовляю ціну кожного скорочення.
Пам'ятаю шість типових провалів: сипати кейсами без уточнень, 50 кейсів без пріоритетів, екзотика без happy path, назви технік без застосування, лише UI, мовчазні припущення.