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

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

Тест-дизайн (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) виписуємо тестові умови — твердження, які мають виконуватись.

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

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

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

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

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

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

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

// Скелет сюїти: назва тесту = тестова умова, одна умова — один тест
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. Фрагмент специфікації і що з ним робити:

Після відповідей перша вимога перетворюється на тестопридатну: «Пошук повертає першу сторінку результатів не довше ніж за 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) від «має працювати швидко» і знаю маркери проблемної: оцінні слова без метрики, розмиті кванти, суперечності, неописані альтернативні гілки.
• Знаю, що нетестопридатна вимога — легітимний дефект (заводиться як баг у коді), а при незрозумілій вимозі йду до аналітика з «що має статися, коли…?»; вимушені припущення фіксую письмово й підтверджую — інакше тестую власну фантазію.