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

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

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

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

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

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

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

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

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

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

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

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

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

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

За корисну інфографіку дякуємо Anastasiia Dyka, Senior Software QA Engineer | Mentor for IT beginners

#корисно #розвиток #tech

👉Всі наші платформи | Масонська ложа😎 |Вакансії|
👉Кар'єрне консультування