Claude може легко згенерувати вам дуже гарні тест-кейси на бізнес-вимоги, яких і близько немає у вашому продукті 

Буває? Та звісно 

Тому роботу з Клод (з іншими АІ - також) варто починати з аналізу вимог: що визначено, де є суперечності та які рішення ще потрібно погодити (тут Клод вже не допоможе).

На інфографіці - зібрала 6 напрямів такої роботи. 
Покажу їх на простому практичному прикладі: «Користувач може скасувати підписку».

 Знайти прогалини у вимогах
Коли припиняється доступ: одразу чи наприкінці оплаченого періоду? 
Що відбувається з наступним списанням? 
Чи передбачене повернення?
Клод може запропонувати ці питання. Відповіді мають спиратися на правила вашого продукту.

 Підготувати питання до BA/PO
Наприклад: «Якщо скасування відбулося під час обробки автопродовження, яке правило визначає результат?»
Додайте, що залежить від відповіді: статус підписки, списання та доступ юзера.

 Перевірити Acceptance Criteria
«Підписка успішно скасовується» залишає прям дуууже багато простору для інтерпретацій 
Попросіть Клод перевірити, чи визначені початковий стан, дія та спостережуваний результат: статус, дата завершення доступу, стан автопродовження. Відсутні правила - це ваші питання для погодження.

 Сформулювати ризики
Наприклад: платіжний провайдер підтвердив скасування, але система не отримала повідомлення - потенційно можемо мати проблему!
Це гіпотеза, актуальність якої потрібно перевірити за архітектурою інтеграції.
Ясно, що потрібні оцінки такої ймовірності (може, такого і не можу статися взагалі)

 Розширити сценарії
Окрім успішного скасування, розгляньте повторний запит, таймаут, уже скасовану підписку та одночасне автопродовження.
Для кожного сценарію визначте передумови й очікуваний результат. 
Якщо результат нам невідомий - є прогалина у вимогах.

 Декомпозувати фічу
Виділіть керування підпискою, платежі, права доступу та сповіщення. 
Позначте залежності й наскрізні перевірки: зміна статусу має узгоджуватися з доступом і платіжною поведінкою відповідно до ваших правил.

Для кожного запиту раджу додавати:
«Для кожного висновку вкажи ID або фрагмент вимоги. Окремо познач припущення. Якщо очікувана поведінка не визначена - сформулюй питання. 
Не додавай та не вигадуй бізнес-правила від себе».

Або прописати це в загальній інструкції, бо так простіше.

Зберегайте схему для наступного refinement - або спробуйте застосувати її до однієї реальної user story.

За корисну інфографіку дякуємо [Anastasiia Dyka](https://www.linkedin.com/in/a-dyka/?lipi=urn%3Ali%3Apage%3Ad_flagship3_detail_base%3B9vcjZC6GQoCr31jJTYw5iw%3D%3D), Senior Software QA Engineer | Mentor for IT beginners

[#корисно](?q=%23%D0%BA%D0%BE%D1%80%D0%B8%D1%81%D0%BD%D0%BE) [#розвиток](?q=%23%D1%80%D0%BE%D0%B7%D0%B2%D0%B8%D1%82%D0%BE%D0%BA) [#tech](?q=%23tech)

**[Всі наші платформи](https://linktr.ee/juniverse_ua)** | **[Масонська ложа](https://t.me/+lUs6TYXFy0UxNjAy)** |[Вакансії](https://t.me/+1nmach7hIiQ1MDMy)**|**
**[Кар'єрне консультування](https://t.me/Job_IT_Junior/10434)