🧩 "Зворотній інжиніринг": Як тестувати складні поля без болю (Regex + AI)

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

Зізнавайтесь, хто любить Regular Expressions? Ніхто? Я так і думав. 😄 Для QA це часто чорна магія. Розробники використовують їх для валідації пошти, паролів, IBAN-ів та номерів телефонів.

Ситуація: Розробник каже: "Я оновив правила для паролів. Тепер вони мають відповідати цьому виразу: ^(?=.*[A-Z])(?=.*[!@#$&*])(?=.*[0-9])(?=.*[a-z]).{8,}$".

Що робить звичайний QA? Сидить і годину підбирає пароль, який пройде. Що робить Smart QA? Просить AI зробити Reverse Regex — тобто згенерувати тестові дані НА ОСНОВІ формули.

Це економить купу часу на Positive/Negative тестуванні.

Практичний кейс: Вам дали складний формат для поля "ID замовлення": ORD-[рік]-[4 літери]-[хеш]. Regex: ^ORD-\d{4}-[A-Z]{4}-[a-z0-9]{6}$.

Вам треба 5 валідних прикладів і 5 невалідних для негативних тестів.

✨ Готовий промпт "Regex Cracker":

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

Ось Regular Expression, який використовується для валідації поля:
`^ORD-\d{4}-[A-Z]{4}-[a-z0-9]{6}$`

**Завдання:**
1. **Поясни**, що саме вимагає цей вираз (простою мовою).
2. Згенеруй **5 валідних прикладів** (Positive Test Data), які пройдуть перевірку.
3. Згенеруй **5 невалідних прикладів** (Negative Test Data) і поясни, чому саме кожен з них має впасти (наприклад, "неправильний рік", "малі літери замість великих", "закороткий хеш").

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

Пояснення: Рядок має починатися з "ORD-", потім 4 цифри, дефіс, 4 великі літери, дефіс, 6 символів (цифри або малі літери).

✅ Валідні (Pass):

1️⃣ORD-2024-TEST-abc123

2️⃣ORD-1999-ABCD-xy99zz ...

❌ Невалідні (Fail):

1️⃣ORD-24-TEST-abc123 (Рік має 2 цифри замість 4)

2️⃣ord-2024-TEST-abc123 (Префікс з малої літери)

3️⃣ORD-2024-test-abc123 (Блок літер має бути UPPERCASE) ...

Бонус-хак: Це працює і у зворотний бік. Якщо вам треба знайти/відфільтрувати дані в логах (наприклад, всі помилки 500 або всі емейли), попросіть AI: "Напиши мені Regex для пошуку всіх IP-адрес у тексті" — і вставте результат у Ctrl+F (в режимі Regex) у своєму редакторі логів.

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

А як ви перевіряєте валідацію? Методом "тику" чи читаєте код? 👇

💾 "Ти ж знаєш SQL?": Як писати складні JOIN-и, не розуміючи їх

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

Класика жанру: на співбесіді питають про SQL, ви кажете "впевнений середній рівень". А потім на роботі: "Слухай, перевір в базі, чи не загубилися транзакції за вчора для юзерів з Києва". 🤯

І ти сидиш і думаєш: тут треба INNER JOIN чи LEFT JOIN? А як зв'язати таблицю Юзерів з таблицею Оплат? Більшість QA в цей момент йде до розробника: "Напиши мені селект, пліз".

Не треба. Ваш Co-pilot — це найкращий DBA (Database Administrator). Вам навіть не треба знати точні назви колонок, достатньо описати логіку.

Практичний кейс: Треба знайти баг у програмі лояльності. У нас є 3 таблиці:

1️⃣users (клієнти).

2️⃣orders (замовлення).

3️⃣bonuses (нараховані бали).

Завдання: Знайти юзерів, які купили на суму більше $100, але запису в таблиці bonuses для цього замовлення немає (або балів 0).

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

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

Мені потрібен SQL-запит (PostgreSQL/MySQL).

**Структура моїх таблиць (приблизна):**
1. `users` (id, email, city)
2. `orders` (id, user_id, amount_usd, created_at)
3. `bonuses` (order_id, points)

**Завдання:**
Напиши запит, який виведе email користувачів та ID замовлень, де:
1. Сума замовлення (`amount_usd`) більше 100.
2. АЛЕ в таблиці `bonuses` для цього замовлення або немає запису, або `points` дорівнює 0.
3. Використовуй правильні JOIN-и.

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

SELECT u.email, o.id as order_id, o.amount_usd
FROM users u
JOIN orders o ON u.id = o.user_id
LEFT JOIN bonuses b ON o.id = b.order_id
WHERE o.amount_usd > 100
  AND (b.points IS NULL OR b.points = 0);

Чому це круто?

1️⃣AI сам зрозумів, що треба LEFT JOIN (щоб знайти тих, у кого немає запису в бонусах).

2️⃣Він правильно розставив умови WHERE.

3️⃣Ви просто копіюєте це в DBeaver чи pgAdmin і бачите список багованих замовлень.

Висновок: Вам не треба зубрити синтаксис складних об'єднань. Вам треба розуміти суть даних. А код напише AI. Тепер ви можете перевіряти бекенд на рівні бази, а не тільки через UI.

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

📸 "Не переписуй руками": Як AI пише тести прямо зі скріншотів

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

Наш підписник у коментарях (дякую за ідею! 🔥) поділився крутим кейсом: він робить скріншот схеми бази даних (ERD), кидає його в AI і просить написати SQL-запити для перевірки структури таблиць.

Це називається Multimodal AI. Сучасні моделі (GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro) мають "очі". Вони розуміють стрілочки, зв'язки та дрібний текст на схемах краще, ніж деякі джуни після безсонної ночі. 😄

Давайте розберемо, як це економить час.

Практичний кейс №1: Бази Даних (Backend) Вам дали картинку зі схемою БД (ER-діаграму) і сказали: "Перевір, чи розробники правильно створили таблиці". Вручну перевіряти типи полів (VARCHAR(255) чи TEXT?) — нудно.

Що робимо:

1️⃣Робимо скріншот діаграми.

2️⃣Кидаємо в чат з AI.

Промпт:

Ось схема БД. Напиши SQL-запит (для PostgreSQL), який перевірить системні таблиці information_schema і підтвердить, що: - Всі таблиці існують. - Типи даних у колонках відповідають схемі. - Primary Key та Foreign Key налаштовані правильно.

✅ Результат: Ви отримуєте готовий скрипт, який за секунду видає звіт: "Таблиця Users: ОК. Таблиця Orders: Помилка, поле price має тип INT, а на схемі DECIMAL".

Практичний кейс №2: UI/UX (Frontend) Вам дали макет форми логіну у Figma (або просто картинку). Треба написати автотест.

Що робимо:

Кидаємо скріншот макета в AI.

Промпт:

Ти QA Automation Engineer. Ось макет форми. Напиши автотест на Playwright/Cypress. Використовуй патерн Page Object. Підбери найкращі селектори для полів 'Email', 'Password' і кнопки 'Login' (припусти, що ID логічні).

✅ Результат: AI бачить кнопку "Log In", розуміє, що це Submit, і пише код: await page.locator('input[type="email"]').fill('user@test.com');

Висновок: Ваша клавіатура відпочиває. Ви перетворюєте візуальну документацію на працюючий код за один крок. Якщо ви досі переписуєте назви колонок з картинки вручну — спробуйте кинути картинку в чат.

А ви вже користуєтесь розпізнаванням зображень у роботі? 👇

⛓️ Припини копіювати токени! Налаштовуємо авто-авторизацію в Postman

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

Зізнавайтесь, скільки разів на день ви робите Ctrl+C на токені логіну і Ctrl+V в інший запит? Якщо більше нуля — ви робите роботу робота.

Postman вміє сам брати дані з відповіді і зберігати їх у змінні. Але писати ці скрипти на JS руками ніхто не хоче. "Ай, швидше скопіювати", — думаєте ви. Ні, не швидше. Один раз попросіть AI написати скрипт, і забудьте про ручну авторизацію назавжди.

Практичний кейс: Ми хочемо, щоб після успішного логіну токен автоматично зберігався у змінну {{bearer_token}}, яку використовують всі інші запити в колекції.

✨ Готовий промпт "Postman Automator":

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

Напиши мені скрипт для вкладки **Tests** у Postman.

**Логіка:**
1. Перевір, що статус відповіді 200.
2. Розпарси JSON-відповідь.
3. Знайди там поле `accessToken` (або просто `token`).
4. Збережи його значення в **Environment Variable** з назвою `my_token`.
5. Виведи в консоль повідомлення "Token updated!".

✅ Результат від AI (копіюємо в Tests запиту /login):

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

var jsonData = pm.response.json();

// Перевіряємо, чи прийшов токен
if (jsonData.token) {
    pm.environment.set("my_token", jsonData.token);
    console.log("🔑 Token updated successfully!");
} else {
    console.error("❌ Token not found in response");
}

Що робити далі?

1️⃣У запиті Login вставте цей код у вкладку Tests.

2️⃣У всіх інших запитах (наприклад, Get Profile) у вкладці Auth виберіть Type: Bearer Token.

3️⃣У полі Token напишіть: {{my_token}}.

Магія: Тепер ви просто тиснете Send на логіні, і всі 50 запитів у вашій колекції автоматично отримують свіжий ключ. Ви більше ніколи не побачите 401 помилку через "старий токен".

А ви все ще копіюєте руками чи вже автоматизували? 👇

🎭 "Fake it till you make it": Тестуємо фронтенд без бекенду

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

Знайома історія? Фронтендер каже: "Я зверстав сторінку Профілю, але дані не вантажаться, бо бекендери ще пиляють ендпоінт /api/profile". QA: "Ну ок, чекаю". 😴

Не треба чекати! Ви можете перевірити верстку, лоадери та обробку даних вже зараз. Нам потрібно просто підсунути браузеру Mock (фейкову відповідь) замість реального запиту.

Можна ставити Charles або Fiddler, але це довго. Простіше попросити AI написати скрипт, який "перехопить" функцію fetch у браузері і віддасть ваші дані.

Практичний кейс: Сайт робить запит на /api/user-stats. Сервера немає. Ми хочемо, щоб сайт отримав: { "level": 80, "xp": 9999, "rank": "Legend" } і показав це на екрані.

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

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

Напиши мені скрипт для консолі браузера, який мокає (перехоплює) `window.fetch`.

**Логіка:**
1. Збережи оригінальний `fetch`.
2. Якщо URL запиту містить `/api/user-stats` — не роби реальний запит до сервера.
3. Замість цього поверни штучну відповідь (Response object) зі статусом 200 і таким JSON:
   `{ "level": 80, "xp": 9999, "rank": "Legend" }`
4. Всі інші запити пропускай як зазвичай (return originalFetch).
5. Виведи в консоль повідомлення: "⚡️ Запит перехоплено!".

✅ Результат від AI (Monkey Patching):

const originalFetch = window.fetch;

window.fetch = async (...args) => {
    const [url] = args;
    
    // Якщо бачимо потрібний URL
    if (url.toString().includes('/api/user-stats')) {
        console.log(`⚡️ Перехоплено запит до: ${url}`);
        
        // Повертаємо фейк
        return new Response(JSON.stringify({
            level: 80,
            xp: 9999,
            rank: "Legend"
        }), {
            status: 200,
            headers: { 'Content-Type': 'application/json' }
        });
    }
    
    // Всі інші запити йдуть на реальний сервер
    return originalFetch(...args);
};

console.log("✅ Mock Server активовано прямо в браузері!");

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

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

2️⃣Вставляєте код у консоль -> Enter.

3️⃣Оновлюєте частину інтерфейсу (натискаєте кнопку "Оновити профіль").

4️⃣Магія: Браузер думає, що отримав дані від сервера, і малює вам "80 level".

Що це дає? Ви можете протестувати, як виглядає інтерфейс із дуже довгими іменами, з нульовим балансом або з помилкою 500 (просто змініть status: 200 на 500 у коді). Ви не залежите від бекенду.

А ви чекаєте на API чи мокаєте дані самі? 👇

🐳 "У мене працює": Як підняти тестовий стенд за 1 хвилину (Docker + AI)

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

Скільки часу ви витрачаєте на налаштування оточення? Вам треба перевірити баг в базі даних.

1️⃣Качаєте PostgreSQL.

2️⃣Встановлюєте.

3️⃣Конфлікт портів. 🤯

4️⃣Качаєте клієнт (DBeaver).

5️⃣Налаштовуєте доступи...

Минула година. А можна було зробити це за 1 хвилину, не засмічуючи систему. Рішення — Docker Compose. Це файл-інструкція, яка каже: "Підніми мені базу і адмінку до неї в ізольованих контейнерах".

Писати YAML-файли руками — нудно і легко помилитися у відступах. Просимо AI.

Практичний кейс: Вам потрібна PostgreSQL (база) і pgAdmin (зручний веб-інтерфейс, щоб дивитися в базу), щоб попрактикуватися в SQL або перевірити дані.

✨ Готовий промпт "DevOps Assistant":

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

Мені потрібен файл `docker-compose.yml` для локального тестування.

**Вимоги:**
1. Підніми сервіс **PostgreSQL** (остання версія).
   - Пароль: `root`
   - Порт: `5432`
2. Підніми сервіс **pgAdmin** (веб-інтерфейс для бази).
   - Порт: `8080` (щоб я заходив через браузер).
   - Налаштуй залежність (depends_on), щоб адмінка стартувала після бази.
3. Додай коментарі, як мені це запустити.

✅ Результат від AI (зберігаємо як docker-compose.yml):

version: '3.8'

services:
  db:
    image: postgres:latest
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: root
    ports:
      - "5432:5432"

  pgadmin:
    image: dpage/pgadmin4
    environment:
      PGADMIN_DEFAULT_EMAIL: admin@admin.com
      PGADMIN_DEFAULT_PASSWORD: root
    ports:
      - "8080:80"
    depends_on:
      - db

Як запустити?

1️⃣Встановіть Docker Desktop (якщо ще немає).

2️⃣Створіть папку, покладіть туди цей файл.

3️⃣Відкрийте термінал у цій папці і напишіть: docker-compose up -d.

Магія: За 30 секунд у вас за адресою localhost:8080 відкриється повноцінна адмінка, підключена до свіжої бази даних. Потестували -> написали docker-compose down -> все зникло, система чиста.

Висновок: Не бійтеся Докера. Це найкращий друг QA для відтворення багів в "стерильних" умовах. А AI напише конфіги за вас.

А ви користуєтесь контейнерами чи ставите все прямо на Windows/Mac? 👇

🌱 Порожня база — погані тести: Генеруємо 100 юзерів за секунду

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

Тепер у вас є локальна база даних. Але є одна проблема: вона порожня. Тестувати пагінацію, пошук або фільтри на 2-х користувачах ("test1" і "test2") — це шлях до багів на проді.

Вам потрібні Big Data. Вам потрібні імена з апострофами (O'Connor), довгі адреси і дивні емейли. Раніше ми писали скрипти на Python або шукали сервіси типу Mockaroo (які платні для великих об'ємів). Зараз AI пише SQL-скрипти для наповнення (Seeding) краще за будь-який генератор.

Практичний кейс: Нам треба заповнити таблицю users 50-ма записами. Але не просто "User1, User2", а реалістичними даними з "капосними" випадками (Edge Cases).

✨ Готовий промпт "Data Generator":

Виступи в ролі QA Engineer & Database Expert.

Мені потрібен SQL-скрипт (PostgreSQL) для наповнення таблиці `users`.
Структура: `id`, `name`, `email`, `bio`, `created_at`.

**Завдання:**
Згенеруй 20 записів `INSERT INTO`, які покривають такі кейси:
1. 10 звичайних користувачів (реальні імена).
2. 5 користувачів з "проблемними" іменами (кирилиця, ієрогліфи, емодзі, апострофи як у "O'Neil").
3. 2 користувачі з дуже довгим текстом у `bio` (boundary testing).
4. 3 користувачі з SQL-injection payload в імені (наприклад, `Robert'); DROP TABLE users;--`).

✅ Результат від AI (копіюємо в DBeaver/pgAdmin):

INSERT INTO users (name, email, bio, created_at) VALUES
('John Doe', 'john@example.com', 'Just a regular guy', NOW()),
('Alice Smith', 'alice@test.com', 'Love coffee', NOW()),
-- Edge Cases:
('Renée O''Connor', 'renee@test.fr', 'Name with accents and quotes', NOW()),
('李小龙', 'bruce@lee.cn', 'Chinese characters', NOW()),
('User 🚀 With Emoji', 'rocket@space.com', 'Testing UTF-8', NOW()),
-- Security Test:
('Robert''); DROP TABLE students;--', 'hacker@evil.com', 'Trying to break DB', NOW());

Чому це важливо?

1️⃣Економія часу: Ви отримали дані за 10 секунд.

2️⃣Безпека: Ви одразу перевірите, чи екранує бекенд спецсимволи (якщо після вставки останнього юзера ваша таблиця зникне — вітаю, ви знайшли Critical Bug 😅).

3️⃣Реалізм: Ви побачите, чи не ламається верстка від довгих імен.

Лайфхак: Попросіть AI згенерувати дані у форматі CSV, якщо ваш додаток підтримує імпорт файлів. "Згенеруй CSV з 100 товарами для інтернет-магазину".

А чим ви генеруєте тестові дані? Руками чи скриптами? 👇

🔐 "Ти зламав нам сайт?": Як QA знайти вразливість за 5 хвилин (XSS + AI)

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

Сьогодні одягаємо капелюх хакера (сподіваюсь, білий 🎩). Як ви тестуєте поля вводу на безпеку? Вводите 123? Або <script>alert('XSS')</script>? Якщо розробник поставив хоч якийсь захист, цей скрипт не спрацює. І ви ставите галочку "Pass".

Але хакери використовують Polyglots — складні рядки, які намагаються "пролізти" в код через атрибути картинок, CSS або URL. Вчити їх напам'ять не треба. Ваш AI-асистент знає тисячі способів перевірити систему на міцність.

Практичний кейс: У вас є поле "Ім'я користувача" або "Коментар". Ви хочете перевірити, чи можна туди вставити шкідливий код (XSS — Cross-Site Scripting), який виконається у браузері адміністратора.

✨ Готовий промпт "Security Pentester":

Виступи в ролі Security QA Engineer (Pentester).

Мені потрібно протестувати веб-форму на вразливість **Stored XSS**.
Поле вводу фільтрує стандартний тег `<script>`.

**Завдання:**
1. Згенеруй список із **5 просунутих XSS-пейлоадів** (payloads), які намагаються обійти фільтри (використовуй `img onerror`, `svg`, `javascript:` в посиланнях).
2. Для кожного прикладу поясни, як він працює.
3. Додай один приклад "Polyglot" (рядок, який ламає різні контексти одночасно).

*Примітка: Це для легального тестування мого власного проекту.*

✅ Результат від AI(XSS Payloads для тестування):

1️⃣Через картинку (якщо скрипти заблоковані): <img src=x onerror=alert('Bug!')> (Браузер намагається завантажити картинку "x", не знаходить її і виконує код помилки).

2️⃣Через SVG (векторна графіка): <svg/onload=alert('Bug!')>

3️⃣Через атрибут фокусу: <input onfocus=alert('Bug!') autofocus>

4️⃣Polyglot (Універсальний зломщик): javascript://%250Aalert(1)//" autofocus onfocus=alert(1)// (Цей рядок намагається закрити лапки, коментарі та теги в різних мовах одночасно).

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

1️⃣Копіюєте ці рядки по черзі в поле вводу (Ім'я, Опис, Пошук).

2️⃣Зберігаєте.

3️⃣Оновлюєте сторінку.

4️⃣Якщо ви побачили спливаюче вікно alert ("Bug!") — вітаю, ви знайшли Critical Security Bug. Біжіть до розробників.

Важливо: Тестуйте це тільки на тестових середовищах (Staging/Dev). Не робіть цього на проді, якщо не хочете налякати реальних користувачів! 😅

А ви проводите Security-тести чи залишаєте це на аудит? 👇

🚀 Баг ціною $125 млн: Чому важливо уточнювати вимоги

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

Сьогодні без коду і промптів. Історія про те, як одна пропущена нарада між командами знищила космічний апарат.

1999 рік. Mars Climate Orbiter. NASA запускає супутник на Марс. Мета: вивчати клімат червоної планети. Бюджет місії: $125 мільйонів. Політ триває 9 місяців. Все йде ідеально. Апарат підлітає до Марса, заходить на орбіту, ховається за планету і... зникає. Назавжди.

Що сталося? Інженери почали розслідування. Спочатку думали, що вибухнув двигун. Але правда виявилася смішнішою (і страшнішою).

Програму писали дві різні команди:

1️⃣Компанія Lockheed Martin (Колорадо) писала софт для розрахунку тяги двигунів. Вони використовували англійську систему мір (фунт-сила).

2️⃣Команда NASA (Каліфорнія) писала софт для навігації. Вони використовували метричну систему (Ньютони).

Коли одна система передала іншій число "тяга = 100", NASA подумали, що це 100 Ньютонів. А це було 100 фунтів. Різниця в 4.45 рази.

Через це двигуни відпрацювали занадто сильно (або занадто слабко), і супутник замість орбіти увійшов в атмосферу Марса на наднизькій висоті й просто згорів.

Мораль для QA: Цей баг неможливо було знайти в Unit-тестах. Кожен модуль окремо працював ідеально! Помилка була на рівні Integration Testing і Вимог. Ніхто не спитав: "А в яких одиницях ми передаємо дані?".

Тож наступного разу, коли ви питаєте аналітика: "А це поле в секундах чи в мілісекундах?" і він закочує очі — згадайте Mars Orbiter. Ви не зануда. Ви економите компанії мільйони.

А які найдорожчі (або найсмішніші) баги пропускали ви? 👇