Виступи в ролі досвідченого QA Architect. Я планую регресійне тестування для нашого e-commerce додатку.

**Основні модулі системи:**
1.  Реєстрація та Логін (включно з Google/Facebook auth).
2.  Каталог товарів та Фільтри.
3.  Кошик та Оформлення замовлення.
4.  Платіжний шлюз (інтеграція з LiqPay).
5.  Адмін-панель (керування товарами).

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

1️⃣Сценарій відновлення кошика: Що станеться, якщо користувач наповнить кошик, вийде з акаунту, а потім увійде знову через Google-аутентифікацію? Його кошик відновиться чи очиститься? (Інтеграція #1 і #3).

2️⃣Синхронізація "залишків": Що буде, якщо користувач оформлює замовлення (Модуль #3) на останній товар на складі, і в цей же момент менеджер в адмін-панелі (Модуль #5) видаляє цей товар? (Race condition).

3️⃣Обробка "відваленого" платежу: Що, якщо користувач оплатив на LiqPay (Модуль #4), але не натиснув "Повернутися в магазин"? Чи отримає наш додаток сповіщення (webhook) і чи створиться замовлення?

4️⃣Логіка фільтрів та кешування: Якщо в адмін-панелі додати новий товар, як швидко він з'явиться у фільтрах (Модуль #2) для користувача? Чи не закешуються старі дані?

5️⃣"Застаріла" сесія: Що, якщо користувач тримав вкладку з кошиком відкритою 3 дні, а потім натиснув "Оплатити"? Чи валідує система ціни та наявність товару повторно?

🔹Feature Flags (Фіча-тогли): Нова фіча "загорнута" в if і вимикається/вмикається на льоту. QA може увімкнути її тільки для себе на продакшені і протестувати.

🔹Canary Releases (Канаркові релізи): Нова версія "викочується" лише на 1% користувачів. Команда QA (разом з DevOps) уважно стежить за метриками.

🔹A/B Тестування: Дві версії фічі працюють одночасно для різних груп, щоб побачити, яка краща.

Виступи в ролі досвідченого SRE (Site Reliability Engineer).

**Завдання:**
Я щойно запустив "canary" реліз нової фічі на 1% користувачів. Я маю доступ до real-time логів та метрик (помилки, час відповіді, CPU).

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

1️⃣Сплеск "тихих" помилок: Не тільки 500-ті, а й 400-ті (напр., 401 Unauthorized), що може свідчити про проблеми з кешем токенів у новій версії.

2️⃣Зростання затримки (Latency) p95: Середній час відповіді може бути в нормі, але 95-й перцентиль (найповільніші запити) почав "гальмувати" — явна ознака деградації.

3️⃣Нерівномірне навантаження на CPU: Один з 10 серверів, де крутиться нова версія, раптом почав споживати на 30% більше CPU.

4️⃣Незвичні патерни логів: З'явилися нові типи warning-повідомлень, яких не було раніше.

5️⃣Падіння конверсії в групі: У групи "Canary" раптом впала кількість натискань на кнопку "Купити" (порівняно з 99% інших користувачів).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🔹"Чому подія, створена о 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️⃣Список "дірок" у логіці, які ви миттєво перетворюєте на баги або уточнення.