AI у дослідницькому тестуванні й аналізі вимог

Що таке дослідницьке тестування і чому саме на цій фазі AI водночас корисний і небезпечний?

Дослідницьке тестування (exploratory testing) — це робота, де цінність не в «прогнати кроки за списком», а в «поставити правильне питання»: тестувальник одночасно вчиться про продукт, придумує перевірки й виконує їх. Спокуса підключити сюди LLM (large language model) виникає тому, що модель тоннами видає правдоподібний текст — начебто може накидати ідей, вичитати вимогу, поводити мишкою замість тебе. Частину справді може. Але саме тут проходить межа між AI-помічником і AI-милицею: помічник розширює твоє поле зору, милиця підміняє твоє судження середнім по корпусу. Практичний наслідок — на цій фазі AI підключають до відкриття (генерація гіпотез, структурування спостережень), а рішення «куди копати» лишають людині.

Чим фаза відкриття відрізняється від генерації тест-артефактів, і чому це важливо для ролі AI?

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

Як правильно сформулювати запит, щоб LLM видала предметні тест-ідеї, а не банальщину?

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

Опиши дивергентно-конвергентну модель роботи з AI над тест-ідеями.

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

Чому кажуть, що модель дає «типове, а не нове», і чому це головна межа генерації ідей?

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

Чи можна дати LLM вимогу, щоб вона знайшла в ній проблеми? Як це працює?

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

Чому вивід аналізу вимог — це список питань, а не список знайдених дефектів вимоги?

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

Як AI вбудовується в сесійне дослідницьке тестування, не підміняючи тестувальника?

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

Що таке «опонент-оракул» і чому ця роль AI корисна саме в сесії?

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

Чому чартер, кермо й відчуття ризику мають лишатися за людиною?

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

Що таке агентне дослідження UI і що агент технічно вміє?

Агент (agent) — це LLM у циклі з інструментами (agentic loop): вона обирає дію, викликає інструмент, читає результат і повторює. Керуючи браузером через, наприклад, Playwright MCP, такий агент уміє навігувати, клікати, читати дерево доступності (accessibility tree), картувати досяжні стани й накидати перший обхід незнайомого застосунку. Де це реально корисно: швидко скласти карту нового для тебе продукту, виявити досяжні екрани й переходи, нашкіцувати діаграму станів, зробити чорновий смоук-краул. Тобто агент добре розширює охоплення дослідження — але, як нижче, не закриває судження.

Агент проклікав застосунок і відрапортував, що все працює. Довіряєш такому висновку?

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

Які межі агентного дослідження UI варто назвати першими, крім відсутності оракула?

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

Як AI покращує баг-репорти і де тут головний ризик?

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

Як безпечно аналізувати логи через AI?

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

Що таке «вигадана кореляція» в логах і чому це підступніше за просту помилку?

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

Навіщо взагалі людина, якщо AI генерує тест-ідеї, вичитує вимоги й водить агентом?

Бо все перелічене — це розширення й структурування, а не судження. Модель тяжіє до типового (середнього по корпусу), а баг, який реально болить бізнесу, майже завжди нетиповий і доменний: у моделі немає цікавості, немає ставки в грі, немає уявлення про живого користувача з його дивними сценаріями. Тому робочий розподіл сталий: AI — щоб розширити лійку ідей, вичитати вимогу, поводити агентом, причесати репорт; людина — щоб вирішити, що важливо, і копнути глибше. Той, хто плутає ці ролі й чекає, що модель «протестує сама», отримує рівно охоплення happy path без жодного відкриття.

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

Кейс 1. Крайові випадки для поля промокоду: поганий промпт проти хорошого

Ти третю годину дивишся на форму оформлення замовлення, око замилилось. Просиш модель допомогти. Різниця в результаті — не в «розумі» моделі, а в тому, скільки контексту й структури ти їй задав.

Слабкий запит:

Дай тест-кейси на поле промокоду.

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

Ось поле промокоду в кошику. Правила: код 6–12 символів A–Z та 0–9,
регістронезалежний, одноразовий на акаунт, не стекується з іншими знижками.
Перелічи крайові випадки за категоріями: порожнє значення, регістр,
пробіли по краях, unicode-символи, гранична довжина (5/6/12/13),
вже використаний код, спроба стекування, застосування під час зміни валюти кошика.

Тепер порівняй, що дає модель і що лишається людині:

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

• Останній рядок таблиці — і є сенс людини. Випадок «промокод під час зміни валюти» випливає зі знання цього кошика й цих користувачів, а не зі статистики корпусу. Модель його не запропонувала, бо він нетиповий — а саме нетипове найчастіше й ламає бізнес.
• Двадцять пунктів від моделі — це лійка, а не покриття. Якщо взяти список як «повне покриття ідей» і піти тестувати, справжнє відкриття лишиться за моделлю. Її вивід треба відфільтрувати за ризиком, а не виконати цілком.
• Якість виводу = якість промпту. Категорії, правила поля й формат відповіді задав ти. Прибери їх — і навіть найкраща модель повернеться до «валідний / невалідний код».

Кейс 2. Вичитування критеріїв приймання: розсортувати кандидатів у питання

На рефайнмент прийшла user story з критеріями. Замість шукати діри очима на льоту, прогони текст через модель — вона бачила безліч специфікацій і швидко підсвітить типові провали форми.

User story: Користувач може вивести кошти на банківську картку.

Acceptance criteria:
1. Мінімальна сума виведення — 100 грн.
2. Кошти надходять протягом 3 робочих днів.
3. Якщо на балансі недостатньо коштів, показати помилку.

Промпт:

Ти рев'юер вимог. Знайди суперечності, неоднозначні формулювання
й незазначені випадки: порожній/граничний стан, обробку помилок, межі,
конкурентний доступ, припущення без підтвердження. Поверни список ПИТАНЬ,
а не тверджень.

Вивід моделі — це кандидати. Твоя робота — розсортувати їх, звіряючи з реальним продуктом:

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

• Модель однаково легко вигадує й пропускає. Рядок «від'ємна сума» — вигадана прогалина: у продукті її нема. А доменний ліміт «N виведень на добу» модель проґавила, бо він тримається на невисловленому правилі комплаєнсу, якого в тексті нема. Тому вивід — це чернетка питань, не список дефектів.
• Формат «поверни ПИТАННЯ» — навмисний. Так ти несеш на рефайнмент «а що при простроченій картці?», а не заводиш дефект вимоги наосліп. Рішення «це справді діра» лишається за тобою й власником продукту.
• Цінність — у швидкості чернетки. Те, що сильний тестувальник складає на рефайнменті вручну, модель накидає за секунди; далі економія часу лише на сортуванні, а не на думанні.

Кейс 3. Агентний обхід чекауту: чому «сторінка відкрилась» не дорівнює «сума правильна»

Агент (LLM у циклі з інструментами) через Playwright MCP пройшовся по чекауту й відрапортував: «Усі кроки працюють, замовлення оформлюється». Питання на співбесіді: довіряєш? Ні — бо в агента немає оракула.

Ось що агент фактично «побачив» на кроці з промокодом:

Крок: ввів SAVE10 у поле промокоду, натиснув «Застосувати».
Спостереження: сторінка оновилась, з'явився блок «Знижку застосовано».
Висновок агента: працює.

А ось перевірка, яку робить людина-оракул — і яку агент не зробив:

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

test('промокод SAVE10 реально зменшує суму на 10%', async ({ page }) => {
  await page.goto('https://shop.example.com/cart');

  const before = await page.getByTestId('cart-total').textContent();
  const subtotal = parseFloat(before!.replace(/[^\d.]/g, ''));

  await page.getByTestId('promo-input').fill('SAVE10');
  await page.getByTestId('promo-apply').click();

  // оракул: не «блок з'явився», а «підсумок = 90% від початкового»
  await expect(page.getByTestId('cart-total')).toHaveText(
    new RegExp((subtotal * 0.9).toFixed(2)),
  );
});

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

• Агент перевірив наявність, оракул — правильність. «Блок Знижку застосовано з'явився» і «сума справді зменшилась на 10%» — різні твердження. Агент зупиняється на першому, бо для нього успішна навігація й коректний результат нерозрізненні. Класична пастка: знижка відрендерилась у UI, але не відняла від суми — агент цього не зловить.
• Обхід дає карту, а не вердикт. Корисний вихід кейсу — перелік досяжних станів чекауту й чернетка сценаріїв (кошик → промокод → адреса → оплата). Це розширює охоплення. Асерти-оракули поверх цієї карти дописує людина.
• Небезпека живих дій. На кроці «оплатити» агент не відрізняє «клікнути, щоб дослідити» від «клікнути, щоб зняти гроші». Тому такий обхід ганяють у пісочниці з тестовою платіжкою й обмеженими дозволами, а не на проді.

Генерація ідей і крайових випадків

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

Аналіз вимог

• Розумію, чому LLM ловить діри у вимогах: суперечності й прогалини мають форму в тексті, а патерни в тексті — її стихія.
• Знаю робочий промпт: дати user story чи критерії приймання (acceptance criteria) і попросити конкретні категорії — порожній стан, помилки, межі, конкурентний доступ, невисловлені припущення.
• Можу пояснити, чому вивід — це список питань до аналітика, а не список знайдених дефектів вимоги.
• Знаю двобічне застереження: модель і вигадає прогалину, якої немає, і пропустить реальну, зав'язану на невисловлене доменне правило.

Дослідницька сесія з AI

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

Агентне дослідження UI

• Можу пояснити, що агент (agent) — це LLM у циклі з інструментами (agentic loop), що керує браузером через, наприклад, Playwright MCP.
• Знаю, де агент реально корисний: карта нового продукту, досяжні стани й переходи, чорновий смоук-краул.
• Розумію головну межу: в агента немає оракула — він бачить «сторінка відкрилась», а не «результат правильний», тож охоплення ≠ перевірка.
• Знаю решту меж: застрягає на модалках, капчах і логіні; повільний і палить токени; може виконати руйнівну дію, тож потребує пісочниці й обмежених дозволів.

Баг-репорти й аналіз логів

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

Головна межа

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