Смоук, саніті, регресія і ретест

Що таке смоук-тестування і яке його головне завдання?

Смоук (smoke testing) — мінімальний набір перевірок критичної функціональності, який запускають на кожному новому білді до будь-якого глибшого тестування. Його завдання — не знайти якомога більше дефектів, а швидко відповісти на одне бінарне питання: чи придатний цей білд для тестування взагалі. Типовий склад: застосунок відкривається, логін працює, ключовий бізнес-флоу проходить без падінь — жодних граничних значень і негативних сценаріїв. Звідси класична характеристика: смоук широкий і мілкий (broad and shallow) — торкається всіх критичних зон, але жодну не копає. Він має відпрацьовувати за хвилини, тому виграє від автоматизації і жорсткого таймбоксу; у CI-практиці той самий набір називають build verification test (BVT).

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

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

Що означають характеристики «широкий і мілкий» та «вузьке і глибоке»?

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

Смоук на новому білді впав. Твої дії?

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

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

Ретест, або підтверджувальне тестування (confirmation testing, re-testing) — повторне виконання того самого тесту, який виявив дефект: ті самі кроки, ті самі дані, те саме середовище. Мета одна — підтвердити, що саме цей дефект справді виправлено. Це стандартний крок життєвого циклу дефекту: у більшості процесів без ретесту баг не переводять у closed. Якщо ретест не пройшов — дефект перевідкривається (reopened) і повертається розробці. Ключова деталь, яка відрізняє ретест від інших прогонів: він ганяє тест, що раніше падав, тоді як регресія ганяє тести, що раніше проходили.

Чим ретест відрізняється від регресії?

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

Баг пофіксили, фікс приїхав у білд. Твої дії?

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

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

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

Що може тригерити регресійне тестування, крім фіксу бага?

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

Як ISTQB розводить smoke і sanity, і як про це відповідати на співбесіді?

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

Як визначають обсяг регресії після конкретної зміни?

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

Часу на повну регресію перед релізом немає. Що прогониш?

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

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

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

Що таке парадокс пестицидів і як він стосується регресійного набору?

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

Чому регресію і смоук автоматизують першими?

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

Автоматизували регресію — питання закрите?

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

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

Кейс 1. Фікс приїхав у білд: розкладаємо, що ганяти

Ситуація: розробник виправив баг #1042 «знижка 10% не застосовується до кошика від 1000 грн». Фікс приїхав у новий білд на тестове середовище. Часу — пів дня. Порядок дій:

Що тут важливо:

• Кроки не взаємозамінні. Ретест (крок 2) підтверджує сам фікс тестом, що падав; регресія (крок 4) шукає нові дефекти тестами, що проходили. «Перевірив фікс — отже, все ок» пропускає половину роботи.
• Порядок економить час. Якщо впав крок 1 або 2, дорогі кроки 3–4 не стартують: немає сенсу ганяти регресію навколо фікса, який не працює.
• Набір кроку 4 — не «вся регресія». Це зріз за impact analysis: питання розробнику «що ще читає ціну кошика?» плюс зачеплені модулі. Повний прогін на такий фікс — марнування дня.
• Знахідка регресії — новий баг-репорт, а не перевідкриття #1042: старий дефект про знижку, новий — про те, що фікс зламав, наприклад, підсумок замовлення.

Кейс 2. Реліз завтра, повна регресія — три дні

Ситуація: у регресійному наборі 800 кейсів, повний прогін — три робочі дні, реліз завтра вранці. «Встигну все» — не відповідь; розкладаємо набір на зрізи за ризиком:

Що тут важливо:

• Фінальний крок обовʼязковий: озвучити менеджеру, що прогнали, що лишилось непокритим і який це ризик. Рішення про прийняття ризику ухвалює команда, але чесну картину дає QA — героїчне мовчання тут гірше за пропущений кейс.
• Розкладка не імпровізується під дедлайн. Якщо в наборі заздалегідь стоять пріоритети чи теги, «регресія за годину» — готовий зріз, і цей кейс займає хвилини планування, а не пів дня сортування.
• Impact analysis починається з розмови. Список релізних змін плюс питання розробникам «що ще може зачепитися?» коштує хвилини і формує другий рядок таблиці точніше за будь-які здогадки.

Кейс 3. Теги в Playwright: зрізи одного набору

Той самий регресійний набір має бігти по-різному: хвилини на кожен деплой, година перед релізом, усе — вночі. Механіка — теги в назвах тестів і запуск за --grep:

import { test, expect } from '@playwright/test';

// @smoke @critical — біжить і на кожен білд, і в годинному зрізі перед релізом
test('логін з валідними даними відкриває дашборд @smoke @critical', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('user@example.com');
  await page.getByLabel('Пароль').fill('correct-password');
  await page.getByRole('button', { name: 'Увійти' }).click();
  await expect(page).toHaveURL(/dashboard/);
});

// тест додано в регресію після фіксу бага #1042 — правило «знайшли баг → додали тест»
test('знижка 10% застосовується до кошика від 1000 грн @critical', async ({ page }) => {
  await page.goto('/cart?fixture=cart-1000');
  await expect(page.getByTestId('discount-line')).toHaveText('-100.00 грн');
});

// без тега — біжить лише в повному нічному прогоні
test('експорт історії замовлень у CSV', async ({ page }) => {
  await page.goto('/orders');
  const download = page.waitForEvent('download');
  await page.getByRole('button', { name: 'Експорт у CSV' }).click();
  expect((await download).suggestedFilename()).toMatch(/orders.*\.csv/);
});

npx playwright test --grep @smoke      # на кожен деплой: хвилини, гейт для білда
npx playwright test --grep @critical   # «регресія за годину» перед релізом
npx playwright test                    # повний набір: нічний прогін у CI

Що тут важливо:

• Тег — це готовий зріз. «Регресія за годину» стає командою, а не імпровізацією під дедлайн; пріоритизація з кейсу 2 вшита прямо в набір.
• Смоук — підмножина регресії, а не окремий набір. Тест з тегом @smoke біжить і в смоуку, і в повному прогоні — дублювати кейси не треба.
• Тест на #1042 зʼявився з бага. Так набір і росте: кожен пропущений колись дефект стає постійною перевіркою. Зворотний обовʼязок — чистка: коли експорт у CSV випиляють з продукту, його тест треба видалити, інакше за рік набір перетворюється на повільний зелений шум.

Смоук і саніті

• Можу пояснити, що смоук відповідає на бінарне питання «чи придатний білд для тестування», а не шукає максимум дефектів.
• Знаю пару характеристик: смоук — широкий і мілкий (broad and shallow), саніті — вузьке і глибоке (narrow and deep).
• Розумію, що смоук — гейт із жорстким таймбоксом (хвилини, не години): упав — білд відхилено, заплановане тестування не починається; у CI той самий набір називають build verification test (BVT).
• Знаю різницю наборів: смоук стабільний, документований і часто автоматизований; саніті зазвичай ситуативний, підбирається під конкретну зміну.
• Памʼятаю чесний факт: у глосарії ISTQB sanity — синонім smoke, а розрізнення «широкий/мілкий vs вузький/глибокий» — індустріальна конвенція, не стандарт.

Ретест і регресія

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

Обсяг регресії

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

Підтримка набору й автоматизація

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