Тест-кейси й чеклисти: рівень деталізації

Зміст

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

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

Атомарність: одна перевірка — один інваріант

Атомарний тест-кейс перевіряє рівно одне твердження про поведінку системи — один інваріант. «Порожній email блокує сабміт форми» — інваріант. «Форма реєстрації працює коректно» — не інваріант, а тема на десяток кейсів.

Чому це принципово. Результат виконання кейсу — один статус: passed або failed. Якщо кейс перевіряє одну річ, статус читається без відкривання кейсу: упав «порожній email блокує сабміт» — зламалася саме ця валідація. Якщо ж кейс на 12 кроків перевіряє шість речей і падає на третій, то про решту три перевірки після точки падіння ти не знаєш нічого: вони не failed — вони не виконані. Один статус на шість інваріантів — це втрата інформації, яку потім доводиться відновлювати руками.

Атомарність дає й інші дивіденди:

Вибіркові прогони. Регресію можна зібрати з атомарних кейсів під конкретний ризик; кейс-комбайн або тягне зайве, або лишає діру.
Чесна статистика. «5 failed з 200» щось означає, лише коли кейси співмірні за обсягом перевірок.
Пряма трасованість. Атомарний кейс прив'язується до однієї тестової умови з ланцюжка «вимога → умова → кейс» (див. першу главу розділу) — це фундамент покриття вимог.

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

В автоматизації різниця видна неозброєним оком:

// Антипатерн: тест-комбайн — падіння на кроці 3 ховає решту перевірок
test('форма реєстрації працює', async ({ page }) => {
  // ...12 кроків, 6 expect-ів упереміш
});

// Атомарно: один інваріант, зрозуміла назва, чистий репорт
test('порожній email блокує сабміт і показує помилку', async ({ page }) => {
  await page.goto('/signup');
  await page.getByRole('button', { name: 'Зареєструватися' }).click();
  await expect(page.getByText('Вкажіть email')).toBeVisible();
});

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

Назва описує перевірку

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

Погана назва	Хороша назва	Що виправлено
Перевірка логіну	Логін з валідним паролем відкриває дашборд	«Перевірка» — шум; названо очікувану поведінку
Тест поля email	Email без символу @ показує помилку валідації	Названо конкретний інваріант, а не об'єкт
Відкрити сторінку кошика і видалити товар	Видалення останнього товару показує порожній кошик	Дія переїхала в кроки; у назві — результат
Негативний кейс 3	Пароль коротший за 8 символів відхиляється	Назву можна прочитати без відкривання кейсу

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

Рівень деталізації: детальний, high-level, чеклист

Той самий інваріант можна записати трьома способами. ISTQB розрізняє низькорівневі (low-level, concrete) тест-кейси — з конкретними даними й покроковими діями — і високорівневі (high-level, logical) — де зафіксовано суть перевірки без конкретних значень. Чеклист — ще один щабель угору: лише список інваріантів, «що має бути правдою», без кроків узагалі (як техніка він розібраний у главі про досвідні техніки).

Формат	Що фіксує	Хто може виконати	Ціна підтримки
Детальний кейс	Кожен крок, конкретні дані, точний очікуваний результат	Будь-хто, навіть без знання продукту	Висока: старіє з кожною зміною UI
High-level кейс	Що перевірити й суть кроків, без конкретики	Той, хто знає продукт	Помірна: переживає косметичні зміни
Чеклист	Тільки інваріант	Досвідчений у продукті	Мінімальна

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

Звідси критерії вибору — вони про контекст, а не про смак:

Виконавець. Крауд-тестування, аутсорс, новачки на онбордингу — детально. Стабільна команда, що знає продукт, — high-level або чеклист.
Ціна помилки і формальні вимоги. Регульовані домени (медицина, авіоніка, фінанси) вимагають відтворюваності й аудиторського сліду — там детальні кейси не обговорюються.
Швидкість змін. Продукт, де UI перемальовують щоспринту, з'їсть будь-яку деталізацію — кроки застаріють раніше, ніж їх виконають удруге.
Доля кейсу. Кандидат на автоматизацію логічно тримати high-level: конкретика все одно переїде в код і тестові дані.

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

Незалежність кейсів

Незалежний кейс можна виконати окремо від решти, у будь-якому порядку, і результат від цього не зміниться. Кожен кейс сам описує свої передумови — а не успадковує стан, який лишив по собі попередній.

Класичний антипатерн — прихований ланцюжок: кейс 1 створює користувача, кейс 3 редагує його профіль, кейс 7 видаляє. Поки сюїту ганяють цілком і по порядку, все зелене. Проблеми починаються одразу за межами цього сценарію: вибіркова регресія неможлива (кейс 7 окремо не запустиш), падіння кейсу 1 каскадом валить 3 і 7 — у звіті три падіння замість одного реального, а перестановка чи паралельний запуск (докладніше — у розділі про автоматизацію) ламає все мовчки. Порядок виконання став передумовою, якої ніде не записано.

Ліки прості: усе, що кейсу потрібно, — у його передумовах, і передумови мають бути відтворюваними. «Існує активний користувач з підпискою» — так; «виконано кейс TC-101» — ні. В автоматизації те саме правило звучить як «стан готуємо найкоротшим шляхом, зазвичай через API, а не через UI-ланцюжок»:

// Передумову створюємо самі через API — кейс самодостатній
test('архівування проєкту ховає його зі списку', async ({ page, request }) => {
  const res = await request.post('/api/projects', { data: { name: 'tmp-archive' } });
  const { id } = await res.json();
  await page.goto(`/projects/${id}`);
  await page.getByRole('button', { name: 'Архівувати' }).click();
  await page.goto('/projects');
  await expect(page.getByText('tmp-archive')).toBeHidden();
});

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

Підтримуваність: дублювання, старіння, рев'ю

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

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

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

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

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

Антипатерни

Зведений список того, що найчастіше стріляє в ногу — і чим саме:

Кейс-комбайн. 30 кроків, 10 перевірок. Падає на сьомому кроці — про решту нічого не відомо, звіт бреше.
«Перевірити, що все працює коректно». Очікуваний результат без критерію — не оракул: два виконавці поставлять різні статуси на тому самому екрані.
Назва про дорогу, а не про перевірку. «Відкрити налаштування профілю» — це крок. Що має бути правдою, коли ти туди дійшов?
Ланцюжок залежних кейсів. Порядок виконання — прихована передумова; вибіркові прогони й паралельність померли.
Крихкі дані в кроках. Дата «31.12.2026», користувач test123, якого хтось видалив. Кейс протухає без жодної зміни продукту — тому дані описують властивістю («дата в майбутньому», «користувач без замовлень»), а конкретику тримають у тестових даних.
Клони замість параметризації. Дванадцять кейсів, що різняться одним значенням поля. Це один кейс із таблицею значень (параметри в TMS, цикл по даних у коді) — інакше кожна зміна флоу множиться на дванадцять.
Кейс-сирота. Не прив'язаний до жодної вимоги чи умови: незрозуміло, навіщо він, і неможливо вирішити, чи можна його видалити. Саме сироти складають баласт старих сюїт.

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

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

Підсумок

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

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

«Наскільки детально треба писати тест-кейси?» Слабка відповідь — «якомога детальніше». Сильна — назвати фактори: хто виконує, ціна помилки і регуляторні вимоги, швидкість змін продукту, чи піде кейс в автоматизацію. Інтерв'юер перевіряє, чи бачиш ти деталізацію як рішення з ціною.
«Чеклист чи тест-кейс — що краще?» Очікують «залежить» із критеріями і розуміння компромісу відтворюваність/підтримка. Бонус — згадати, що зріла сюїта поєднує обидва формати.
«Що таке хороший тест-кейс?» Дивляться, чи назвеш ознаки якості (атомарність, назва за перевіркою, незалежність, очікуваний результат із критерієм), а не лише перелік полів зі структури.
«У вас 800 кейсів, регресія займає тиждень. Ваші дії?» Перевіряють мислення про сюїту як продукт: ревізія і видалення застарілих, злиття дублікатів через трасування, параметризація клонів, пріоритезація за ризиком, кандидати в автоматизацію.
«Чому кейси не повинні залежати один від одного?» Очікують конкретні наслідки: неможливість вибіркових прогонів, каскадні падіння, прихована передумова у вигляді порядку виконання — а не абстрактне «так правильно».
«Кейс упав, бо застарів. Що робите?» Сильна відповідь — про гігієну: полагодити або видалити одразу і чому «звичний failed» небезпечніший за відсутність кейсу — він знецінює сигнал усієї сюїти.

Джерела

ISTQB CTFL 4.0 Syllabus — розділ 1.4 (тест-кейси як testware у діяльностях тестування) і 4.4.3 «Checklist-Based Testing»; глава спирається на них у частині термінології.
ISTQB Glossary — канонічні означення test case, high-level test case, low-level test case, test suite.
ISO/IEC/IEEE 29119-3 Software and systems engineering — Software testing — Part 3: Test documentation — формальний стандарт структури тестової документації, включно зі специфікацією тест-кейсів.
Playwright: Best Practices — офіційні рекомендації щодо ізоляції тестів, на які спирається приклад незалежності.

Що таке атомарний тест-кейс і навіщо правило «один кейс — одна перевірка»?

Атомарний кейс перевіряє рівно одне твердження про поведінку системи — один інваріант: «порожній email блокує сабміт форми» — інваріант, «форма реєстрації працює коректно» — тема на десяток кейсів. Причина принципова: результат виконання кейсу — один статус, passed або failed. Якщо кейс перевіряє одну річ, статус читається без відкривання кейсу: упав — зламалася саме ця поведінка. Якщо ж кейс на 12 кроків перевіряє шість речей і падає на третьому, про перевірки після точки падіння невідомо нічого — вони не failed, вони не виконані, і один статус на шість інваріантів — це втрата інформації. Бонуси атомарності: вибіркові прогони під конкретний ризик, чесна статистика («5 failed з 200» щось означає лише для співмірних кейсів) і пряма трасованість до однієї тестової умови.

Атомарність означає «один крок на кейс»?

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

Якою має бути назва тест-кейсу?

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

Чим відрізняються низькорівневі (low-level) і високорівневі (high-level) тест-кейси?

Це термінологія ISTQB про рівень конкретики. Низькорівневий (low-level, concrete) кейс фіксує кожен крок, конкретні дані й точний очікуваний результат — його виконає будь-хто, навіть без знання продукту, і два різні виконавці зроблять те саме. Високорівневий (high-level, logical) фіксує суть перевірки без конкретних значень — виконати його може лише той, хто знає продукт, зате він переживає косметичні зміни інтерфейсу. Ще щабель угору — чеклист: лише список інваріантів без кроків узагалі. Це не шкала «погано — краще», а компроміс між відтворюваністю і вартістю підтримки.

Чеклист чи тест-кейс — що краще?

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

Наскільки детально треба писати тест-кейси?

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

Що таке незалежний тест-кейс і чому кейси не повинні залежати один від одного?

Незалежний кейс можна виконати окремо від решти, у будь-якому порядку, і результат не зміниться — кожен кейс сам описує свої передумови, а не успадковує стан від попереднього. Наслідки залежності конкретні, і саме їх чекає інтерв'юер замість абстрактного «так правильно». Перше: вибіркова регресія неможлива — кейс 7 окремо не запустиш, бо він мовчки вимагає кейсів 1 і 3. Друге: падіння першого кейсу каскадом валить залежні — у звіті три падіння замість одного реального. Третє: перестановка чи паралельний запуск ламає все мовчки, бо порядок виконання став передумовою, якої ніде не записано.

Як правильно формулювати передумови кейсу?

Усе, що кейсу потрібно, має бути в його передумовах, і передумови мають бути відтворюваними — тобто описувати стан, який можна створити з нуля. «Існує активний користувач з підпискою» — так; «виконано кейс TC-101» — ні, це залежність від іншого кейсу, а не опис стану. В автоматизації те саме правило звучить як «стан готуємо найкоротшим шляхом, зазвичай через API, а не через UI-ланцюжок»: тест сам створює собі проєкт POST-запитом і лише тоді йде в UI перевіряти. Playwright підштовхує до цього чистим контекстом браузера на кожен тест, а от у ручних сюїтах TMS такої огорожі немає — там незалежність тримається лише на дисципліні автора.

Що таке хороший тест-кейс?

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

Чому «перевірити, що все працює коректно» — поганий очікуваний результат?

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

Кейс упав, бо застарів — посилається на кнопку, якої немає два релізи. Що робите?

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

Звідки в сюїті беруться дублікати і як їх ловити?

Типовий сценарій: та сама перевірка живе у трьох сюїтах під різними назвами — одну написали до фічі, другу під регресію, третю після бага. Тепер будь-яка зміна поведінки править три кейси, і рано чи пізно вони розійдуться: один passed, інший failed на тій самій збірці. Корінь зазвичай у тому, що кейси пишуть «від екрана» («а що тут можна потикати?»), а не від тестової умови. Системні ліки — трасування до вимог: коли кожен кейс прив'язаний до умови з ланцюжка «вимога → умова → кейс», дублікат видно механічно — як другий кейс на тій самій умові.

У сюїті дванадцять кейсів, що різняться лише значенням одного поля. Це проблема?

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

Чому конкретні дані в кроках — «дата 31.12.2026», «користувач test123» — пастка?

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

Кейс перевіряє кілька точок за один прохід — це завжди антипатерн?

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

У вас 800 кейсів, регресія займає тиждень. Ваші дії?

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

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

Кейс 1. Кейс-комбайн → атомарні кейси

У сюїті живе кейс, який «покриває всю реєстрацію». Виглядає солідно, поки не впаде:

Назва: Перевірка форми реєстрації

Кроки:
1. Відкрити /signup
2. Натиснути «Зареєструватися» з порожніми полями
   Очікується: помилка «Вкажіть email»
3. Ввести email без @, натиснути «Зареєструватися»
   Очікується: помилка валідації email
4. Ввести валідний email і пароль із 5 символів
   Очікується: помилка «Пароль закороткий»
5. Ввести різні значення в «Пароль» і «Повторіть пароль»
   Очікується: помилка про розбіжність паролів
6. Вирівняти паролі, зняти чекбокс згоди з умовами
   Очікується: кнопка «Зареєструватися» неактивна
7. Поставити чекбокс, натиснути «Зареєструватися»
   Очікується: редірект на дашборд, лист із підтвердженням

Прогін показав failed на кроці 3. Що ми знаємо? Що валідація email зламалась — і нічого про кроки 4–7: перевірки пароля, згоди й успішної реєстрації не failed, вони не виконані. У звіті один червоний рядок «Перевірка форми реєстрації», який не каже, що саме зламалося, а зібрати вибіркову регресію «тільки валідація пароля» з такого кейсу неможливо.

Рефакторинг — по одному інваріанту на кейс, назва описує перевірку:

1. Порожній email блокує сабміт і показує «Вкажіть email»
2. Email без символу @ показує помилку валідації
3. Пароль коротший за 8 символів відхиляється
4. Розбіжність полів «Пароль» і «Повторіть пароль» показує помилку
5. Без згоди з умовами кнопка «Зареєструватися» неактивна
6. Успішна реєстрація редіректить на дашборд і надсилає лист

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

Звіт тепер читається без відкривання кейсів. Упали кейси 2 і 3 — зламані саме валідація email і мінімальна довжина пароля; решта чотири інваріанти чесно passed, а не «невідомо».
Спільна підготовка тут копійчана — «відкрити /signup» — тож дублювати її в кожному кейсі дешевше, ніж тримати комбайн. Якби підготовка була важкою, її виносять у спільну передумову, а не склеюють перевірки назад.
Кількість кроків не змінює атомарності. Кейс 6 (успішна реєстрація) має найбільше кроків — заповнити всі поля правильно — але інваріант один, тож кейс атомарний.

Кейс 2. Один інваріант — три рівні деталізації

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

Детальний (low-level) кейс:

Передумови: існує активний проєкт «Alpha»

Кроки:
1. Відкрити список проєктів (/projects)
2. Натиснути меню «...» на картці проєкту «Alpha»
3. Вибрати «Архівувати», підтвердити дію в діалозі
4. Повернутися до списку проєктів

Очікуваний результат: проєкту «Alpha» немає у списку активних;
він відображається лише під фільтром «Архівовані»

High-level кейс:

Заархівувати активний проєкт і переконатися, що він зник
зі списку активних і доступний лише через фільтр архіву.

Пункт чеклиста:

- Архівований проєкт не видно серед активних

Тепер рішення — не «який формат кращий», а «який відповідає контексту»:

Контекст	Формат	Чому
Регресію ганяє аутсорс, продукт бачать уперше	Детальний	Виконавець не знає, де меню архівації; без кроків перевірка не відбудеться
Фінтех, аудитор вимагає слід виконання	Детальний	Потрібна відтворюваність: два виконавці мають зробити те саме й так само оцінити результат
Продуктова команда, UI перемальовують щоспринту	High-level	Кроки «меню → діалог» застаріють за спринт; суть перевірки переживе редизайн
Смоук перед релізом силами сеньйорів	Чеклист	Виконавець знає продукт; мінімальна ціна підтримки
Кейс — кандидат на автоматизацію	High-level	Конкретика все одно переїде в код і тестові дані

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

Кейс 3. Розрив ланцюжка залежних кейсів

Класична сюїта з прихованим ланцюжком:

TC-101: Створення користувача з підпискою     → створює user_042
TC-103: Редагування профілю користувача       → редагує user_042
TC-107: Видалення користувача                 → видаляє user_042

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

Ліки у TMS — кожному кейсу власна відтворювана передумова:

TC-103: Редагування профілю користувача
Передумови: існує активний користувач із підпискою
(створити через адмін-панель або POST /api/users)

Формулювання «існує користувач із підпискою» — так; «виконано TC-101» — ні: перше описує стан, який можна створити з нуля, друге — залежність від чужого кейсу.

В автоматизації те саме правило: стан готуємо найкоротшим шляхом через API, а не UI-ланцюжком.

// Кейс самодостатній: передумову створює сам через API
test('редагування імені зберігається в профілі', async ({ page, request }) => {
  const res = await request.post('/api/users', {
    data: { name: 'tmp-edit-user', plan: 'pro' },
  });
  const { id } = await res.json();

  await page.goto(`/users/${id}/profile`);
  await page.getByLabel('Повне імʼя').fill('tmp-edit-user-renamed');
  await page.getByRole('button', { name: 'Зберегти' }).click();
  await expect(page.getByText('Профіль оновлено')).toBeVisible();
});

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

Тест запускається окремо, повторно і паралельно — він не чекає на сусідів і не лишає їм стан. Playwright і так дає кожному тесту чистий контекст браузера; сетап через API закриває решту.
Падіння тепер точкове. Зламалося редагування — червоний один цей тест, а не хвіст ланцюжка; звіт не бреше.
Сетап через API, а не через UI-флоу реєстрації — швидше і стійкіше: UI-ланцюжок на п'ять екранів упаде від будь-якої зміни по дорозі, хоча перевіряємо ми не його.
Якщо передумова потрібна в сорока тестах — виносьте її у фікстуру чи хелпер: зміна флоу створення користувача стане однією правкою, а не сорока. У TMS ту саму роль грає спільна передумова або параметризований кейс.

Атомарність і назва

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

Рівень деталізації

Знаю різницю low-level (конкретні дані й покрокові дії) vs high-level (суть перевірки без конкретики) кейсів за ISTQB і де на цій шкалі чеклист.
Розумію, що деталізація — компроміс «відтворюваність проти вартості підтримки», а не міра старанності чи професійності.
Можу назвати критерії вибору формату: виконавець, ціна помилки і регуляторні вимоги, швидкість змін продукту, чи піде кейс в автоматизацію.
Знаю, чому зріла сюїта — мікс форматів, а «один рівень деталізації для всього» — погана ознака.
Можу пояснити, чому чеклист — не «незрілий артефакт», а свідомо вибраний рівень деталізації (ISTQB описує checklist-based testing як техніку).

Незалежність кейсів

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

Підтримуваність сюїти

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

Антипатерни

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