Види тестування: Smoke, Regression, Sanity, Exploratory

Загальна картина

Всі чотири види вирішують різні питання:

Вид	Головне питання	Коли
Smoke	Чи запускається білд взагалі?	Кожен новий білд
Regression	Чи не зламали ми щось що раніше працювало?	Після кожної зміни
Sanity	Чи виправили конкретний баг / чи працює нова фіча?	Після фіксу
Exploratory	Де може бути прихований баг?	Нова фіча, мало часу

Smoke тестування

Суть

Назва прийшла з електроніки: якщо схема «димить» при першому включенні — далі тестувати нема сенсу.

Ціль: переконатись, що білд взагалі придатний до тестування.

Характеристики

Покриття: широке, поверхневе
Глибина: мінімальна — тільки критичні функції
Тривалість: 15–30 хвилин
Хто виконує: QA або автоматизація
Документація: фіксований набір тест-кейсів

Що тестується у smoke

Додаток запускається
Головна сторінка відкривається
Авторизація працює
Ключові навігаційні елементи присутні
Критичні ендпоінти відповідають

Результат

Білд прийнятий до тестування або Білд відхилено

Приклад

Новий білд v2.15.0 зданий розробником о 14:00.
QA запускає smoke (20 тест-кейсів):
  ✅ Додаток запускається
  ✅ Логін працює
  ❌ Головна сторінка повертає 500

→ Білд відхилено. Повертається розробнику.
   Детальне тестування не починається.

Regression тестування

Суть

Найоб'ємніший вид. Ціль: переконатись, що нові зміни не зламали те, що раніше працювало.

Хронічний страх кожної команди: виправили баг у кошику — зламали оплату.

Характеристики

Покриття: повне або вибіркове (на основі ризику)
Глибина: всі суміжні модулі
Тривалість: години або дні
Хто виконує: QA + автоматизація (регресія зазвичай автоматизована)
Документація: повна тест-suite

Типи регресії

Тип	Опис	Коли
Full regression	Всі тест-кейси системи	Перед великим релізом
Partial regression	Змінені модулі + суміжні	Після кожного спринту
Risk-based	Тільки найбільш ризиковані	При браку часу

Приклад

Розробник виправив баг у фільтрації товарів (PROD-0142).
QA запускає регресію:
  - Модуль фільтрації (змінений) — перевіряємо
  - Модуль пошуку (суміжний) — перевіряємо
  - Модуль кошику (суміжний) — перевіряємо
  - Модуль оплати (суміжний) — перевіряємо
  - Профіль користувача (несуміжний) — пропускаємо

Чому регресія автоматизується

Запускати 500+ тест-кейсів вручну щодня після кожного коміту — нереально. Playwright/Cypress запускають всю suite за 10–15 хвилин у CI/CD.

Sanity тестування

Суть

Вузька, цільова перевірка конкретної зміни або фіксу.

Ціль: «Ми попросили виправити баг X — він дійсно виправлений?»

Характеристики

Покриття: вузьке, конкретна функція
Глибина: глибока перевірка одного модуля
Тривалість: 15–60 хвилин
Хто виконує: QA вручну
Документація: може бути без формальних тест-кейсів

Smoke vs Sanity

	Smoke	Sanity
Ширина	Широко	Вузько
Глибина	Поверхово	Глибоко
Мета	Перевірити білд загалом	Перевірити конкретний фікс
Коли	На вході кожного білду	Після конкретної зміни

Приклад

Розробник закрив тікет:
«BUG-0142: Кнопка Оплатити активна при порожньому кошику»

QA робить sanity (20 хвилин):
  1. Відкрити порожній кошик → кнопка задізейблена ✅
  2. Додати товар → кнопка активна ✅
  3. Видалити всі товари → кнопка знову задізейблена ✅
  4. Перевірити повідомлення при спробі оплати з порожнім кошиком ✅

→ Тікет підтверджено виправленим. Status: Closed.

Exploratory тестування

Суть

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

Мета: знайти те, чого ми не передбачили в тест-плані.

Характеристики

Покриття: непередбачуване, залежить від тестувальника
Глибина: змінна — слідуємо за знахідками
Тривалість: 30–90 хвилин (time-box)
Хто виконує: досвідчений QA
Документація: session report після завершення

Exploratory ≠ хаотичне тестування

Це структуроване дослідження з нотатками:

Визначаємо мету сесії (charter)
Виділяємо time-box (наприклад, 60 хвилин)
Досліджуємо, нотуємо знахідки
Пишемо session report

Session Charter (мета сесії)

Ціль: Дослідити модуль оплати на предмет граничних сценаріїв
Область: Форма оплати, валідація карти, стани помилок
Time-box: 60 хвилин
Тестувальник: Анна

Що шукає досвідчений QA в exploratory

Нестандартні сценарії:

Що буде якщо відкрити в двох вкладках одночасно?
Що буде якщо скопіювати посилання і відкрити без авторизації?
Що буде якщо вставити SQL у поле імені: '; DROP TABLE users--
Що буде якщо завантажити файл розміром 0 байт?
Що буде якщо змінити параметр в URL вручну?

Session report після завершення:

Сесія: Оплата — граничні сценарії
Час: 60 хвилин
Знайдено:
  - BUG-201: Форма не очищається після невдалої оплати
  - BUG-202: Можна ввести картку з минулою датою (2020)
Протестовано:
  - Всі поля форми з граничними значеннями
  - Сценарії з розривом мережі
  - Cross-tab поведінка

Де які види тестування застосовуються в спринті

День 1–2:   Новий білд → [SMOKE] → прийнятий/відхилений
День 3–5:   Нова фіча  → [EXPLORATORY сесія 1]
День 6–7:   Фікс бага  → [SANITY] → підтвердження
День 8–9:   Ще фікси   → [SANITY] × N
День 9–10:  Перед релізом → [REGRESSION повна]

Питання на співбесіді

«Чим smoke відрізняється від sanity?»

Smoke — перевіряє весь білд поверхово (широко і мілко). Sanity — перевіряє конкретну функцію або фікс глибоко (вузько і глибоко). Smoke — на вході перед тестуванням. Sanity — після конкретної зміни.

«Навіщо exploratory якщо є тест-кейси?»

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

«Коли регресія не потрібна?»

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

«Що таке time-box в exploratory?»

Фіксований відрізок часу для дослідницької сесії (30–90 хвилин). Після закінчення часу — зупинка і написання session report, незалежно від того чи знайшли всі баги.