Дослідницьке тестування

Що таке дослідницьке тестування?

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

Чим дослідницьке тестування відрізняється від ad hoc?

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

Чим exploratory відрізняється від скриптованого підходу і коли обрати кожен?

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

Дослідницьке тестування — це відмова від тест-дизайну?

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

Чому exploratory вважається технікою для досвідчених, а не для новачків?

Виглядає навпаки — «кейси ж писати не треба», — але якість дослідження прямо пропорційна багажу тестувальника: його «нюху», знанню типових дефектів, умінню ставити продукту незручні питання. У силабусі ISTQB CTFL 4.0 дослідницьке тестування недарма стоїть серед досвідних технік (experience-based techniques), поруч із передбаченням помилок і чеклистами. Новачок без накопичених евристик знайде в сесії менше, ніж сеньйор за ті самі 90 хвилин, бо ідеї перевірок не беруться з повітря — їх дає досвід плюс евристики.

Що таке чартер і як його правильно сформулювати?

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

Розкажіть про сесійний підхід (SBTM). Яку проблему він розв'язує?

Session-based test management запропонували Джеймс і Джонатан Бахи як відповідь на головний закид менеджера: «як я дізнаюся, що ви там натестували?» SBTM робить дослідження вимірюваним і підзвітним, не вбиваючи гнучкості. Будова: чартер (місія) → сесія фіксованої довжини без перемикань → сесійний звіт (session sheet) з покриттям, багами й питаннями → дебриф з лідом чи командою. Питання й ризики з дебрифу перетворюються на нові чартери — цикл замикається. Для команди сесія стає обліковою одиницею: скільки сесій витрачено на область, скільки багів вони принесли, скільки чартерів у черзі — це і є звітність.

Чому сесія має фіксовану довжину і що таке розкладка setup/test/bug?

Таймбокс — зазвичай 60–120 хвилин без перемикань на інші задачі: коротше — не встигаєш заглибитися, довше — падає концентрація, а сесію стає важко обліковувати. Час сесії в SBTM розкладають на три види роботи: налаштування середовища (setup), власне тестування (test) і розслідування та документування багів (bug). Це не бюрократія, а діагностика: якщо 70% сесії з'їв setup — проблема не в тестувальнику, а в середовищі, і лікувати треба саме його. Така розкладка дає менеджеру чесну картину, куди насправді йде час дослідження.

Що відбувається на дебрифі і що таке PROOF?

Дебриф (debrief) — коротка розмова з лідом або командою після сесії. У SBTM для неї є агенда PROOF: Past (що робив), Results (що знайшов), Obstacles (що заважало), Outlook (що далі), Feelings (яке враження від якості). Дебриф — не формальність, а механізм замикання циклу: питання й ризики з нього перетворюються на нові чартери в беклог. Заодно це контроль якості самих сесій: лід бачить, чи чартер був виконаний, чи сесію з'їли перешкоди.

Як ви документуєте результати дослідницького тестування?

Під час сесії — не після — фіксується: чартер, білд і середовище (без них нотатки не мають контексту), маршрут (які області пройдено, з якими даними), баги і «майже баги» — дивна поведінка, яка поки не відтворюється, питання до аналітика чи розробника, ідеї для наступних чартерів. Форма легка: текстовий файл, session sheet у TMS, замітки з таймстемпами. Головне правило — нотатки пишуться під час сесії: через годину деталі вже втрачено, тому «потім задокументую» не працює, і кроки відтворення бага не збираються. Для вебу найцінніший додаток — вкладка Network і збережений HAR-файл: мережевий слід відповідає на «що саме тоді сталося» краще за пам'ять. Кандидат, який «ніяк не документує», exploratory насправді не робив — це фільтр практики.

Що таке тури Віттакера? Наведіть кілька прикладів.

Джеймс Віттакер у книзі «Exploratory Software Testing» запропонував метафору: продукт — місто, тестувальник — турист, а тур — маршрут із певним фокусом уваги. Приклади: тур грошей (money tour) — функції, за які продукт купують, падіння тут найдорожче; тур FedEx — слідувати за даними через усю систему від створення до експорту; тур саботажника (saboteur tour) — почати операцію і завадити їй: обірвати мережу, видалити файл, відкликати права; тур поганого району (bad neighborhood tour) — області, де вже знаходили баги, бо дефекти скупчуються; тур диванного лежня (couch potato tour) — мінімум зусиль, дефолтні значення, пропущені необов'язкові поля. Тури не взаємовиключні — це різні окуляри на ту саму фічу, а вибір туру — це вибір ризику: новому продукту — тур орієнтирів і грошей, перед релізом — поганий район, фічі з інтеграціями — FedEx.

Сесія триває, а ідеї закінчилися. Звідки брати наступні перевірки?

З евристик — компактних підказок, які розгортаються в десятки перевірок. SFDIPOT з Heuristic Test Strategy Model Джеймса Баха — сім кутів погляду на продукт: Structure, Function, Data, Interfaces, Platform, Operations, Time; застряг — пройдися списком, і мінімум один кут виявиться непокритим. Евристики даних: нуль / один / багато; порожній рядок, самі пробіли, юнікод, emoji, наддовгий текст; значення на межах і поза ними. Переривання й повтори: закрити вкладку посеред операції, натиснути «Зберегти» двічі, повернутися «Назад» після сабміту, зробити те саме у двох вкладках паралельно. Для регресії — RCRCRC Карен Джонсон: Recent, Core, Risky, Configuration-sensitive, Repaired, Chronic.

Як дослідницьке тестування поєднується з автоматизацією?

Це поділ праці, а не конкуренція. Автоматизація перевіряє відоме: автотест — скриптована перевірка очікування, яке хтось уже сформулював; вона захищає від регресії швидко, щоразу й однаково. Exploratory шукає невідоме: те, на що ніхто не написав перевірку, автотест не зловить за побудовою — він не вміє дивуватися. Найпрактичніший цикл: сесія знаходить баг → баг лагодять → перевірка стає регресійним автотестом, щоб знахідка не повернулася. Працює і зворотний напрям: перехоплення й мокання мережі дозволяє дослідити стани, які руками не викликати (помилка 500, порожній список, повільна мережа), а скрипт, що генерує дані чи доводить систему до потрібного стану, економить setup-час сесії. Тому «все автоматизують — мануальне помре» — навпаки: що більше рутини забирає автоматизація, то більше часу лишається на дослідження.

Команда пропонує замінити регресію дослідницькими сесіями. Ваші аргументи?

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

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

Кейс 1. Сесія за чартером: імпорт CSV від місії до дебрифу

Завдання зі спринту: у продукт додали імпорт контактів із CSV, вимоги описують лише щасливий шлях. Писати кейси нема на що — область для дослідження. Формулюємо чартер за формулою Гендріксон (ціль → ресурси → інформація) і йдемо в сесію на 90 хвилин.

ЧАРТЕР: Дослідити імпорт контактів із CSV, використовуючи файли
з нестандартними кодуваннями й розділювачами, щоб знайти
проблеми обробки даних.
Білд: 2.14.0-rc1, стенд: staging-2, браузер: Chrome 126

10:00 setup: готую файли — utf8/win-1251, роздільники "," і ";",
      порожній файл, 1 рядок, 10 000 рядків, emoji в іменах
10:25 test: win-1251 → імена кирилицею стали "????" — БАГ,
      скріншот + HAR збережено
10:40 test: файл із самим лише заголовком → вічний спінер — БАГ
10:55 test: 10 000 рядків → ок, але прогрес-бар стоїть на 0%
      до самого кінця — МАЙЖЕ БАГ, поки не зрозуміло, це UI чи бек
11:05 test: подвійний клік по "Імпортувати" → контакти
      задвоїлись — БАГ (евристика переривань/повторів)
11:20 bug: оформлюю три репорти з кроків у нотатках
ПИТАННЯ: чи підтримуємо ми взагалі win-1251? У вимогах тиша.
ІДЕЇ ДЛЯ ЧАРТЕРІВ: експорт тих самих даних (тур FedEx),
обрив мережі посеред імпорту (тур саботажника)

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

• Чартер тримає фокус, але не диктує кроки. Всередині місії «нестандартні кодування й розділювачі» тестувальник вільний — і саме тому подвійний клік по кнопці теж легітимна перевірка: евристика переривань спрацювала по дорозі.
• Розкладка часу — діагностика. Тут setup зайняв 25 хвилин з 90 — прийнятно. Якби готування файлів і стенда з'їло 70% сесії, висновок дебрифу був би не «мало багів», а «полагодьте середовище».
• «Майже баг» — теж знахідка. Прогрес-бар на 0% поки не відтворюється як дефект, але без запису в нотатках він зникне з пам'яті через годину. Наступна сесія або розробник поруч перетворять його на баг чи на «за дизайном».
• Нотатки пишуться під час сесії. Кроки відтворення всіх трьох багів уже лежать у таймлайні — репорти в кінці сесії збираються з нотаток, а не реконструюються з пам'яті.
• Дебриф за PROOF замикає цикл. Past і Results — таймлайн вище; Obstacles — питання про win-1251, яке блокує вердикт по першому багу; Outlook — два нові чартери в беклог; Feelings — «валідації на вході фактично немає, область сира».

Кейс 2. Таблиця рішень: скриптоване, exploratory чи ad hoc?

Типові ситуації спринту і чесний вибір підходу:

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

Кейс 3. Знахідка сесії стає регресійним автотестом

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

// Народжено сесією: після зміни валюти сума в кошику не перераховувалась
test('сума кошика перераховується після зміни валюти', async ({ page }) => {
  await page.goto('/cart');
  await expect(page.getByTestId('cart-total')).toContainText('₴');
  await page.getByLabel('Валюта').selectOption('EUR');
  await expect(page.getByTestId('cart-total')).toContainText('€');
});

Працює і зворотний напрям — інструменти автоматизації підсилюють саму сесію. Стан «сервер валют упав» руками не викликати, а перехопленням мережі — за секунду:

// Дослідження стану, якого не досягти руками: що покаже кошик на 500?
await page.route('**/api/rates**', (route) =>
  route.fulfill({ status: 500, body: 'Internal Server Error' }),
);
await page.goto('/cart');
// далі — очима: чи є повідомлення про помилку, чи просто вічний спінер?

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

• Автотест закриває відоме, сесія шукала невідоме. Ніхто не написав би цю перевірку заздалегідь — очікування «сума перераховується» сформулювала сама знахідка. Тепер воно відоме, і його щоразу однаково тримає регресія.
• Мок — не підміна тестування, а інструмент дослідження. page.route тут не асертить, а створює стан для спостереження; вердикт («вічний спінер — баг») виносить дослідник. Це і є «дослідник з інструментами бачить більше, ніж дослідник з самою лише мишкою».
• HAR-файл із сесії — половина баг-репорту. Мережевий слід із вкладки Network відповідає на «що саме тоді сталося» краще за пам'ять — і для бага з валютою одразу показав би, чи запит за курсом узагалі відправлявся.

Означення і межі підходу

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

Сесійний підхід (SBTM)

• Знаю будову SBTM (Джеймс і Джонатан Бахи): чартер → сесія з таймбоксом → сесійний звіт → дебриф — і чому саме сесія стає обліковою одиницею дослідження для менеджера.
• Можу сформулювати чартер за формулою Гендріксон: досліди ціль, використовуючи ресурси, щоб знайти інформацію — напрям без кроків.
• Знаю, чому таймбокс 60–120 хвилин (коротше — нема глибини, довше — падає концентрація), і розкладку часу setup/test/bug: 70% на setup — діагноз середовищу, а не тестувальнику.
• Знаю агенду дебрифу PROOF: Past, Results, Obstacles, Outlook, Feelings — і що питання з дебрифу стають новими чартерами.

Тури й евристики

• Можу пояснити метафору турів Віттакера і назвати кілька: тур грошей, FedEx, саботажника, поганого району, диванного лежня.
• Розумію, що вибір туру — це вибір ризику: новому продукту — орієнтири і гроші, перед релізом — поганий район, інтеграціям — FedEx.
• Знаю SFDIPOT як сім кутів погляду на продукт: Structure, Function, Data, Interfaces, Platform, Operations, Time — рятівний список, коли застряг.
• Пам'ятаю евристики даних (нуль/один/багато, порожній рядок, юнікод, наддовгий текст, межі) і переривань (закрити вкладку посеред операції, подвійний сабміт, дві вкладки паралельно).
• Знаю RCRCRC Карен Джонсон для вибору, що дослідити в регресії: Recent, Core, Risky, Configuration-sensitive, Repaired, Chronic.

Нотатки й місце поруч з автоматизацією

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