🚀 QA 3.0: Забудьте про промпти. Наступний
крок — AI-Агенти, які тестують самі

Привіт, екіпаж!

Ми з вами вже майстри у написанні промптів: "напиши 10 тест-кейсів", "знайди баг в цьому коді", "згенери SQL-запит". Це рівень QA Co-pilot — ми керуємо, AI допомагає.

Але що, як я скажу вам, що наближається наступний етап, який переверне гру? Це — Автономні AI-Агенти.

У чому різниця?

🔹Co-pilot (сьогодні): Ви даєте йому код і просите написати тест.

🔹Агент (завтра): Ви даєте йому посилання на сайт і кажете: "Піди і протестуй флоу реєстрації".

І він сам іде на сторінку, сам знаходить поля, сам вирішує, які дані ввести (позитивні, негативні), сам натискає кнопки і сам робить висновок про успіх чи невдачу.

Це не фантастика. Такі інструменти вже активно розробляються. Це AI, який може "бачити" екран, "розуміти" контекст і "діяти" самостійно, щоб досягти мети.

Що ж тоді залишається нам, тестувальникам? Наша робота стає ще в 10 разів цікавішою і складнішою. Ми перетворюємося з "тестерів" на "Тренерів AI" та "Навігаторів":

1️⃣Постановка Мети (Навігатор): Наша задача — не "напиши 5 тест-кейсів", а "Переконайся, що новий користувач може купити найдорожчий товар і застосувати промокод". Ми ставимо бізнес-цілі.

2️⃣Валідація Результатів (Суддя): Коли Агент каже "я все перевірив, все ок", наша робота — критично оцінити його звіт. А чи не пропустив він ключовий edge-кейс? Чи правильно він "зрозумів" задачу?

3️⃣Навчання (Тренер): Якщо Агент "збожеволів" і почав клікати не туди, наша задача — проаналізувати його логіку і скоригувати його "поведінку" на майбутнє.

Висновок: Майбутнє QA — це не про написання коду для тестів. Це про створення інструкцій для інших AI, які будуть писати і запускати ці тести. Ми переходимо від інженерії до "оркестрування".

А ви готові стати "тренером" для AI-агентів? Чи це вже занадто і звучить лякаюче? Поділіться думками в коментарях! 👇

💸 QA — це "центр витрат"? Як за 5 хвилин з AI довести менеджеру, що ви економите мільйони

Привіт, екіпаж!

Усі ми чули цей стереотип: "Розробники створюють цінність, а QA — лише витрачає час і гроші". Ми знаходимо 50 багів, але менеджмент бачить лише "затримку релізу".

Чому? Бо ми звітуємо про кількість багів, а не про вартість цих багів.

Давайте змінимо це. Давайте перестанемо бути просто "шукачами багів" і станемо "Менеджерами Ризиків". І в цьому нам допоможе наш Co-pilot, виступивши в ролі Фінансового Аналітика.

Практичний кейс: Ви знайшли критичний баг: "У мобільному додатку не працює оплата через Apple Pay, якщо в кошику є акційний товар".

❌ Поганий репорт: "Severity: Critical. Priority: High. Apple Pay не працює."

✨ Промпт "Бізнес-Аналітик":

Виступи в ролі досвідченого Product Manager в e-commerce. Я QA, знайшов критичний баг.

**Баг:** "В нашому мобільному додатку (iOS) не працює оплата через Apple Pay, якщо в кошику є хоча б один акційний товар."

**Контекст (вигаданий):**
- 30% наших мобільних платежів проходять через Apple Pay.
- 50% всіх замовлень містять акційні товари.

**Завдання:**
Напиши 3-4 переконливі тези для менеджменту, які переводять цей баг у **фінансові втрати**. Оціни потенційний щоденний збиток, якщо наш денний обіг $100,000.

✅ Приклад результату, який видасть AI:

Аналіз впливу на бізнес:

1️⃣Пряма втрата доходу: Базуючись на наданих даних, цей баг блокує (30% користувачів Apple Pay) * (50% замовлень з акціями) = 15% всіх мобільних транзакцій.

2️⃣Фінансові збитки (ROI): При денному обігу в $100,000, ми потенційно втрачаємо до $15,000 щодня, поки цей баг на продакшені. Виправлення цього бага окупиться за кілька годин.

3️⃣Відтік клієнтів (LTV): Користувач, який не зміг оплатити найзручнішим для нього способом (Apple Pay), з високою ймовірністю не повернеться і піде до конкурента. Ми втрачаємо не тільки одне замовлення, а й довічну цінність клієнта.

4️⃣Репутаційні втрати: Це прямий удар по репутації нашого бренду як надійної e-commerce платформи.

Висновок: Ви щойно перетворили "просто баг" на аргументований бізнес-кейс на $15,000. Тепер менеджмент бачить у вас не "витратний матеріал", а захисника прибутку.

Це і є рівень Co-pilot'а.

А ви коли-небудь рахували, скільки грошей зекономили вашій компанії? Поділіться в коментарях! 👇

✈️ Ваш Co-pilot марний, якщо ви не вмієте літати: Чому теорія QA — це ваш головний двигун

Привіт, екіпаж!

Сьогодні хочу поговорити про одну небезпечну ілюзію. З появою AI багато хто вирішив: "Навіщо мені вчити нудний ISTQB? Навіщо мені ці класи еквівалентності? Я просто попрошу AI згенерувати мені тест-кейси!"

Але ось правда: AI — це лише потужний інструмент. Це мультиплікатор. І якщо ви множите на нього "нуль" знань, ви отримаєте "нуль" результату.

AI не розуміє, що він робить. Він просто вгадує наступне слово на основі патернів. Ваше завдання — керувати ним, а для цього потрібен фундамент.

Давайте на реальному прикладі:

❌ Промпт Новачка (який не знає теорії):

"Напиши тест-кейси для поля 'Вік', де можна вводити від 18 до 65."

✅ Результат AI: Ви отримаєте банальщину:

1️⃣Ввести 25 (валідно).
2️⃣Ввести 16 (невалідно).
3️⃣Ввести 70 (невалідно).

Це погане тестування!

✅ Промпт Інженера (який знає теорію):

"Виступи в ролі Senior QA. Напиши тест-кейси для поля 'Вік' (діапазон 18-65), застосовуючи техніки 'Аналіз Граничних Значень' (3-точковий) та 'Класи Еквівалентності'."

🔥 Результат AI: Ви отримаєте професійний набір тестів:

1️⃣Класи Еквівалентності (Невалідні):
🔹10 (менше 18)
🔹100 (більше 65)

2️⃣Класи Еквівалентності (Валідний):
🔹35 (усередині діапазону)

3️⃣Аналіз Граничних Значень (Нижня межа):
🔹17 (невалідно)
🔹18 (валідно)
🔹19 (валідно)

4️⃣Аналіз Граничних Значень (Верхня межа):
🔹64 (валідно)
🔹65 (валідно)
🔹66 (невалідно)

Висновок: AI не придумав "Аналіз Граничних Значень". Ви йому сказали це зробити. Він не знає, що тестувати, поки ви не скажете йому, як тестувати.

AI — це ваш другий пілот (Co-pilot), але саме ви є головним пілотом. Якщо ви не знаєте основ навігації (теорії QA), ви обоє просто влетите в гору.

Вчіть базу. Вчіть ISTQB. Тоді AI перетворить вас з простого тестувальника на інженера з надздібностями.

А ви освіжаєте свої знання з теорії? Чи вважаєте, що це вже застаріло? Поділіться в коментарях! 👇

🕵️ AI-Детектив: Використовуємо техніку "5 Чому" для пошуку справжньої причини багів

Що відбувається, коли ви знаходите баг? Зазвичай його виправляють, закривають тікет, і всі йдуть далі. І це — величезна помилка.

Якщо не знайти першопричину (Root Cause), цей самий баг (або його "брат-близнюк") з'явиться знову в іншому місці.

Є класична техніка — "5 Чому" (5 Whys), яка допомагає докопатися до істини. Але проводити такий аналіз самому складно. На щастя, у нас є Co-pilot, який ідеально грає роль неупередженого слідчого.

Практичний кейс: Уявімо, ми знайшли баг: "Користувач зміг купити товар, якого не було на складі (Out of Stock)."

✨ Готовий промпт "AI-Детектив":

Виступи в ролі досвідченого QA Architect. Я проводжу Root Cause Analysis (RCA) для критичного бага, використовуючи техніку "5 Чому".

**Баг:** "Користувач зміг успішно купити товар, у якого на складі була кількість '0'."

**Завдання:**
Проведи симуляцію "5 Чому", ставлячи послідовні запитання, щоб знайти найглибшу першопричину. Запропонуй найбільш імовірні відповіді на кожному кроці.

✅ Приклад результату, який видасть AI:

Симуляція "5 Чому":

1️⃣Чому? (Користувач зміг купити?)
🔹Відповідь: Тому що кнопка "Купити" на сайті була активною, хоча в базі даних товару вже не було.

2️⃣Чому? (Кнопка була активною?)
🔹Відповідь: Тому що дані про залишки на сайті (у фронтенд-кеші, напр. Redis) не оновилися (не інвалідувалися), коли в основній базі даних (PostgreSQL) кількість товару стала 0.

3️⃣Чому? (Кеш не оновився?)
🔹Відповідь: Тому що бекенд-сервіс stock-service (який відповідає за склад) не відправив повідомлення про оновлення кешу.

4️⃣Чому? (Сервіс не відправив повідомлення?)
🔹Відповідь: Аналіз коду показує, що сервіс відправляє повідомлення тільки тоді, коли замовлення успішно оформлене. Але він не відправляв повідомлення, коли залишки оновилися іншим шляхом (наприклад, менеджер вручну змінив кількість в адмінці, або прийшов інший скрипт інвентаризації).

5️⃣ЧОМУ? (Першопричина):
🔹Відповідь: Процес оновлення кешу був "прив'язаний" тільки до флоу покупки, але не до всіх можливих сценаріїв зміни залишків.

🔥 Першопричина: Процесна помилка та прогалина в архітектурі. Потрібно не просто "пофіксити" баг, а додати тригер оновлення кешу на всі події, що змінюють кількість товару.

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

А ви проводите RCA для своїх багів? Поділіться в коментарях! 👇

💰 QA + AI = $$$? Як конвертувати навички промптингу в підвищення зарплати

Давайте про головне. Про гроші.

Ринок зараз складний. Конкуренція шалена. Роботодавці хочуть "сеньйора за ціною мідла". Як у такій ситуації не просто втриматися, а вибити собі "AI-премію"?

Багато хто приховує від менеджера, що використовує AI, боячись почути: "А, то за тебе все робить GPT? Тоді нащо тобі платити?"

Це помилка.

Ваша стратегія має бути протилежною: "Я використовую AI, тому я даю результат за двох, і коштую дорожче, ніж звичайний QA".

Ось як це аргументувати мовою цифр:

1️⃣Швидкість Delivery: "Завдяки автоматизації рутини через AI, я скоротив час на регресію з 2 днів до 4 годин. Ми релизимось частіше."

2️⃣Покриття: "Я згенерував і перевірив на 40% більше edge-кейсів, ніж це фізично можливо вручну. Кількість багів на проді впала."

3️⃣Розширення ролі: "AI допоміг мені закрити дірки в аналітиці та DevOps (налаштування Docker, SQL), на що раніше треба було залучати інших людей."

Практичний кейс: Тренування переговорів про зарплату

Боїтеся йти просити рейз? Потренуйтеся з AI! Він може бути дуже жорстким опонентом.

✨ Готовий промпт "Salary Negotiation Simulator":

Виступи в ролі скептичного Engineering Manager. Я прийшов просити підвищення зарплати на 20%.

**Мої аргументи:**
- Я впровадив AI-інструменти, що прискорило написання тест-кейсів на 50%.
- Я зменшив кількість пропущених багів на 15% завдяки AI-аналізу вимог.

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

Висновок: AI — це ваш важіль. Використовуйте його, щоб підняти важчу вагу, ніж можуть інші, і вимагайте за це відповідну винагороду.

А ви вважаєте використання AI аргументом для підвищення зарплати? Чи краще про це мовчати? 👇

⏳ "А у мене вчора, а на сервері завтра": Як тестувати Час і Дати без болю

Привіт, екіпаж!

Якщо ви хоч раз тестували календар, розклад або звіти, ви знаєте цей біль.

🔹"Чому подія, створена о 23:00 в Києві, показується як "вчора" в Лондоні?"

🔹"Що буде 29 лютого?"

🔹"Як система поведе себе при переході на літній час?"

Баги з часом — найпідступніші. Вони "сплять" місяцями і вибухають в найгірший момент.

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

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

✨ Готовий промпт для "Test Data Generation":

Виступи в ролі Senior QA. Мені потрібен набір тестових даних (у форматі ISO 8601) для перевірки обробки часу та дат.

**Завдання:**
Згенеруй 5 "хитрих" timestamp-ів, які найчастіше ламають систему, і поясни, що саме кожен з них перевіряє.

**Включи такі сценарії:**
1.  Перехід на літній/зимовий час (DST gap).
2.  Високосний рік (Leap year).
3.  Перетин півночі (коли у користувача ще "сьогодні", а в UTC вже "завтра").
4.  Різні формати часових поясів (Z, offset).

✅ Приклад результату, який видасть AI:

1️⃣Високосний рік (Leap Day): 2024-02-29T12:00:00Z — Перевіряє, чи система знає, що у 2024 році є 29 лютого. Багато систем "падають", очікуємо 1 березня.

2️⃣Перехід на літній час (DST - втрачена година): 2024-03-31T03:30:00+03:00 (для Києва) — Перевірка, як система обробляє час, якого "не існує" або який дублюється при переведенні годинників.

3️⃣"Машина часу" (Перетин дати): 2023-12-31T23:59:59-11:00 (Самоа) vs 2024-01-01T00:00:00+14:00 (Кірібаті) — Це один і той самий момент часу, але різні роки в локальному часі. Чи правильно система сортує такі події?

4️⃣Нульовий рік (Edge case): 0000-01-01T00:00:00Z — Перевірка, як база даних обробляє дуже старі дати (іноді використовується як default value).

Висновок: Копіюєте ці дати -> вставляєте в поле/API -> дивитесь результат. Ви щойно покрили найскладніші кейси, не відкриваючи календар.

А які "часові парадокси" зустрічалися вам? Діліться в коментарях! 👇

🔮 Техніка "Pre-Mortem": Як пережити провал... до того, як він станеться

Всі знають, що таке "Post-Mortem" — це сумний мітинг, де команда обговорює, чому впав прод і хто винен.

Але найкрутіші інженери роблять "Pre-Mortem". Це ментальна вправа: ви уявляєте, що майбутній реліз вже провалився, і намагаєтесь "згадати", що саме пішло не так.

Людині важко бути песимістом щодо власної роботи ("та все буде добре!"). А от AI — ідеальний песиміст і критик.

Практичний кейс: Ви готуєте до релізу нову систему "Кешбек за покупки".

✨ Готовий промпт "Катастрофа в майбутньому":

Виступи в ролі досвідченого, скептичного Технічного Директора (CTO).

**Контекст:** Ми плануємо запустити нову систему кешбеку.
**Сценарій:** Уяви, що пройшов місяць після релізу, і він став повною катастрофою. Клієнти лютують, бізнес втрачає гроші.

**Завдання:**
Напиши "Звіт про причини провалу". Назви 5 найбільш ймовірних технічних або логічних причин, чому ця система могла зламатися.
(Подумай про: накрутку кешбеку, подвійні списання, навантаження, округлення копійок, повернення товару).

✅ Що видасть AI (Причини вашого майбутнього "звільнення"):

1️⃣Fraud-схема: "Користувачі купували дорогий товар, отримували кешбек, виводили його, а потім робили повернення товару. Ми забули списувати кешбек при поверненні."

2️⃣Race Condition: "Скріпт нарахування запускався двічі при поганому інтернеті, подвоюючи бонуси."

3️⃣Проблема округлення: "Через помилки float накопичилася розбіжність у фінансових звітах на тисячі гривень."

Висновок: Цей список — це ваш готовий план тестування. Ви не просто перевіряєте "чи працює". Ви перевіряєте "чи не вб'є це нас".

AI допомагає зняти "рожеві окуляри" і побачити ризики, які зазвичай стають очевидними лише постфактум.

А ви пробували бути песимістом до релізу? 👇

🏦 Як тестувати Фінтех чи Медицину, якщо ви не банкір і не лікар? AI як Доменний Експерт

Одна з найскладніших речей при зміні роботи — це не вивчення нових тулів, а занурення в нову доменну область.

Ви прийшли в проєкт логістики, і вам кажуть: "Перевір розрахунок об'ємної ваги згідно з правилами IATA". Або у фінтеху: "Перевір флоу KYC для юрисдикції UK". 🤯

Раніше на онбординг і читання Вікіпедії йшли тижні. Зараз ваш Co-pilot може пояснити будь-який бізнес-процес і — що найважливіше — підказати специфічні для цієї сфери баги.

Практичний кейс: Ви влаштувалися в Healthcare-стартап і тестуєте форму запису пацієнта.

✨ Готовий промпт "Доменний Ментор":

Виступи в ролі експерта з медичного ПЗ (MedTech) та відповідності стандартам (HIPAA/GDPR).

Я тестую форму реєстрації пацієнта в новій системі.
Поля: Ім'я, Дата народження, Симптоми, Фото страхового полісу.

**Завдання:**
1.  Назви 3 критичні **ризики** для такої форми саме в медичній сфері (безпека, приватність).
2.  Які специфічні **тест-кейси** я маю перевірити, про які не подумав би тестувальник звичайного інтернет-магазину? (Наприклад, зберігання чутливих даних, вік згоди тощо).

✅ Приклад інсайтів від AI:

1️⃣PHI (Protected Health Information): Поле "Симптоми" — це чутлива інформація. Перевір, чи не кешується вона в браузері і чи не потрапляє в URL-рядок.

2️⃣Вік згоди: Якщо пацієнту менше 18 (або 13, залежно від країни), система має вимагати згоду опікуна. Звичайний валідатор "18+" тут не підходить, бо діти теж хворіють.

3️⃣Формат файлів: Для MedTech критично, щоб фото документів (страховка) не стискалися до нечитабельного стану, але й не були вірусами (безпечне завантаження).

Висновок: За 5 хвилин ви отримуєте розуміння специфіки, на яке пішли б місяці досвіду. Це дозволяє вам на першому ж мітингу ставити правильні, професійні запитання і виглядати компетентно.

А в яких складних доменах доводилося працювати вам? Де був найважчий поріг входження? Діліться історіями! 👇

💻 Відчуй себе хакером: Як AI та Консоль браузера роблять вашу роботу за секунду

Привіт, екіпаж!

Уявіть задачу: ви тестуєте каталог товарів. На сторінці 50 карток. Вам треба переконатися, що у кожного товару є назва і ціна не дорівнює нулю.

👀 Спосіб "Звичайний": Скролити, дивитися очима, витратити 15 хвилин, пропустити один товар.
😎 Спосіб "QA Co-pilot": Попросити AI написати "одноразовий скрипт", вставити його в консоль браузера і отримати результат миттєво.

Вам не треба знати JavaScript. Вам треба просто знати, що ви хочете перевірити.

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

1️⃣Натисніть F12 -> вкладка Console.

2️⃣Подивіться, який клас у заголовків (напр., клікніть правою кнопкою на заголовок -> Inspect, бачимо <h3 class="product-title">iPhone 15</h3>).

✨ Готовий промпт:

Виступи в ролі Front-end розробника.
Напиши мені JavaScript-код (сніпет), який я можу вставити в консоль браузера Chrome.

**Завдання:**
1.  Знайти на сторінці всі елементи з класом `.product-title`.
2.  Витягнути з них текст.
3.  Вивести цей список у консоль у зручному форматі (або просто списком, або таблицею).

✅ Результат від AI (код, який ви просто копіюєте):

const titles = Array.from(document.querySelectorAll('.product-title'))
                    .map(el => el.innerText);
console.table(titles);

Що відбудеться? Ви вставляєте це в консоль, тиснете Enter — і бачите акуратну таблицю з усіма назвами. Ви можете скопіювати її в Excel і звірити.

Що ще можна перевірити так само?

🔹"Знайди всі посилання (a), які не починаються з https".

🔹"Підрахуй кількість кнопок Купити на сторінці".

🔹"Перевір, чи є на сторінці картинки без атрибуту alt".

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

А ви користуєтесь консоллю для тестування? 👇

📜 Документація з повітря: Як тестувати, коли вимог немає (або вони брешуть)

Класика жанру: ви приходите на проект, а там... тиша. Документації немає, або вона писалася 3 роки тому. Розробники кажуть: "Ну, воно працює так, як працює. Тестуй".

Як зрозуміти, це баг чи фіча, якщо немає з чим порівняти?

Замість того, щоб гадати, використовуйте AI як "відновлювача вимог". Він може проаналізувати шматок коду або ваші нотатки і "народити" ідеальну документацію.

Практичний кейс: Ви бачите дивну логіку нарахування бонусів у коді (або в поведінці системи), але не впевнені, чи так має бути.

✨ Готовий промпт "Reverse Engineering":

Виступи в ролі Business Analyst та QA Lead.

Я знайшов цей фрагмент коду (або опис поведінки системи), але у нас немає документації.
**Код/Логіка:**
[Вставте код або опишіть: "Коли користувач купує товар А, знижка 5% дається тільки якщо це вівторок, але якщо у нього Premium, то знижка 10% завжди"]

**Завдання:**
1.  Сформулюй чіткі **Бізнес-Вимоги (User Story & Acceptance Criteria)**, які б описували цю логіку.
2.  Знайди **логічні прогалини** або суперечності в цій логіці (наприклад, "А що, якщо вівторок І Premium? Знижки сумуються чи береться більша?").
3.  Напиши тест-кейси для перевірки цих спірних моментів.

✅ Що ви отримаєте:

1️⃣Готову документацію, яку можна затвердити з Product Owner'ом ("Дивись, система зараз працює О ТАК. Це те, що ми хотіли?").

2️⃣Список "дірок" у логіці, які ви миттєво перетворюєте на баги або уточнення.

Висновок: Ви не просто тестуєте. Ви створюєте порядок із хаосу. Ви стаєте тим, хто володіє істиною про проект. Це найшвидший спосіб стати незамінним у команді.

А вам часто доводиться працювати без ТЗ? 👇

🚌 Тури тестування: Як перетворити нудну
регресію на захопливу подорож

Привіт, екіпаж!

Іноді фантазія закінчується. Ви дивитесь на додаток і не знаєте, що ще перевірити. Ви вже пройшли всі чек-листи, але відчуваєте, що баги ще є.

У таких випадках рятують "Тури тестування". Це коли ви обираєте конкретну "роль" або "маршрут" і фокусуєтесь тільки на ньому.

А щоб не вигадувати маршрут самому, попросіть AI стати вашим Гідом.

✨Ось 3 популярні тури і як їх "завести" з AI:

1️⃣💅 Тур "Супермодель" (The Supermodel Tour) Фокус тільки на зовнішності. Логіка не важлива, головне — краса.
✨ Промпт:

"Виступи в ролі QA-дизайнера. Ми проводимо 'Тур Супермоделі' для сторінки профілю користувача. Напиши мені чек-лист з 10 пунктів, які стосуються ВИКЛЮЧНО візуальної частини (відступи, шрифти, анімації, плейсхолдери, кольори помилок), ігноруючи функціонал."

2️⃣📦 Тур "FedEx" (The FedEx Tour) Фокус на даних. Ви — кур'єр. Вам треба простежити шлях даних від вводу до збереження і відображення.
✨ Промпт:

"Ми проводимо 'FedEx Tour'. Я вводжу дані в форму реєстрації. Склади список місць (база даних, API-відповіді, лог-файли, email-підтвердження, сторінка профілю), де я маю перевірити ці дані, щоб переконатися, що вони 'доставлені' без пошкоджень."

3️⃣🦹‍♂️ Тур "Саботажник" (The Saboteur Tour) Фокус на руйнуванні. Ви намагаєтесь змусити систему впасти або зависнути.
✨ Промпт:

"Виступи в ролі зловмисника. Ми проводимо 'Тур Саботажника' для функції завантаження файлів. Запропонуй 5 способів, як спробувати заблокувати ресурси сервера, викликати timeout або змусити UI зависнути, маніпулюючи лише цим завантаженням."

Висновок: Цей метод ("метафори тестування") допомагає мозку переключитися з режиму "зомбі" в режим "дослідника". А AI допомагає не забути важливі зупинки на вашому маршруті.

А ви використовуєте тури чи евристики в роботі? Який ваш улюблений? 👇

🕸 Не тільки "Network Tab": Як AI аналізує мережевий трафік замість вас

Привіт, екіпаж!

Коли фронтенд поводиться дивно, ми всі йдемо в DevTools -> Network. Але якщо там сотні запитів, знайти проблему очима важко.

Ви знаєте, що ці логи можна зберегти як HAR-файл (HTTP Archive)? А те, що AI вміє їх читати і знаходити аномалії за секунди?

Практичний кейс: Сторінка завантажується повільно, і ви підозрюєте, що якийсь зайвий запит гальмує процес, або, можливо, десь "тече" сек'юрна інформація.

Що робимо:

1️⃣DevTools -> Network -> стрілочка вниз "Export HAR".

2️⃣Відкриваємо файл в текстовому редакторі, копіюємо фрагмент (або весь, якщо влізає в контекст) і несемо в AI.

✨ Готовий промпт "Network Detective":

Виступи в ролі Performance Engineer та Security QA.

Я надаю тобі фрагмент HAR-файлу (мережеві логи браузера) у форматі JSON.

**Завдання:**
1.  **Performance:** Знайди 3 запити, які зайняли найбільше часу (duration), і поясни, чому (напр., великий розмір тіла, довгий TTFB).
2.  **Security:** Перевір, чи не передаються чутливі дані (паролі, токени, PII) у URL-параметрах (query params) GET-запитів.
3.  **Errors:** Знайди будь-які запити зі статусом 4xx або 5xx.

[Вставте сюди шматок JSON з HAR-файлу]

✅ Що знаходить AI:

🔹"Запит GET /api/user?token=eyJ... передає токен авторизації прямо в URL. Це Critical Security Issue, токени мають бути в хедерах!"

🔹"Запит на завантаження картинки logo.png важить 5МБ і триває 3 секунди. Рекомендація: стиснути зображення."

🔹"Прихована помилка 404 на запит analytics.js, яка не відображається в UI, але засмічує консоль."

Висновок: Це перетворює вас на "рентгенолога" вашого додатку. Ви бачите не просто інтерфейс, а кровоносну систему сайту і знаходите тромби, про які розробники могли й не знати.

А ви зберігаєте HAR-файли для баг-репортів? 👇