Почніть із критеріїв приймання
Не починайте з “які тести написати?”. Спочатку опишіть, за якими ознаками фіча вважається готовою. Наприклад:
- користувач може зберегти нове поле;
- API повертає новий параметр;
- помилка показується людським текстом;
- стара поведінка не змінилася для інших ролей.
Це дає AI межі задачі. Без критеріїв приймання план легко роздувається або пропускає головне.
Розділіть перевірки за типами
Для маленької фічі не завжди потрібен великий набір e2e. Але майже завжди потрібні три групи:
- happy path: основний сценарій;
- edge cases: порожні значення, permissions, межові стани, повторні кліки;
- regression checks: сусідні сценарії, які вже працювали до зміни.
Якщо фіча йде в production, додайте короткий smoke check після deploy.
Не тестуйте все підряд
Хороший тест-план має не тільки список перевірок, а й межі. Якщо щось не входить у scope, краще сказати це прямо. Наприклад: “не перевіряємо старий mobile layout”, “не перевіряємо зовнішню інтеграцію”, “не робимо performance test”.
Це не халтура. Це чесне керування ризиком.
Пакет підказок
Скопіюйте цей запит, коли треба швидко скласти тест-план:
Допоможи скласти короткий план тестування для маленької фічі.
Контекст:
- Що змінюється: [короткий опис фічі]
- Для кого ця зміна: [користувач, адміністратор, API client, внутрішня команда]
- Критерії приймання: [список очікуваної поведінки]
- Де це працює: [сторінка, endpoint, команда, job, інтеграція]
- Що може зламатися поруч: [логін, платежі, permissions, валідація, кеш, UI]
- Доступні перевірки: [unit tests, integration tests, e2e, manual QA, staging]
- Обмеження: [немає часу, немає test data, немає staging, інше]
Побудуй план:
1. Happy path: що обов'язково має працювати.
2. Edge cases: які межові або дивні сценарії перевірити.
3. Regression checks: що поруч могло зламатися.
4. Manual checks: що треба клацнути або перевірити руками.
5. Smoke check після deploy.
6. Що можна не тестувати зараз і чому.
Формат відповіді:
- Scope
- Must-pass checks
- Edge cases
- Regression checks
- Manual QA
- Post-deploy smoke check
- Not in scope
Коротко
Маленька фіча не потребує великої тестової стратегії. Але вона потребує ясного мінімуму: що має працювати, що може зламатися поруч, що перевірити руками і що подивитися після deploy.
AI добре допомагає з таким планом, якщо дати йому scope, критерії приймання і ризики поруч.
Короткий чеклист
- Назвати критерії приймання перед тестами.
- Перевірити happy path і 2-3 edge cases.
- Додати регресійні перевірки для сусідніх частин.
- Відділити автоматичні тести від ручної перевірки.
- Підготувати smoke check після deploy.
- Чесно записати, що не входить у scope.
Пакет підказок: скласти план тестування маленької фічі
Допоможи скласти короткий план тестування для маленької фічі. Контекст: - Що змінюється: [короткий опис фічі] - Для кого ця зміна: [користувач, адміністратор, API client, внутрішня команда] - Критерії приймання: [список очікуваної поведінки] - Де це працює: [сторінка, endpoint, команда, job, інтеграція] - Що може зламатися поруч: [логін, платежі, permissions, валідація, кеш, UI] - Доступні перевірки: [unit tests, integration tests, e2e, manual QA, staging] - Обмеження: [немає часу, немає test data, немає staging, інше] Побудуй план: 1. Happy path: що обов'язково має працювати. 2. Edge cases: які межові або дивні сценарії перевірити. 3. Regression checks: що поруч могло зламатися. 4. Manual checks: що треба клацнути або перевірити руками. 5. Smoke check після deploy. 6. Що можна не тестувати зараз і чому. Формат відповіді: - Scope - Must-pass checks - Edge cases - Regression checks - Manual QA - Post-deploy smoke check - Not in scope