Тест-дизайн: від вимоги до перевірки

Зміст

«Протестуйте це поле вводу» — найзаїждженіша задача на співбесіді QA і водночас чесна модель щоденної роботи. Інтервʼюер не чекає, що ти назвеш усі перевірки на світі, — він дивиться, чи є в тебе метод: як із розмитого «протестуй» народжується скінченний, обґрунтований список перевірок. Саме цей метод і називається тест-дизайном (test design).

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

Чому вичерпне тестування неможливе

Почнімо з математики, яка руйнує наївну мрію «перевірити все». Візьмімо звичайне текстове поле на 20 символів. Навіть якщо дозволені лише малі латинські літери, варіантів вводу — 26 у 20-му степені, це приблизно 2×10^28 комбінацій. Перевіряючи мільярд значень на секунду, впораєшся за сотні мільярдів років — Всесвіт молодший.

І це одне поле. Реальна фіча — це ще й комбінації: форма з пʼяти полів по 10 значень кожне дає 100 000 комбінацій; додай порядок дій користувача, стани системи, браузери, локалі, паралельних користувачів — простір станів вибухає далеко за межі будь-якого бюджету. Тому силабус ISTQB виносить це окремим принципом тестування (другим із семи): вичерпне тестування неможливе — окрім тривіальних випадків.

Висновок не песимістичний, а робочий: будь-яке тестування — це вибірка. Питання лише в тому, роблена вона свідомо чи навмання. Тест-дизайн — дисципліна, що робить вибірку осмисленою: обрати з нескінченності перевірок ті кілька десятків, які з найбільшою ймовірністю знайдуть дефекти. А що саме вважати «найважливішим» — підказує ризик: чим болючіший можливий збій і чим імовірніший, тим щільніше покриття (докладно про ризик-орієнтований підхід — у розділі «Основи тестування»).

Ланцюжок: test basis → тестова умова → тест-кейс

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

Тестова основа (test basis) — усе, на що ти спираєшся, проєктуючи перевірки: вимоги і user story, приймальні критерії, макети, специфікація API, документація, стандарти, а також знання про типові дефекти. Немає вимог — базою стає те, що є: поведінка попередньої версії, аналоги, здоровий глузд. База гірша — але вона все одно є.

Тестова умова (test condition) — те, що можна перевірити: окрема властивість, правило, інваріант системи. Це ще не тест — це твердження, яке має виконуватись. Крок від бази до умов називають аналізом.

Тест-кейс (test case) — конкретизація умови: як саме перевіряємо. Передумови, дані, кроки, очікуваний результат. Це крок дизайну. Далі кейси шикуються у процедури виконання або автотести — але це вже імплементація.

На живому прикладі. Вимога: «Пароль містить від 8 до 64 символів і щонайменше одну цифру».

Тестові умови: пароль допустимої довжини з цифрою приймається; коротший за 8 відхиляється; довший за 64 відхиляється; без жодної цифри відхиляється.
Тест-кейс для однієї з умов: передумова — відкрита форма реєстрації; дані — пароль longpassword (12 символів, без цифр); крок — сабмит форми; очікуваний результат — акаунт не створено, біля поля зʼявляється повідомлення про обовʼязкову цифру.

Зверни увагу: одна умова може породити кілька кейсів (відхилення «коротшого за 8» варто перевірити на 7 символах — це вже територія глави «Граничні значення»). ISTQB розрізняє також високорівневі кейси (без конкретних значень: «пароль коротший за мінімум») і низькорівневі (з точними даними) — рівень деталізації обирається під контекст, про це окрема глава «Тест-кейси й чеклисти: рівень деталізації».

Навіщо проміжний крок з умовами, чому не писати кейси одразу? Бо покриття рахується саме по умовах. Список умов можна звірити з вимогою і побачити дірку («а що з довшим за 64 — ніхто не перевіряє?»); стос готових кейсів без умов — це просто купа, у якій дірок не видно. Звʼязка «вимога ↔ умова ↔ кейс» — основа трасування, до якого дійдемо у главі «Покриття вимог і трасування».

Декомпозиція фічі на перевірки

«Протестуй відновлення пароля» — з чого почати? Фіча цілком не тестується — вона спершу розкладається на шари, і в кожному шарі свої умови:

Вхідні дані: поле email — формат, регістр, пробіли по краях, неіснуюча адреса.
Потоки: основний (запит листа → перехід за посиланням → новий пароль → вхід) і альтернативні (повторний запит, скасування на півдорозі).
Стани: посилання свіже, протерміноване, вже використане — поведінка в кожному стані своя.
Правила: вимоги до нового пароля, чи можна повторити старий.
Помилки й межі: сервіс пошти недоступний, кілька запитів поспіль.

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

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

// Одна умова — один тест; назва описує інваріант, а не дію
test('протерміноване посилання відхиляється з пропозицією запросити нове', async ({ page }) => {
  await page.goto(expiredResetLink);
  await expect(page.getByText('Посилання застаріло')).toBeVisible();
  await expect(page.getByRole('link', { name: 'Надіслати нове' })).toBeVisible();
});

Позитивні й негативні перевірки

Кожну умову можна віднести до одного з двох таборів.

Позитивна перевірка підтверджує, що система робить те, що обіцяно, на валідних даних і очікуваних діях: коректний email — лист прийшов. Негативна перевіряє, що на невалідних даних чи неочікуваних діях система відмовляє гідно: зрозуміле повідомлення, код 4xx на рівні API, жодних падінь, слідів у базі чи зависань.

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

На практиці негативних перевірок майже завжди більше, ніж позитивних: способів зробити правильно — один-два, способів зробити неправильно — десятки (порожньо, задовго, не той тип, спецсимволи, несвоєчасно). І кожен невалідний сценарій перевіряється окремим тестом — якщо запхати в один тест і закороткий пароль, і відсутню цифру, перше ж спрацьовування валідації замаскує, чи працює друга (механіку розберемо в главі «Класи еквівалентності»). А про пастку «тестуємо лише happy path» — у главі «Сценарії використання й приймальні критерії».

Три сімʼї технік

Технік тест-дизайну багато, але класифікація проста — за тим, звідки береться інформація для виведення умов. Силабус ISTQB CTFL 4.0 називає ці групи black-box, white-box і experience-based; українською їх зазвичай називають «специфікаційними», «структурними» й «досвідними».

Сімʼя	На що спирається	Приклади технік
Специфікаційні (black-box)	Вимоги й зовнішня поведінка; код бачити не треба	класи еквівалентності, граничні значення, таблиці рішень, переходи станів
Структурні (white-box)	Внутрішня будова: код, гілки, шляхи виконання	покриття інструкцій і гілок
Досвідні (experience-based)	Досвід, інтуїція, знання типових дефектів	передбачення помилок, чеклисти, дослідницьке тестування

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

Для мануального QA і AQA робочий хліб — специфікаційні та досвідні. Структурні частіше живуть на рівні unit-тестів у розробників, але розуміти їх треба: питання «чому 100% покриття коду не гарантує якості» — класика співбесід.

Тестопридатність вимог

Ланцюжок «вимога → умова → кейс» працює, лише якщо перша ланка притомна. Тестопридатна (testable) вимога — та, з якої можна вивести обʼєктивний критерій pass/fail. Порівняй:

«Пошук має працювати швидко» — нетестопридатна: швидко — це скільки? На яких даних? Тест на таку вимогу не напишеш, а результат не захистиш.
«Пошук повертає першу сторінку результатів не довше ніж за 2 секунди при каталозі на 100 000 товарів» — тут є число, умови й вимірюваний критерій.

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

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

Перший орієнтир: яку техніку брати

Повний розбір вибору й комбінування — у главі «Вибір і комбінування технік», але груба карта потрібна вже зараз: техніку підказує тип логіки у фічі.

Словами: поля, діапазони й формати — класи еквівалентності плюс межі; правила виду «якщо клієнт постійний І сума понад поріг, ТО знижка» — таблиця рішень; замовлення, що мандрує статусами «створено → оплачено → відправлено», — переходи станів; матриця «браузери × ОС × мови» — попарне тестування; наскрізний шлях користувача — сценарії використання. І поверх будь-чого — досвідні техніки як фінальний прохід: «а що тут зазвичай ламається?»

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

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

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

Підсумок

Вичерпне тестування неможливе, тому будь-яке тестування — вибірка; тест-дизайн робить її свідомою: максимум знайдених дефектів на мінімум перевірок.
Перевірки виводяться ланцюжком: test basis → тестова умова (що перевіряти) → тест-кейс (як саме); покриття і трасування рахуються по умовах.
Негативний тест — це перевірка гідної відмови з чітким очікуваним результатом, і таких перевірок зазвичай більше, ніж позитивних.
Техніки діляться на специфікаційні, структурні й досвідні — за джерелом інформації; вони доповнюють одна одну, а не конкурують.
Нетестопридатна вимога — це дефект, і знайти його на ревʼю дешевше, ніж його наслідки в проді.

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

«Протестуйте поле / форму логіну / олівець» — питання №1 у професії. Сильна відповідь починається не з перевірок, а з уточнення вимог і пріоритетів, далі — техніки пошарово. Повний розбір формату — у главі «Класичні задачі співбесід».
«Чому не можна протестувати все? І що тоді робити?» — чекають принцип вичерпного тестування + вихід через техніки і ризик, а не «тестуємо скільки встигнемо».
«Що таке тест-дизайн? Які техніки знаєте, коли яку застосувати?» — інтервʼюер слухає класифікацію (три сімʼї) і мапінг «тип логіки → техніка», а не завчений перелік назв.
«Чим тестова умова відрізняється від тест-кейсу? А тест-кейс від чеклиста?» — перевірка словника: рівень абстракції, наявність конкретних даних і кроків.
«Вимога незрозуміла — ваші дії?» — правильний рух: питання аналітику, фіксація припущень, дефект на вимогу; червоний прапорець для інтервʼюера — «придумаю сам, як має бути».

Наскрізь інтервʼюер оцінює одне: чи є за відповідями система. Кандидат, який назве 10 перевірок хаотично, програє тому, хто назве 8, але згрупує їх за техніками й пояснить, чому саме ці.

Джерела

ISTQB CTFL Syllabus v4.0 — ця глава покриває розділ 1.3 (принципи тестування, зокрема «вичерпне тестування неможливе») і вступ до розділу 4 «Test Analysis and Design» (класифікація технік, тестові умови).
ISTQB Glossary — канонічні означення термінів: test basis, test condition, test case, test design, testability.
ISO/IEC/IEEE 29119-4:2021 «Software and systems engineering — Software testing — Part 4: Test techniques» — міжнародний стандарт, що формалізує специфікаційні, структурні й досвідні техніки (текст платний).

Що таке тест-дизайн і навіщо він, якщо можна «просто потестувати»?

Тест-дизайн (test design) — це метод, за яким із розмитого «протестуй» народжується скінченний і обґрунтований список перевірок. «Просто потестувати» — це «потикав, поклікав, начебто працює»: покриття випадкове, дірки невидимі, а кількість кейсів неможливо ні пояснити менеджеру, ні захистити на співбесіді. Оскільки перевірити все неможливо, будь-яке тестування — вибірка, і тест-дизайн робить її свідомою: з нескінченності перевірок обрати ті кілька десятків, які з найбільшою ймовірністю знайдуть дефекти. Саме це інтервʼюер і перевіряє класичним «протестуйте це поле»: не скільки перевірок назвеш, а чи є за ними система.

Чому неможливо протестувати все? І що тоді робити?

Бо простір станів комбінаторно вибухає. Звичайне текстове поле на 20 символів лише з малих латинських літер — це 26 у 20-му степені, приблизно 2×10^28 комбінацій: перевіряючи мільярд значень на секунду, впораєшся за сотні мільярдів років. Реальна фіча додає комбінації полів, порядок дій користувача, стани системи, браузери, локалі — тому ISTQB виносить «вичерпне тестування неможливе» окремим принципом тестування, другим із семи. Вихід не «тестуємо скільки встигнемо», а свідома вибірка через техніки тест-дизайну; глибину покриття підказує ризик: чим болючіший і імовірніший можливий збій, тим щільніше покриваємо.

Що таке тестова основа (test basis)? А якщо вимог немає?

Тестова основа — все, на що спираєшся, проєктуючи перевірки: вимоги і user story, приймальні критерії, макети, специфікація API, документація, стандарти, а також знання про типові дефекти. Це перша ланка ланцюжка «test basis → тестова умова → тест-кейс»: перевірки не беруться з повітря, вони виводяться з бази. Якщо вимог немає, базою стає те, що є: поведінка попередньої версії, продукти-аналоги, здоровий глузд. Така база гірша, але вона все одно існує — «немає вимог» не означає «нема з чого виводити перевірки».

Чим тестова умова відрізняється від тест-кейсу?

Рівнем абстракції: умова каже, що перевірити, кейс — як саме. Тестова умова (test condition) — окрема властивість, правило чи інваріант системи, твердження, яке має виконуватись: «пароль коротший за 8 символів відхиляється». Тест-кейс (test case) — конкретизація умови: передумови, конкретні дані, кроки, очікуваний результат. Крок від бази до умов називають аналізом, від умов до кейсів — дизайном; далі кейси шикуються у процедури виконання або автотести — це вже імплементація. Практичний наслідок: одна умова може породити кілька кейсів, а покриття і трасування рахуються саме по умовах.

Що таке позитивні й негативні перевірки?

Позитивна перевірка підтверджує, що система робить обіцяне на валідних даних і очікуваних діях: коректний email — лист прийшов. Негативна перевіряє, що на невалідних даних чи неочікуваних діях система відмовляє гідно: зрозуміле повідомлення, код 4xx на рівні API, жодних падінь, зависань чи слідів у базі. Тобто негативний тест перевіряє не «що буде, якщо зламати», а що відмова керована. Якщо на email без символу равлика прилітає 500-та помилка — негативний тест знайшов дефект: система мала відмовити контрольовано, а не впасти.

Чи є в негативного тесту очікуваний результат?

Так, обовʼязково — і саме на цьому сипляться на співбесідах. «Ввести сміття і подивитись, що буде» — це не негативний тест, а лотерея: без очікуваного результату неможливо сказати, passed він чи failed. Справжній негативний тест формулюється повністю: на email без символу равлика форма показує «Некоректна адреса» і не надсилає запит на сервер. Тоді будь-яке відхилення — 500-та, зависання, мовчазний сабмит — це чітко зафіксований дефект, а не «щось дивне сталося».

Чому негативних перевірок зазвичай більше, ніж позитивних?

Бо способів зробити правильно — один-два, а способів зробити неправильно — десятки: порожнє значення, задовге, не той тип, спецсимволи, дія в невідповідний момент. Кожен невалідний сценарій — окрема тестова умова зі своїм очікуваним результатом, тому негативна частина списку природно розростається. Це нормальний профіль покриття, а не перекіс: якість системи здебільшого визначається тим, як вона поводиться на межах і при помилках, а не лише на happy path.

Чому не можна перевірити кілька невалідних сценаріїв одним тестом?

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

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

Класифікація — за джерелом інформації, з якого виводяться тестові умови; силабус ISTQB CTFL 4.0 називає три групи. Специфікаційні (black-box) спираються на вимоги й зовнішню поведінку, код бачити не треба: класи еквівалентності, граничні значення, таблиці рішень, переходи станів. Структурні (white-box) спираються на внутрішню будову — код, гілки, шляхи виконання: покриття інструкцій і гілок. Досвідні (experience-based) спираються на досвід, інтуїцію і знання типових дефектів: передбачення помилок, чеклисти, дослідницьке тестування. Для мануального QA і AQA робочий хліб — специфікаційні та досвідні; структурні частіше живуть на рівні unit-тестів у розробників, але розуміти їх треба.

Чим високорівневий тест-кейс відрізняється від низькорівневого?

Наявністю конкретних даних. Високорівневий кейс описує перевірку без точних значень: «пароль коротший за мінімум відхиляється» — зрозуміло, що робити, але значення обирає виконавець. Низькорівневий фіксує все точно: пароль abcde12 із 7 символів, конкретна форма, конкретне повідомлення про помилку. Рівень деталізації — не догма, а вибір під контекст: досвідченій команді досить високорівневих, для автотестів чи аутсорс-виконавців потрібні низькорівневі. Це стандартна пара термінів ISTQB, яку перевіряють у звʼязці з «умова vs кейс».

Навіщо виводити тестові умови, якщо можна писати тест-кейси одразу з вимоги?

Бо покриття рахується саме по умовах. Короткий список умов можна звірити з вимогою і побачити дірку: «а що з паролем, довшим за 64, — ніхто не перевіряє?» Стос готових кейсів без умов — це купа, в якій дірок не видно: звірити 200 кейсів із вимогою на порядок важче, ніж 10 умов. Крім того, звʼязка «вимога ↔ умова ↔ кейс» — основа трасування: видно, звідки взявся кожен кейс і що покриває кожну вимогу. Пропуск цього кроку виглядає як економія часу, а насправді ховає прогалини покриття.

Чому специфікаційні, структурні й досвідні техніки не замінюють одна одну?

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

Чому 100% покриття коду не гарантує якості?

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

Що таке тестопридатна вимога і як розпізнати проблемну?

Тестопридатна (testable) вимога — та, з якої можна вивести обʼєктивний критерій pass/fail. «Пошук має працювати швидко» — нетестопридатна: швидко — це скільки, на яких даних? «Пошук повертає першу сторінку не довше ніж за 2 секунди при каталозі на 100 000 товарів» — тут є число, умови й вимірюваний критерій. Маркери проблемної вимоги: оцінні слова без метрики («зручно», «інтуїтивно»), розмиті кванти («як правило», «за потреби», «тощо»), суперечності між пунктами, неописані альтернативні гілки («а якщо email вже зайнятий?»). Кожен маркер — привід іти до аналітика, а «вимога, яку неможливо перевірити» — легітимний дефект, який заводять так само, як баг у коді.

Вимога незрозуміла чи суперечлива — ваші дії?

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

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

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

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

Кейс 1. Ланцюжок на живій вимозі: пароль від 8 до 64 символів і щонайменше одна цифра

Вимога одна, а перевірок із неї виводиться кілька — і саме проміжний список умов показує, чи все ти дістав. Крок перший: з вимоги (test basis) виписуємо тестові умови — твердження, які мають виконуватись.

#	Тестова умова	Тип
1	Пароль допустимої довжини з цифрою приймається	позитивна
2	Пароль, коротший за 8 символів, відхиляється	негативна
3	Пароль, довший за 64 символи, відхиляється	негативна
4	Пароль без жодної цифри відхиляється	негативна

Крок другий — звірка списку з вимогою. Саме тут видно дірки: чи перевіряємо рівно 8 і рівно 64 (валідні межі)? А 7 і 65 (перші невалідні значення)? Точний вибір значень — територія граничних значень, але сам факт «межі треба не забути» виловлюється вже на рівні умов. Зі стосу готових кейсів таку прогалину не видно — з чотирьох рядків таблиці видно одразу.

Крок третій: одна умова розгортається в тест-кейс — з передумовами, конкретними даними, кроками й очікуваним результатом.

Поле кейсу	Значення
Умова	№4: пароль без жодної цифри відхиляється
Передумова	Відкрита форма реєстрації
Дані	Пароль `longpassword` — 12 символів, без цифр
Кроки	Ввести email і пароль, сабмитнути форму
Очікуваний результат	Акаунт не створено; біля поля — повідомлення про обовʼязкову цифру

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

Одна умова — кілька кейсів, це нормально. Умову №2 варто перевірити на 7 символах, а не на 1: значення під самою межею найчастіше ловить помилку виду «переплутали строгу й нестрогу нерівність».
Негативних умов три з чотирьох. Типовий профіль: спосіб зробити правильно один, способів помилитися — більше. Якщо у твоєму списку негативних менше, ніж позитивних, — найімовірніше, список недороблений.
Кожна негативна умова — окремим тестом. Пароль abc порушує одразу два правила (короткий і без цифри), але тестом для умови №4 він не годиться: валідація довжини спрацює першою і замаскує перевірку цифри. Дані підбираються так, щоб порушувалось рівно одне правило.

Кейс 2. Декомпозиція фічі: «протестуйте відновлення пароля»

Фіча цілком не тестується — спершу вона розкладається на шари, і кожен шар віддає свої умови своїй техніці.

Шар	Приклади тестових умов	Техніка, що допоможе
Вхідні дані	формат email, регістр, пробіли по краях, неіснуюча адреса	еквівалентність + межі
Потоки	основний потік; повторний запит; скасування на півдорозі	сценарії використання
Стани	посилання свіже / протерміноване / вже використане	переходи станів
Правила	вимоги до нового пароля; чи можна повторити старий	таблиця рішень
Помилки й межі	сервіс пошти недоступний; кілька запитів поспіль	досвідні техніки

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

// Скелет сюїти: назва тесту = тестова умова, одна умова — один тест
test.describe('відновлення пароля: стани посилання', () => {
  test('свіже посилання відкриває форму нового пароля', async ({ page }) => {
    // ...
  });

  test('протерміноване посилання відхиляється з пропозицією запросити нове', async ({ page }) => {
    await page.goto(expiredResetLink);
    await expect(page.getByText('Посилання застаріло')).toBeVisible();
    await expect(page.getByRole('link', { name: 'Надіслати нове' })).toBeVisible();
  });

  test('вже використане посилання не дає змінити пароль удруге', async ({ page }) => {
    // ...
  });
});

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

Назва тримає інваріант, а не дію. «Перевірити відновлення пароля» не каже, коли тест passed; «протерміноване посилання відхиляється…» — готовий критерій провалу. Червоний тест із такою назвою читається без відкривання коду.
Шари — це і план покриття. Порожній рядок таблиці («а стани ми взагалі дивились?») помітити легко; у плоскому списку зі 100 кейсів — ні.
Технік кілька, і це нормально. Одна фіча = кілька технік пошарово; спроба накрити все однією — головне джерело «200 кейсів про той самий клас даних».

Кейс 3. Ревʼю вимог на тестопридатність

Ланцюжок працює, лише якщо перша ланка притомна: з нетестопридатної вимоги не вивести обʼєктивний pass/fail. Фрагмент специфікації і що з ним робити:

Вимога як написано	Маркер проблеми	Питання аналітику
«Пошук має працювати швидко»	оцінне слово без метрики	Швидко — це скільки? На якому обсязі каталогу?
«Система, як правило, надсилає нагадування»	розмитий квант	Коли саме надсилає, а коли ні?
«Користувач реєструється за email»	неописана альтернативна гілка	Що станеться, якщо email вже зайнятий?
П. 2.1: пароль від 8 символів; п. 4.3: від 6	суперечність між пунктами	Який мінімум правильний?

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

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

Кожен маркер — привід питати, а не додумувати. Додумана вимога означає, що очікуваний результат узято зі стелі: зелений прогін підтверджує фантазію тестувальника, а не продукт.
Нетестопридатна вимога — легітимний дефект. Її заводять так само, як баг у коді: знайдена на ревʼю, вона коштує розмови; у проді — інциденту й хотфіксу.
Вимушене припущення фіксується письмово. Якщо відповіді чекати ніколи, припущення записується і підтверджується заднім числом — тоді зрозуміло, що саме перевіряв тест, коли зʼясується інше.

Навіщо тест-дизайн

Можу пояснити, чому вичерпне тестування неможливе: комбінаторний вибух (поле на 20 символів лише з малих латинських літер — уже 26 у 20-му степені комбінацій) і принцип ISTQB, другий із семи.
Розумію, що будь-яке тестування — вибірка, а тест-дизайн робить її свідомою: максимум знайдених дефектів на мінімум перевірок.
Знаю, що глибину покриття диктує ризик: чим болючіший і імовірніший збій, тим щільніше покриття.

Ланцюжок вимога → перевірка

Знаю словник ISTQB: test basis → тестова умова (test condition) → тест-кейс (test case), і назви кроків між ними — аналіз, дизайн, імплементація.
Можу пояснити різницю: умова — ЩО перевіряти (інваріант без даних і кроків), кейс — ЯК саме (передумови, дані, кроки, очікуваний результат).
Знаю, що входить у test basis (вимоги, приймальні критерії, макети, специфікація API, знання типових дефектів) і що робити, коли вимог немає.
Розумію, навіщо проміжний крок з умовами: покриття і трасування рахуються по умовах, а в стосі кейсів без умов дірок не видно.
Знаю різницю високорівневих (без конкретних значень) і низькорівневих (з точними даними) тест-кейсів і що рівень деталізації обирається під контекст.

Декомпозиція й атомарність

Можу розкласти фічу на шари-джерела умов: вхідні дані, потоки, стани, правила, помилки й межі.
Тримаю атомарність: одна перевірка — один інваріант, і назва тесту прямо його називає («Протерміноване посилання відхиляється…», а не «Перевірити відновлення пароля»).

Позитивні й негативні перевірки

Знаю різницю: позитивна підтверджує обіцяне на валідних даних, негативна перевіряє гідну відмову на невалідних — зрозуміле повідомлення, 4xx на рівні API, без падінь і слідів у базі.
Можу пояснити, чому «ввести сміття і подивитись» — не негативний тест: у негативного теж є чіткий очікуваний результат.
Розумію, чому негативних перевірок майже завжди більше за позитивні і чому кожен невалідний сценарій — окремим тестом (перше спрацьовування валідації маскує решту).

Три сімʼї технік

Знаю класифікацію за джерелом інформації: специфікаційні (black-box), структурні (white-box), досвідні (experience-based) — і приклади технік у кожній.
Можу назвати сліпу зону кожної сімʼї: специфікаційні не бачать код поза вимогами, структурні не помічають нереалізовану вимогу, досвідні залежать від носія досвіду.
Можу пояснити, чому 100% покриття коду не гарантує якості — класика співбесід на межі white-box.
Знаю мапінг «тип логіки → техніка»: діапазони й формати — еквівалентність + межі; комбінації бізнес-правил — таблиця рішень; обʼєкт живе за статусами — переходи станів; матриця конфігурацій — pairwise; немає специфікації або стиснутий час — досвідні + дослідницьке.
Розумію, що реальна фіча покривається кількома техніками пошарово, а не однією «найкращою».

Тестопридатність вимог

Можу відрізнити тестопридатну вимогу (обʼєктивний критерій pass/fail) від «має працювати швидко» і знаю маркери проблемної: оцінні слова без метрики, розмиті кванти, суперечності, неописані альтернативні гілки.
Знаю, що нетестопридатна вимога — легітимний дефект (заводиться як баг у коді), а при незрозумілій вимозі йду до аналітика з «що має статися, коли…?»; вимушені припущення фіксую письмово й підтверджую — інакше тестую власну фантазію.