1️⃣Емпатія (Адвокат Користувача) AI може перевірити, чи працює кнопка. Але він не може відчути, що ця кнопка незручна, дратує або вводить в оману. Вміння поставити себе на місце користувача, зрозуміти його біль і захистити його інтереси перед командою — це чисто людська і безцінна навичка.

2️⃣Вміння ставити питання (Майстер Промптингу) Ми вже говорили про це, але це критично важливо. Якість відповіді AI на 90% залежить від якості вашого питання. Вміння чітко декомпозувати проблему, дати правильний контекст і поставити AI таке запитання, щоб отримати геніальну відповідь, — це і є новий "технічний скіл".

3️⃣Економічне мислення (Адвокат Бізнесу) AI знайде вам 100 багів. Але який з них коштує компанії $10 000 на день, а який — $1? Вміння пріоритезувати баги не за технічною складністю, а за впливом на бізнес-метрики (конверсія, відтік, дохід) — це те, що відрізняє Senior QA від Junior-виконавця. (Ми говорили про це в пості "QA як адвокат" 😉).

1️⃣"Shift-Left" на стероїдах: QA тестує код, написаний AI. Раніше ми тестували код, який написав розробник. Тепер ми все частіше тестуємо код, який розробник згенерив за допомогою GitHub Copilot чи іншого асистента. Що це змінює? AI пише код неймовірно швидко, але часто "галюцинує" і пропускає edge-кейси. Задача QA змістилася: ми маємо не просто "знайти баг", а "перевірити логіку AI" і бути тим самим "дорослим наглядачем", який питає: "А що, якщо...?"

2️⃣"Test Observability" (спостережуваність) — це нова норма. "Червоний" білд і незрозумілий лог на 10 000 рядків — це минуле століття. Що це змінює? Сучасні інструменти (та й AI-помічники) дозволяють миттєво зрозуміти, чому тест впав. Ми одразу бачимо скріншот, запис екрана, мережеві запити та помилки в консолі, пов'язані з конкретним кроком. Це перетворює дебагінг з годин на хвилини і робить роботу автоматизатора набагато приємнішою.

3️⃣QA = Базова кібербезпека (Security-Aware QA). Раніше безпека була справою окремого відділу. Зараз, через прискорення розробки, компанії очікують, що QA буде першою лінією оборони. Що це змінює? Знання основ OWASP Top 10, вміння перевірити базові XSS, SQL Injection (хоча б за допомогою AI-асистента) — це стає такою ж базовою вимогою, як і вміння написати тест-кейс.

Виступи в ролі досвідченого 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).