AI в тестуванні

Що таке LLM і як вона працює простими словами?

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

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

Як AI допомагає в роботі QA?

• Аналіз вимог: знайти неоднозначності, пропущені сценарії, питання до PM.
• Тест-дизайн: чернетки тест-кейсів і чеклістів, граничні значення, негативні сценарії.
• Тестові дані: згенерувати JSON, CSV, набори невалідних значень.
• Баги: структурувати баг-репорт, розібрати стек-трейс чи лог.
• Автоматизація: чернетки коду автотестів, локаторів, SQL-запитів; Copilot у редакторі.
• Документація: тест-план, звіт, release notes з переліку задач.

Спільне для всього: AI робить чернетку швидше, але рішення, перевірка і відповідальність — на QA.

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

• Контекст: опис фічі, критерії приймання, обмеження, бізнес-правила.
• Роль: «Ти Senior QA, тестуєш платіжну форму».
• Техніки: «застосуй класи еквівалентності й граничні значення, додай негативні сценарії».
• Формат: таблиця з колонками ID, передумови, кроки, очікуваний результат, пріоритет.
• Приклад одного хорошого кейсу, щоб модель повторила стиль.
• Ітерації: «що я пропустив з безпеки?», «додай сценарії збоїв мережі».

Погано:
  Напиши тест-кейси для переказу.

Добре:
  Ти Senior QA у фінтех-продукті. Фіча: переказ з картки на картку.
  Правила: сума 1–10 000 UAH, 2 знаки після коми, денний ліміт 20 000,
  комісія 1%, мінімум 5 UAH.
  Застосуй класи еквівалентності та граничні значення, додай негативні
  сценарії, подвійну відправку і тайм-аут.
  Формат: таблиця ID | Передумови | Кроки | Очікуваний результат | Пріоритет.
  Окремо випиши питання до вимог, які залишилися незрозумілими.

Що таке галюцинації і чому відповідь AI не можна брати як є?

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

Що з цього випливає для QA:

• Згенеровані кейси звіряти з реальними вимогами: модель могла додати власні «правила».
• Код запускати й рев'ювати, як код колеги на PR.
• Методи, команди й параметри звіряти з документацією.
• AI не знає вашого продукту, історії багів і домовленостей у команді — покриття від нього ніколи не повне.

Які дані не можна передавати в AI-інструменти?

• Персональні дані клієнтів, реальні дампи бази.
• Паролі, токени, API-ключі, конфіги з секретами.
• Код і документацію клієнта, якщо компанія не дозволила конкретний інструмент.
• Дані, що підпадають під NDA.

Правило: використовувати лише інструменти, погоджені компанією (корпоративні плани, де дані не йдуть на навчання моделей), і знеособлювати все, що передаєш. Якщо політики немає — спитати, а не припускати.

Як тестувати фічі, побудовані на LLM (чат-бот, асистент)?

Головна відмінність — недетермінованість: на той самий запит відповідь щоразу трохи інша, тому перевірка «відповідь дорівнює X» не працює.

• Критерії замість точного тексту: відповідь містить потрібні факти, не містить заборонених, правильна мова й тон, формат відповідає вимогам.
• Набір еталонних запитів (eval set) з очікуваною якістю, який проганяють після кожної зміни промпту чи моделі.
• Prompt injection: спроби змусити бота ігнорувати інструкції, розкрити системний промпт або дані інших користувачів.
• Галюцинації: питання, на які бот має відповісти «не знаю» або передати людині.
• Межі: бот не дає порад поза своєю роллю, не виконує дій без підтвердження.
• Нефункціональне: час відповіді, вартість запитів, поведінка при недоступності моделі.

Які обмеження AI-генерації тест-кейсів?

• Не знає контексту продукту: інтеграцій, історії інцидентів, рішень команди.
• Генерує багато очевидних кейсів і мало глибоких: гонок, станів, нетипових даних.
• Може вигадати правила, яких немає у вимогах.
• Дублює кейси й не пріоритизує за ризиком.
• Якість прямо залежить від якості вимог: з поганих вимог вийдуть погані кейси.

Тому сильніший підхід — просити AI не «написати кейси», а знайти прогалини у вимогах і в уже написаних кейсах.

Розкажи, як ти використовуєш AI у своїй роботі.

Це питання про твій досвід, тож відповідь має бути конкретною: інструмент → задача → результат → як ти перевіряв. Структура:

1. Які інструменти і де: Copilot у редакторі, Claude чи ChatGPT для аналізу вимог і документації.
2. Конкретна задача: наприклад, чернетки степ-дефінішенів, тест-кейси з критеріїв приймання, рев'ю PR.
3. Результат, бажано з цифрою: швидше на X, менше рутини.
4. Як контролював якість: рев'ю, запуск, звірка з вимогами.
5. Межі: що не передаєш в AI і де він не допомагає.

Не перебільшуй: інтерв'юер майже завжди спитає деталі, і відповідь має бути з твого досвіду.

Як AI змінює роль QA і чи замінить він тестувальників?

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

Збалансована відповідь: AI не замінить QA, але QA, який ефективно використовує AI, замінить того, хто не використовує.

AI-інструменти в роботі QA

Для коду використовую AI-асистентів у IDE: GitHub Copilot, Cursor, Claude Code. Вони пришвидшують написання автотестів, Page Objects, custom commands і рефакторинг. Також допомагають розібратися в чужому коді та знайти причину падіння тесту за логом.

Чат-асистенти (Claude, ChatGPT) використовую для генерації ідей тест-кейсів і чек-листів з вимог, пошуку граничних та негативних сценаріїв. Також — для генерації тестових даних, SQL-запитів, JSON-схем і регулярних виразів. Корисно просити AI проаналізувати вимоги на суперечності та пропущені кейси.

Інші застосування: написання баг-репортів і документації, переклад, самохілінг локаторів у деяких платформах, аналіз великих логів. Важливо згадати й обмеження: не передаю в зовнішні AI-сервіси конфіденційні дані, токени та персональні дані користувачів.

Ризики AI-згенерованих тестів і коду

AI може згенерувати тести, які перевіряють не те, що треба, або дублюють поточну поведінку разом із багами. Часто зустрічаються вигадані API, методи чи опції бібліотек, яких не існує, або застарілий синтаксис. Згенерований код може містити антипатерни: фіксовані очікування, крихкі селектори, відсутність асершенів.

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

Валідую так: кожен згенерований тест читаю й розумію, звіряю з вимогами, перевіряю, що він падає, коли функціонал зламано. Код проходить той самий code review, лінтер і CI, що й написаний вручну. Відповідальність за результат лишається на мені, AI — лише інструмент.

Тестування недетермінованої LLM-фічі

Оскільки відповідь щоразу різна, точне порівняння рядків не працює, тому перевіряємо властивості відповіді, а не конкретний текст. Наприклад: відповідь містить ключову інформацію, відповідає на питання, має потрібний формат, мову й довжину, не містить заборонених тем. Це схоже на property-based підхід.

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

Допоміжні прийоми: зниження temperature до 0 для відтворюваності на тестовому середовищі, фіксація версії моделі й промпта. Також перевіряю граничні випадки: порожній запит, дуже довгий текст, інша мова, неоднозначне питання, нерелевантний запит. І обов'язково регресія при зміні промпта чи моделі.

Галюцинації

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

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

Автоматизовано: порівняння з еталонною відповіддю з golden dataset, перевірка faithfulness — чи кожне твердження відповіді підтверджується контекстом. Для цього використовують LLM-as-a-judge та фреймворки на кшталт RAGAS, DeepEval чи promptfoo. Метрики: faithfulness, answer relevancy, context precision.

Критерії якості відповіді LLM

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

Golden dataset — еталонний набір запитів з очікуваними відповідями або критеріями, підготовлений і перевірений людьми. На ньому проганяють кожну нову версію промпта чи моделі й порівнюють метрики. Він працює як регресійний набір для LLM.

Рубрика — чітка шкала оцінювання, наприклад 1–5 за кожним критерієм з описом кожного рівня. LLM-as-a-judge — коли інша модель оцінює відповідь за рубрикою, що дає масштабування оцінки. Але суддю треба калібрувати: вибірково звіряти його оцінки з людськими.

Prompt injection і jailbreak

Prompt injection — атака, коли зловмисник вставляє інструкції, які змушують модель ігнорувати системний промпт. Пряма — у повідомленні користувача, наприклад «Ignore previous instructions and...». Непряма — через дані, які модель читає: вебсторінку, документ, лист, відповідь API.

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

Як тестую: набір атакуючих промптів з відомих каталогів, наприклад OWASP Top 10 for LLM, перевірка витоку системного промпта й конфіденційних даних. Також перевіряю, що модель не виконує небезпечних дій через інструменти без дозволу. Автоматизувати допомагають promptfoo, Garak та інші red-teaming інструменти.

Автоматизація перевірок LLM-відповідей

Перший рівень — детерміновані перевірки: структура JSON за схемою, наявність обов'язкових полів, довжина, мова, ключові слова, відсутність заборонених слів чи персональних даних. Вони швидкі й дешеві, тож їх запускають на кожен коміт. Це можна робити й у звичайному Cypress чи Playwright тесті через API.

Другий рівень — семантичні перевірки: порівняння відповіді з еталоном через embeddings і косинусну подібність з порогом, наприклад 0.8. Третій — LLM-as-a-judge з рубрикою, який оцінює коректність, релевантність і тон. Для RAG додаються метрики faithfulness і context relevance.

Через недетермінізм кожен кейс проганяють кілька разів і рахують відсоток успішних відповідей. На тестах можна зменшити temperature, але фінальна оцінка має бути на продакшн-налаштуваннях. Результати відстежують у часі, щоб бачити регресію після зміни промпта чи моделі.