🗂 Рубрика: Ультимативна Шпаргалка #7 | Знищуємо баги ще в Jira (Shift-Left Testing)

Екіпаж, який баг найдешевший? Той, який ви знайшли до того, як розробник написав хоча б один рядок коду.

Аналіз вимог (тестування документації) — це те, що відрізняє "просто клікера" від Senior QA. Але читати сирі тікети в Jira з описом у стилі "зробіть, щоб користувач міг оплатити картою" — це біль. Там завжди не вистачає Acceptance Criteria, забуті корнер-кейси (edge cases), а бізнес-логіка часто суперечить сама собі.

Замість того, щоб витрачати години на деконструкцію тікета, натравлюємо на нього нейромережу.

Ідеальний промпт для краш-тесту вимог (Claude 3.5 / ChatGPT-4o):
"Дій як прискіпливий Senior QA Architect. Ось опис нової фічі з Jira (User Story):
[ВСТАВИТИ ТЕКСТ ТІКЕТА]

Твоя задача — провести жорстке 'Shift-Left' тестування цих вимог.

Знайди логічні діри, суперечності або пропущені сценарії безпеки/продуктивності.

Сформуй список із 5 незручних 'What if...?' (Що, якщо..?) запитань для продакт-менеджера. (Наприклад: проблеми з мережею, паралельними сесіями, невалідними станами чи лімітами).

Напиши 3 технічні Acceptance Criteria, яких тут критично не вистачає."

⚙️ Що це дає на практиці?
Ви приходите на Grooming або Sprint Planning не з пустими руками, а з готовим списком архітектурних запитань. Ви блокуєте розробку "сирої" фічі. Ваша цінність для бізнесу зростає моментально, бо ви економите тижні розробки ще до початку спринту.

А як у вас на проєкті з документацією?

👇

🔥 — Розношу тікети ще на етапі ідеї, ПМ мене боїться!
👀 — Вимоги завжди сирі, розбираємось уже по ходу тестування.
🤯 — Яка документація? У нас таски ставлять голосом на мітапах...