🕸 Не тільки "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-файли для баг-репортів? 👇

🕵️ "Промислове шпигунство" для QA: Як покращити свій продукт, аналізуючи помилки конкурентів

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

Розумний вчиться на своїх помилках. Мудрий — на чужих. Як QA, ми часто зациклені на своєму беклозі. А що, як подивитися, через що страждають користувачі вашого головного конкурента?

Це золоте джерело тест-кейсів! Люди в App Store / Google Play вже написали про всі найболючіші баги та незручні флоу. Але читати тисячі відгуків — це довго.

Давайте доручимо це AI.

Практичний кейс: Ви розробляєте додаток для доставки їжі. Ваш конкурент — "Glovo" (умовно).

Крок 1: Зайдіть в стор, скопіюйте 20-30 останніх негативних відгуків (1-3 зірки) про додаток конкурента. Крок 2: "Згодуйте" їх AI.

✨ Готовий промпт "Аналіз Конкурента":

Виступи в ролі Product QA Analyst.

Ось список негативних відгуків користувачів про додаток нашого прямого конкурента (сфера доставки їжі).

**Завдання:**
1.  Проаналізуй скарги і виділи 5 найчастіших **технічних проблем** (багів) та **UX-проблем**.
2.  На основі цих проблем, створи **Risk-Based Checklist** для нашого власного додатку. Що ми маємо протестувати прямо зараз, щоб не повторити їхню долю?
3.  Особливу увагу зверни на "edge cases", які викликають найбільше емоцій у користувачів.

**Відгуки:**
[...вставте скопійовані відгуки...]

✅ Що видасть AI (Приклад):

1️⃣Зона ризику №1: Скасування замовлення.

🔹Проблема конкурента: Гроші списуються, навіть якщо замовлення скасував ресторан. Повернення триває 5 днів.

🔹Наш Тест: Перевірити сценарій скасування з боку ресторану при оплаті картою. Перевірити статус транзакції.

2️⃣Зона ризику №2: Геолокація.

🔹Проблема конкурента: Кур'єр бачить іншу точку на карті, ніж вказав клієнт.

🔹Наш Тест: Перевірити передачу координат при ручному виборі точки vs автоматичному визначенні.

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

А ви заглядаєте в город до конкурентів? 👇

👀 У AI з'явилися "очі": Як тестувати UI, просто скинувши скріншот

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

Ми звикли писати промпти текстом. Але QA — це часто робота очима. "Тут кнопка з'їхала", "тут контраст поганий", "тут текст не читається".

Раніше, щоб автоматизувати це, потрібні були дорогі інструменти візуальної регресії. Сьогодні ваш Co-pilot (ChatGPT-4o, Gemini, Claude) може зробити візуальний аудит за секунди.

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

Що робимо:

1️⃣Робимо скріншот екрану (або макета у Figma).

2️⃣Завантажуємо його в чат з AI.

✨ Готовий промпт "UI-інспектор":|

(Прикріпіть скріншот)

Виступи в ролі суворого UI/UX Дизайнера та QA. Проведи візуальний аудит цього екрану мобільного додатку.

**Зверни увагу на:**
1.  **Вирівнювання (Alignment):** Чи є елементи, які "пляшуть" і не вирівняні по сітці?
2.  **Типографіку:** Чи читабельний текст? Чи достатній контраст (згідно WCAG)?
3.  **Відступи (Padding/Margin):** Чи не виглядають елементи занадто скупченими або розкиданими?
4.  **Consistency:** Чи не виглядає якась кнопка "чужою" за стилем?

Дай список із 3-5 конкретних візуальних багів або покращень.

✅ Що знаходить AI: Він дивовижно точний!

🔹"Кнопка 'Скасувати' має менший відступ знизу, ніж кнопка 'Зберегти'."

🔹"Сірий текст на білому фоні має занизький контраст, це проблема доступності."

🔹"Іконка 'Налаштування' не вирівняна по центру з текстом заголовка."

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

А ви вже пробували показувати AI картинки? Як результати? 👇

🛠 Кнопка "Зробити магію": Створюємо власні інструменти тестування за 1 хвилину

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

Ми звикли качати розширення для Chrome: одне для перевірки посилань, інше для очищення кешу, третє для заповнення форм. А що, як я скажу вам, що ви можете створити власний інструмент під конкретну задачу за хвилину, не будучи програмістом?

Це називається Bookmarklet (Букмарклет) — шматок JavaScript-коду, збережений як звичайна закладка в браузері.

Давайте створимо "рентген", який миттєво покаже всі картинки без опису (alt), що є грубою помилкою доступності та SEO.

Практичний кейс:

1️⃣Відкриваємо AI.

2️⃣Пишемо промпт.

✨ Промпт "Tool Maker":

Виступи в ролі JavaScript-розробника.

Напиши мені код для **Bookmarklet** (скрипт, що починається з `javascript:`), який робить наступне на будь-якій відкритій сторінці:
1. Знаходить усі зображення (`img`), у яких немає атрибута `alt` або він порожній.
2. Обводить ці зображення товстою червоною рамкою (5px solid red).
3. Виводить повідомлення (alert) з кількістю знайдених помилок.

Код має бути в один рядок (minified), готовий для вставки в закладку.

✅ Результат від AI (копіюйте це):

javascript:(function(){var imgs=document.querySelectorAll('img:not([alt]),img[alt=""]');imgs.forEach(img=>img.style.border='5px solid red');alert('Знайдено зображень без Alt: '+imgs.length);})();

Як це встановити:

1️⃣У Chrome натисніть правою кнопкою на панель закладок -> "Додати сторінку".

2️⃣Ім'я: 🔴 Find No-Alt

3️⃣URL: вставте код, який дав AI.

4️⃣Зберегти.

Як це працює: Зайдіть на будь-який сайт. Натисніть на цю закладку. Бум! Усі проблемні картинки обведені червоним.

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

🔹"Заповнити всі поля форми тестовими даними".

🔹"Підсвітити всі посилання, які ведуть на http замість https".

🔹"Показати приховані паролі".

Ви більше не залежите від чужих плагінів. Ви створюєте свої.

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

🎯 "Я змінив тільки один рядок": Як AI допомагає робити Impact Analysis і не поламати прод

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

Класика: розробник каже "фікс дрібний, не бійся", ви робите швидкий смоук, а на проді відвалюється половина функціоналу. Чому? Бо "дрібний фікс" зачепив спільну бібліотеку.

Робити повну регресію на кожен чмих — немає часу. Не робити — страшно. Рішення: Impact Analysis (Аналіз впливу).

Замість того, щоб гадати, що зачепило зміни, запитайте у Co-pilot'а. Він чудово будує логічні зв'язки.

Практичний кейс: Розробник змінив логіку валідації номера телефону в модулі реєстрації.

✨ Готовий промпт "Детектор зв'язків":

Виступи в ролі Software Architect.

**Зміна:** Розробники оновили бібліотеку валідації телефонних номерів у модулі "Реєстрація".

**Архітектура системи:**
1. Реєстрація/Логін.
2. Особистий кабінет (редагування профілю).
3. Оформлення замовлення (ввід контактів).
4. Відновлення пароля через SMS.
5. Адмін-панель (пошук користувачів).

**Завдання:**
Проведи Impact Analysis. Назви 4 неочевидні місця в системі (крім самої реєстрації), які могли зламатися через цю зміну і які я обов'язково маю перевірити. Поясни ризик для кожного пункту.

✅ Що підсвітить AI:

Зона ризику 1️⃣: Оформлення замовлення.
🔹Ризик: Якщо там використовується та сама функція валідації, клієнти не зможуть купити товар.

Зона ризику 2️⃣: Відновлення пароля.
🔹Ризик: Якщо формат номера в базі змінився або валідація стала суворішою, старі користувачі не зможуть отримати SMS.

Зона ризику 3️⃣: Імпорт існуючих користувачів (Міграція).
🔹Ризик: Чи відповідають старі номери в базі новим правилам валідації?

Зона ризику 4️⃣: API інтеграції (напр., CRM).
🔹Ризик: Якщо ми передаємо телефон у зовнішню систему, чи не змінився формат даних?

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

А ви вірите розробникам на слово, коли вони кажуть "там нічого не зачепило"? 😉 👇

💾 SQL-магія: Як перевіряти Базу Даних рівня Senior, знаючи лише "SELECT"

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

Інтерфейс може брехати. API може кешувати старі дані. І тільки База Даних (БД) завжди каже правду. Але щоб дізнатися цю правду, часто треба зв'язати три таблиці, відфільтрувати за датою і згрупувати за статусом. 🤯

Якщо написання JOIN викликає у вас головний біль — делегуйте це AI. Ви описуєте задачу словами — він пише ідеальний SQL.

Практичний кейс: Нам треба знайти користувачів, які зареєструвалися минулого тижня, зробили замовлення, але платіж так і не пройшов (status = 'failed').

Це задача на три таблиці: Users, Orders, Payments.

✨ Готовий промпт "SQL-Гуру":

Виступи в ролі Database Administrator (PostgreSQL).

У мене є така структура бази даних (схема):
1. **Users** (`id`, `email`, `created_at`)
2. **Orders** (`id`, `user_id`, `amount`, `order_date`)
3. **Payments** (`id`, `order_id`, `status` ['success', 'failed'])

**Завдання:**
Напиши мені SQL-запит, який знайде email-адреси користувачів, які:
1. Зареєструвалися за останні 7 днів.
2. Мають хоча б одне замовлення.
3. Але у цього замовлення статус платежу 'failed'.

Поясни, який тип JOIN ти використав і чому.

✅ Результат від AI:

SELECT u.email, o.id as order_id, p.status
FROM Users u
JOIN Orders o ON u.id = o.user_id
JOIN Payments p ON o.id = p.order_id
WHERE u.created_at >= NOW() - INTERVAL '7 days'
  AND p.status = 'failed';

Що ви отримали:

1️⃣Готовий робочий запит.

2️⃣Розуміння логіки (AI пояснить, що JOIN з'єднує таблиці за спільними ID).

Висновок: Вам не треба бути експертом з SQL, щоб робити глибокі перевірки даних. Використовуйте AI як "перекладача" з людської мови на мову баз даних. Це супер-сила на будь-якій співбесіді і в роботі.

А ви пишете складні запити самі чи просите розробників? 👇

🔮 QA 2026: Кінець епохи "Клікателів"? Мій прогноз на майбутній рік

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

На календарі грудень 2025-го. Ми стоїмо на порозі нового року, і я відчуваю, що 2026 стане переломним. Якщо у 2024-25 ми просто "гралися" з AI-помічниками, то наступного року правила гри зміняться кардинально.

Ось мій прогноз на QA-тренди 2026 року:

1️⃣Від Copilot до Autopilot (Agentic Testing) 🤖 Ми перестанемо писати кожен крок у коді автотестів.

🔹Зараз: Ми пишемо: driver.findElement(By.id("login")).click().

🔹У 2026: Ми даватимемо задачу AI-агенту: "Протестуй флоу покупки для нового юзера" — і агент сам визначить локатори, сам згенерує дані і сам пройде сценарій. 👉 Скіл: Вміння налаштовувати та контролювати AI-агентів.

2️⃣"Prompt Engineering" стає частиною QA 🗣 Кожен другий додаток тепер має вбудований LLM (чат-боти, генератори). Тестувати їх класичними методами ("очікуваний результат = фактичний") неможливо, бо вони кожен раз відповідають по-різному. 👉 Скіл: LLM Red Teaming (вміння змусити модель галюцинувати або видати токсичний контент) стане окремою професією.

3️⃣Смерть "Документації заради Документації" 📄 Писати довгі тест-плани вручну стане моветоном. Відео-запис екрану + голосовий коментар тестувальника будуть миттєво перетворюватися AI на баг-репорт, документацію та тест-кейс одночасно. 👉 Тренд: Більше часу на дослідження, менше — на оформлення папірців.

4️⃣Observability замість Regression 📊 Швидкість релізів така, що проганяти повну регресію перед кожним деплоєм — це розкіш. Фокус зміщується на Testing in Production. Головне питання не "чи є баги?", а "як швидко ми їх знайдемо на проді і відкотимося?". 👉 Скіл: Робота з Datadog, Grafana, Sentry, аналіз логів.

5️⃣QA перетворюється на QE (Quality Engineering) ⚙️ Кордон між SDET і Manual стирається остаточно. "Мануальщик", який не вміє запустити скрипт чи проаналізувати JSON, залишиться без роботи. Всі стають інженерами, озброєними AI-інструментами.

Висновок: QA не помирає, він еволюціонує. Ми переходимо від ролі "тих, хто шукає помилки" до ролі "архітекторів якості", які керують армією ботів.

А які ваші ставки на 2026? Що помре, а що злетить? 👇

🔥 Як "покласти" власний сервер: Навантажувальне тестування для тих, хто боїться JMeter

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

Ми всі вміємо перевіряти, чи працює логін для одного користувача. А що станеться, якщо 1000 користувачів натиснуть "Увійти" одночасно в "Чорну п'ятницю"? 🤔

Зазвичай мануальні QA кажуть: "Ну, це робота перформанс-інженерів". Але бути тим, хто може сказати: "Хлопці, наш API вмирає при 50 запитах на секунду, я перевірив" — це зовсім інший рівень авторитету.

Вам не треба вчити монструозний JMeter. Використовуйте K6. Це сучасний інструмент, де тести — це просто JS-код. А код за вас напише AI.

Практичний кейс: Треба перевірити API-ендпоінт POST /api/login. Ми хочемо зімітувати 50 користувачів, які логіняться одночасно протягом 30 секунд.

✨ Готовий промпт "DDOS-атака на мінімалках":

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

Мені потрібен скрипт для навантажувального тестування інструментом **K6 (k6.io)**.

**Сценарій:**
1. Ендпоінт: `POST https://my-test-api.com/login`
2. Тіло запиту (JSON): `{ "email": "test@test.com", "password": "123" }`
3. Перевірка (Check): Статус відповіді має бути 200.

**Навантаження (Load Config):**
- Кількість віртуальних користувачів (VUs): 50
- Тривалість тесту: 30 секунд.

Напиши готовий JS-скрипт і поясни, як його запустити.

✅ Результат від AI (готовий файл script.js):

import http from 'k6/http';
import { check, sleep } from 'k6';

export let options = {
  vus: 50, // 50 юзерів
  duration: '30s', // протягом 30 секунд
};

export default function () {
  let url = 'https://my-test-api.com/login';
  let payload = JSON.stringify({
    email: 'test@test.com',
    password: '123',
  });

  let params = {
    headers: { 'Content-Type': 'application/json' },
  };

  let res = http.post(url, payload, params);

  // Перевіряємо, чи сервер вижив (200 OK)
  check(res, {
    'is status 200': (r) => r.status === 200,
  });

  sleep(1);
}

Як це використати?

1️⃣Встановіть K6 (одна команда в терміналі).

2️⃣Запустіть: k6 run script.js.

3️⃣Дивіться в консоль: якщо ви побачите купу червоних хрестиків і час відповіді 5000ms — вітаю, ви знайшли "вузьке місце" (bottleneck)!

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

А ви коли-небудь проводили навантажувальне тестування? Чи вірите, що "сервер витримає"? 👇

🔎 Ти — бог Jira: Як знаходити будь-які тікети без мук з фільтрами

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

Jira — це монстр. Знайти там потрібний тікет іноді важче, ніж знайти сам баг у коді. Звичайні фільтри ("My Open Issues") дуже обмежені. А щоб робити круті вибірки, треба знати JQL (Jira Query Language).

Хто з вас пам'ятає, як написати: "Покажи всі баги, де статус змінювався на 'Reopened' за останній тиждень"? Я теж не пам'ятаю. І не треба.

Делегуйте написання запитів AI, щоб створювати потужні дешборди та звіти.

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

✨ Готовий промпт "Jira-хакер":

Виступи в ролі Jira Administrator.
Напиши мені **JQL-запит** (Jira Query Language) для фільтрації задач.

**Критерії пошуку:**
1. Тип задачі: Bug.
2. Пріоритет: High або Critical.
3. Статус: НЕ "Done" і НЕ "Closed" (тобто відкриті).
4. Виконавець (Assignee): Unassigned (порожньо).
5. Дата створення: Більше ніж 14 днів тому.

Напиши тільки сам код запиту.

✅ Результат від AI:

issuetype = Bug AND priority in (High, Critical) AND status not in (Done, Closed) AND assignee is EMPTY AND created < -14d

Як це використати?

1️⃣В Jira натисніть Filters -> Advanced Issue Search.

2️⃣Переключіться на режим JQL (справа кнопочка "Switch to JQL").

3️⃣Вставте цей рядок.

4️⃣Готово! Ви бачите список "проблемних" задач, про які всі забули.

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

А ви користуєтесь Advanced Search в Jira? 👇

🎭 Бекенд ще не готовий? Не біда! Піднімаємо Mock-сервер за хвилину

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

Класична ситуація: — "Ти протестував нову форму реєстрації?" — "Ні, чекаю на бекенд, API ще не працює". 😴

Стоп. Це позиція жертви обставин. Професійний QA може протестувати фронтенд, навіть якщо бекенду взагалі не існує. Для цього ми використовуємо Моки (Mocks).

Раніше треба було ставити складні тули типу WireMock. Сьогодні ваш Co-pilot напише вам "фейковий сервер" на Python за 30 секунд.

Практичний кейс: Вам треба, щоб за адресою http://localhost:5000/api/user повертався JSON з даними юзера.

✨ Готовий промпт "Fake Backend":

Виступи в ролі Python-розробника.

Мені потрібен простий **Mock-сервер** на бібліотеці **Flask**.
Він має слухати порт 5000 і мати один ендпоінт:
`GET /api/user`

**Логіка:**
1. Якщо я передаю в хедері `Authorization: valid_token` — повертай 200 OK і JSON:
   `{"id": 1, "name": "QA Ninja", "role": "admin"}`
2. Якщо токена немає або він інший — повертай 401 Unauthorized.

Напиши повний код скрипта, який я можу запустити одною командою.

✅ Результат від AI (код server.py):

from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route('/api/user', methods=['GET'])
def get_user():
    token = request.headers.get('Authorization')
    if token == 'valid_token':
        return jsonify({"id": 1, "name": "QA Ninja", "role": "admin"}), 200
    else:
        return jsonify({"error": "Unauthorized"}), 401

if __name__ == '__main__':
    app.run(port=5000)

Як це використати?

1️⃣Встановіть Flask (pip install flask).

2️⃣Запустіть файл (python server.py).

3️⃣Вкажіть своєму фронтенду (або в Postman) стукати на localhost:5000.

Висновок: Ви можете симулювати будь-які помилки (500, 503), затримки мережі та дивні дані, не чекаючи, поки бекенд-розробник звільниться. Ви самі керуєте реальністю.

А ви використовуєте моки чи чекаєте на справжнє API? 👇

⏳ Машина часу для QA: Як протестувати "Новий Рік" посеред літа

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

Уявіть задачу: розробник зробив акцію "Чорна п'ятниця", яка активується автоматично 29 листопада. Надворі — грудень (або липень). Як перевірити, що банер зникне, коли акція закінчиться?

❌ Поганий спосіб: Просити адмінів перевести годинник на сервері (це покладе базу даних і токени).

❌ Довгий спосіб: Чекати реальної дати.

✅ Спосіб "QA Co-pilot": Підмінити час тільки у вашому браузері за допомогою простого скрипта.

Браузер бере час з вашої системи. Але ми можемо "обдурити" сайт, перевизначивши об'єкт Date. Писати цей код вручну складно, але AI робить це за секунду.

Практичний кейс: Я хочу, щоб сайт думав, що зараз 1 січня 2026 року, 00:00:01.

✨ Готовий промпт "Time Traveler":

Виступи в ролі JavaScript Expert.

Напиши мені сніпет коду (script), який я можу вставити в консоль браузера (DevTools).
**Завдання:**
Перевизначити глобальний об'єкт `Date` так, щоб для сайту поточний час завжди був: **2026-01-01 00:00:01**.
При цьому скрипт має зберігати працездатність методів `Date` (щоб сайт не впав).

✅ Результат від AI (копіюємо і вставляємо в Console):

(function() {
    var originalDate = Date;
    var mockDate = new originalDate('2026-01-01T00:00:01');

    Date = function(dt) {
        if (dt) return new originalDate(dt);
        return new originalDate(mockDate);
    };
    Date.now = function() { return mockDate.getTime(); };
    Date.prototype = originalDate.prototype;
    Date.parse = originalDate.parse;
    Date.UTC = originalDate.UTC;
    
    console.log("⏰ Час успішно підмінено на: " + mockDate);
})();

Як це працює:

1️⃣Відкриваєте сайт.

2️⃣Тиснете F12 -> Console.

3️⃣Вставляєте код -> Enter.

4️⃣Оновлюєте контент на сторінці (без перезавантаження всієї сторінки, якщо це SPA) або натискаєте на кнопки. Сайт "думає", що вже майбутнє.

Висновок: Ви можете перевіряти прострочені сесії, майбутні акції та таймери зворотного відліку, не чіпаючи налаштування Windows/macOS. Ви керуєте часом!

А вам доводилося тестувати логіку, залежну від часу? Як викручувались? 👇

🔗 "Copy XPath" — це зло. Генеруємо "безсмертні" локатори з AI

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

Ви вирішили написати свій перший автотест (або просто шукаєте елемент у консолі). Ви тиснете Copy selector у Chrome і отримуєте: #app > div:nth-child(2) > main > div.container > form > button

Це працює... до першого оновлення сайту. Як тільки розробник загорне кнопку в ще один div — ваш локатор зламається, а тест впаде.

Професіонали пишуть локатори, прив'язані до суті елемента, а не до його місця. Але вигадувати складні XPath/CSS буває ліньки.

Нехай це робить ваш Co-pilot.

Практичний кейс: У нас є кнопка "Купити", яка захована глибоко в DOM-дереві.

✨ Готовий промпт "Selector Architect":

Виступи в ролі Automation QA Engineer.

Ось HTML-код кнопки:
`<button class="btn btn-primary btn-lg" id="x-123-random" onclick="...">Buy Now</button>`

**Завдання:**
Напиши мені 3 варіанти **надійних (robust)** локаторів для цього елемента (CSS або XPath), які НЕ зламаються, якщо зміниться верстка навколо або динамічний ID.

Поясни, чому твої варіанти кращі за автозгенеровані.

✅ Що видасть AI:

Варіант 1️⃣ (За текстом - XPath):
//button[contains(text(), 'Buy Now')] Чому краще: Працює, де б кнопка не знаходилась, доки на ній написано "Buy Now".

Варіант 2️⃣ (За атрибутами - CSS): button[class*='btn-primary'] Чому краще: Ігнорує динамічний ID (x-123-random), фокусується на стилі.

Варіант 3️⃣ (Комбінований - XPath):
//button[normalize-space()='Buy Now' and not(@disabled)] Чому краще: Знаходить тільки активну кнопку.

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

А ви пишете локатори самі чи довіряєте Chrome DevTools? 👇

🕸 GraphQL без сліз: Як писати складні запити, не знаючи синтаксису

Ви звикли до REST API: хочеш юзера — йдеш на
/users/1, хочеш його замовлення — йдеш на
/users/1/orders. Все просто.

Але приходить розробник і каже: "Ми переїхали на GraphQL. Тепер у нас тільки один URL, а дані проси через Query". 🤯 Ви відкриваєте Postman, бачите пусте поле Body і не знаєте, що туди писати. { user { id } }? Чи query { getUser }?

GraphQL дозволяє забрати всі потрібні дані одним запитом (і юзера, і його кота, і історію покупок). Але написати цей "багатоповерховий" запит без помилок — важко.

Тут в гру вступає AI.

Практичний кейс: Вам треба отримати ім'я користувача, його імейл та список із останніх 5 замовлень (тільки ID та суму) для юзера з ID 123.

✨ Готовий промпт "GraphQL Builder":

Виступи в ролі Backend Developer.
Мені потрібно написати **GraphQL Query**.

**Моя мета:**
Отримати дані для користувача з `id: "123"`.
Поля, які мені потрібні:
1. З об'єкта User: `firstName`, `email`.
2. З вкладеного об'єкта Orders (мені потрібні тільки останні 5 штук): `id`, `totalAmount`, `status`.

Напиши правильний синтаксис запиту.

✅ Результат від AI:

query {
  user(id: "123") {
    firstName
    email
    orders(limit: 5) {
      id
      totalAmount
      status
    }
  }
}

Що з цим робити?

1️⃣В Postman вибираєте тип GraphQL.

2️⃣Вставляєте цей код у поле Query.

3️⃣Тиснете Send.

4️⃣Отримуєте ідеальний JSON саме з тими даними, які просили. Жодних зайвих полів!

Бонус: Якщо запит не працює, скопіюйте помилку (Field 'orders' doesn't exist on type 'User') в AI, і він скаже: "А, точно, у вашій схемі це поле називається userOrders, спробуй так...".

Висновок: GraphQL — це потужно, бо ви самі вирішуєте, що поверне сервер. З AI ви стаєте архітектором своїх даних за секунди.

А у вас на проєкті REST чи GraphQL? 👇