Тест-кейси, чеклисти і тест-сюїти

З чого складається тест-кейс?

За ISTQB тест-кейс — набір передумов, вхідних даних, дій, очікуваних результатів і постумов, розроблений на основі тестових умов. Практичний мінімум полів: ID, назва, передумови, кроки, очікуваний результат, пріоритет і посилання на вимогу. Сильна відповідь — не перелік, а «навіщо кожне»: ID дає однозначне посилання в баг-репорті й розмові, назва працює на пошук і тріаж, передумови відділяють підготовку від перевірки, кроки — пронумеровані дії по одній на крок, очікуваний результат — оракул, з яким порівнюють фактичну поведінку, пріоритет вирішує, чи потрапить кейс у скорочений прогін. Формальні шаблони описує стандарт ISO/IEC/IEEE 29119-3 (наступник IEEE 829), але в реальності структуру диктує TMS або конвенція команди — тож завчений шаблон цінний менше, ніж розуміння ролі кожного поля.

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

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

Куди покласти логін — у передумови чи в кроки?

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

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

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

Який тест-кейс — хороший?

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

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

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

Чим чеклист відрізняється від тест-кейсу? Коли обереш чеклист?

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

Що таке високорівневий і низькорівневий тест-кейс і коли який доречний?

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

Звідки береться тест-кейс? Що таке тестова умова і навіщо трасування?

Кейс завершує ланцюжок: з вимоги чи acceptance criteria виводяться тестові умови — що треба перевірити («після трьох невдалих спроб акаунт блокується»), а з тестової умови народжується кейс — як саме це перевірити: кроки, дані, очікуваний результат. У STLC це фаза дизайну тестів. Ланцюжок дає трасування (traceability): змінилася вимога — знаходиш усі кейси, які її перевіряють; впав кейс — знаєш, яка вимога під загрозою. Без цього звʼязку набір перетворюється на купу перевірок, про які невідомо, навіщо вони існують, — і які страшно видаляти.

Що таке тест-сюїта? Чи може один кейс бути одночасно у смоуку і в регресії?

Тест-сюїта — набір кейсів, зібраних для виконання разом, і ключова думка, яку часто пропускають: сюїта — це вибірка під ціль прогону, а не папка в дереві. Тому так, кейс «логін валідними даними» живе одночасно у смоуку і в повній регресії — це нормально і правильно. Уявлення «сюїта = папка» веде до копіювання кейсів по «папках», а копії гарантовано розсинхронізуються. В автоматизації та сама ідея реалізується тегами: тест позначається @smoke і @regression, а прогін сюїти — просто фільтр на кшталт npx playwright test --grep @smoke.

Як організуєш регресійний набір на проєкті?

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

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

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

Кейс три роки проходить і нічого не знаходить — що з ним робити?

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

Як тримати набір тест-кейсів в актуальному стані?

Кейси старіють за замовчуванням — це закон, а не чиясь недбалість: фіча змінилася — кроки брешуть, фічу видалили — лишилися кейси-сироти, два тестувальники описали одну перевірку різними словами — дублікат роздуває регресію. Тримає набір живим чотири практики. Актуалізація — частина роботи над фічею: definition of done включає оновлені тести, а не «колись потім». Життєвий цикл кейсу — статуси draft → актуальний → deprecated: кейс без статусу — кейс, якому не можна довіряти. Ревізія за підсумками регресії: кожен прогін підсвічує кейси, які всі пропускають, кейси зі «своєю інтерпретацією» і кейси, що падають через застарілі кроки, а не через баги. І сміливість видаляти — див. попереднє питання.

З якими TMS працював і що взагалі дає TMS?

Назви тут цікавлять менше, ніж розуміння, що TMS (test management system) дає процесу, — і сильна відповідь починає саме з цього. Мінімальний набір: зберігання кейсів з історією змін, збирання сюїт і прогонів, фіксація результатів по кожному кейсу, звʼязування кейсів з вимогами (трасування) і баг-репортами, метрики на кшталт pass rate і динаміки прогонів. Поширені інструменти: TestRail, Zephyr і Xray як плагіни до Jira, Qase, TestLink, Azure Test Plans — вибір визначають інтеграції і бюджет, а не пошук «правильної» TMS; малому проєкту на старті вистачає таблиці, і це нормально. Окрема цінність для команд з автоматизацією — єдина точка правди: результати автопрогонів з CI публікуються туди ж, де живуть ручні прогони, і картина покриття стає повною, а не розірваною на «наші кейси» й «їхні тести».

Прогін показує 100% passed — реліз безпечний?

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

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

Кейс 1. Рефакторинг: з «Перевірка форми — 3» у кейс, яким можна користуватися

Типовий кейс зі старого набору, який дістався у спадок:

ID: TC-113 Назва: Перевірка форми — 3 Кроки:

1. Залогінитися.
2. Перейти в профіль і змінити пароль; якщо зʼявиться попередження — закрити його.
3. Вийти й зайти з новим паролем.

Очікуваний результат: система працює коректно.

Тут зібрані одразу всі антипатерни глави. Після рефакторингу — два окремі кейси; перший виглядає так:

ID: TC-113 Назва: Зміна пароля залогіненим користувачем: показується підтвердження Передумови: існує зареєстрований користувач user@example.com з паролем OldPass1!; користувач залогінений. Кроки:

1. Відкрити сторінку профілю, розділ «Безпека».
2. Ввести старий пароль OldPass1! і новий NewPass2!.
3. Натиснути «Зберегти».

Очікуваний результат: зʼявляється повідомлення «Пароль змінено»; користувач лишається залогіненим.

А «вийти й зайти з новим паролем» — окремий кейс TC-114 зі своєю передумовою «пароль користувача змінено на NewPass2!».

Що виправлено і чому:

• Логін пішов у передумови. Предмет перевірки — зміна пароля, а не вхід; логін лише готує стан, тож виконувати його можна як завгодно — через UI, API чи готову сесію.
• Розгалуження «якщо зʼявиться попередження» зникло. Розгалуження в кроці означає, що в кейсі живуть два сценарії, — і виконавці підуть різними гілками, отримавши різні результати.
• Кейс розпиляно за атомарністю. «Змінити пароль і перелогінитися» при падінні на другому етапі не каже нічого про перший: одна клітинка failed ховає стан другої перевірки. Два кейси — два незалежні статуси.
• Зʼявився оракул. «Система працює коректно» — це не результат: два тестувальники поставлять такому кейсу різні статуси. Тепер результат перевірний і описує й те, що статися не має (сесія не розривається).
• Назва описує перевірку. У прогоні на 300 кейсів видно лише назви — «Перевірка форми — 3» у списку впалих не каже нічого, нова назва каже все.

Кейс 2. Таблиця рішень: чеклист чи тест-кейси

Питання «що заводити під фічу — чеклист чи кейси?» вирішується не смаком, а контекстом. Робоча таблиця:

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

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

Кейс 3. Playwright: один кейс у двох сюїтах через теги

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

// tests/auth/login.spec.ts — файл за фічею: вимір «де лежить»
import { test, expect } from '@playwright/test';

// критичний позитивний сценарій: і у смоуку, і в регресії
test('логін валідними даними: користувач бачить дашборд',
  { tag: ['@smoke', '@regression'] },
  async ({ page }) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill('user@example.com');
    await page.getByLabel('Пароль').fill('CorrectPass1!');
    await page.getByRole('button', { name: 'Увійти' }).click();
    await expect(page).toHaveURL(/\/dashboard/);
  });

// негативний сценарій: лише повна регресія
test('логін з неправильним паролем: помилка, сесія не створюється',
  { tag: ['@regression'] },
  async ({ page, context }) => {
    await page.goto('/login');
    await page.getByLabel('Email').fill('user@example.com');
    await page.getByLabel('Пароль').fill('WrongPass1!');
    await page.getByRole('button', { name: 'Увійти' }).click();
    await expect(page.getByText('Неправильний email або пароль')).toBeVisible();
    await expect(page).toHaveURL(/\/login/);
    // очікуваний результат описує й те, що статися НЕ має
    const cookies = await context.cookies();
    expect(cookies.find((c) => c.name === 'session')).toBeUndefined();
  });

Прогін сюїти — просто фільтр:

npx playwright test --grep @smoke        # смоук перед деплоєм
npx playwright test --grep @regression   # повна регресія

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

• Тест входить у кілька сюїт без дублювання. Перший тест позначений і @smoke, і @regression — жодних копій файлу в папках smoke/ і regression/, які гарантовано розсинхронізуються.
• Два виміри видно буквально. Шлях tests/auth/login.spec.ts — структура за фічами (так тест шукають), теги — вибірки під ціль прогону (так його женуть). Це прямий аналог репозиторію кейсів і сюїт у TMS.
• Асерт на «не має статися». Перевірка, що кука сесії не встановилася, — переклад конкретного очікуваного результату з кейсу TC-042 глави в код; без неї тест мовчки пропустить створення сесії при показаній помилці.
• Назви тестів — назви кейсів. У репорті прогону видно лише назви, тож вони описують перевірку («помилка, сесія не створюється»), а не дію («перевірити логін»).

Структура тест-кейсу

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

Атрибути хорошого кейсу

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

Чеклист vs тест-кейс, рівні кейсів

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

Сюїти й організація набору

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

Підтримка набору і TMS

• Знаю чотири практики, що тримають набір живим: актуалізація як частина definition of done фічі, статуси життєвого циклу (draft → актуальний → deprecated), ревізія за підсумками регресії, сміливість видаляти.
• Розумію, чому мертвий кейс гірший за відсутній (ілюзія покриття, час прогону, підрив довіри) і чому вічно зелений кейс — парадокс пестицидів і привід для ревізії, а не для впевненості.
• Можу пояснити, що TMS дає процесу: історія змін кейсів, сюїти й прогони, трасування до вимог і багів, метрики — і чому «що лежить у системі» важливіше за «яка це система».