Виступи в ролі досвідченого UX-дослідника та Product Manager. Я тестую нову фічу "Фільтри товарів" для нашого e-commerce додатку.

**Завдання:**
1.  Назви 3-5 основних конкурентів [вставте вашу сферу, напр., "у сфері e-commerce в Україні"].
2.  Склади чек-лист з 10 "must-have" функцій та зручностей, які користувачі очікують бачити у фільтрах товарів (на основі найкращих практик).
3.  Запропонуй 3 "вау-фічі" (неочевидні, але зручні), які є у лідерів ринку і які ми могли пропустити.

1️⃣Must-have функції:

🔹Фільтр за ціною (слайдер).

🔹Фільтр за брендом (з пошуком).

🔹Фільтр за рейтингом (від 4+ зірок).

🔹Можливість обрати кілька значень в одній категорії (напр., бренди "А" і "Б").

🔹Кнопка "Скинути всі фільтри".

2️⃣"Вау-фічі" (ідеї для тестування та покращення):

🔹Показ кількості товарів: Показувати в реальному часі, скільки товарів буде знайдено ((115)), ще до натискання кнопки "Застосувати".

🔹Неактивні фільтри: Не ховати, а робити сірими ті варіанти фільтрів, які не дадуть жодного результату (напр., якщо обрали "Телевізор" -> "Samsung", то бренд "Apple" стає сірим).

🔹Збереження фільтрів: Можливість зберегти обраний набір фільтрів для майбутніх пошуків.

Виступи в ролі досвідченого QA Lead. Мені потрібно оцінити час на тестування нової User Story.

**User Story:** "Як користувач, я хочу мати можливість редагувати свій профіль (ім'я, прізвище, аватар)."

**Завдання:**
1.  **Декомпозиція:** Розбий цю фічу на основні підзадачі (scenarios), які потрібно протестувати.
2.  **Чек-лист ризиків:** Назви 3-4 потенційні проблеми або edge-кейси, які можуть ускладнити тестування.
3.  **Оцінка:** На основі цього, запропонуй приблизну оцінку часу (в Story Points або годинах) на повне тестування.

1️⃣Декомпозиція (Основні сценарії):
🔹Тестування UI (чи всі поля та кнопки на місці).
🔹Позитивний сценарій (зміна всіх полів, збереження).
🔹Негативні сценарії (валідація полів: занадто довге ім'я, порожні поля).
🔹Тестування завантаження аватара (різні формати, розміри).
🔹Тестування скасування (кнопка "Скасувати").

2️⃣Потенційні ризики (Edge Cases):
🔹Аватар не завантажується (помилка сервера).
🔹Втрата сесії під час редагування.
🔹Проблеми з безпекою (XSS в полі "Ім'я").
🔹Перевірка, що зміни відобразилися в інших частинах додатку (напр., в хедері).

3️⃣Приблизна оцінка:
🔹Враховуючи необхідність тестування UI, валідації, завантаження файлів та перевірки безпеки, рекомендована оцінка — 8 Story Points (або 10-12 годин), щоб покрити всі сценарії.

Виступи в ролі досвідченого 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 накопичилася розбіжність у фінансових звітах на тисячі гривень."