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

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

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

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

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

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

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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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".

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

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

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

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

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

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

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

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

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