Почніть із критеріїв приймання
Не починайте з “які тести написати?”. Спочатку опишіть, за якими ознаками фіча вважається готовою. Наприклад:
- користувач може зберегти нове поле;
- API повертає новий параметр;
- помилка показується людським текстом;
- стара поведінка не змінилася для інших ролей.
Це дає AI межі задачі. Без критеріїв приймання план легко роздувається або пропускає головне.
Розділіть перевірки за типами
Для маленької фічі не завжди потрібен великий набір e2e. Але майже завжди потрібні три групи:
- основний сценарій: головна дія користувача;
- межові випадки: порожні значення, права доступу, межові стани, повторні кліки;
- регресійні перевірки: сусідні сценарії, які вже працювали до зміни.
Якщо фіча йде в робочий продукт, додайте коротку перевірку після деплою.
Не тестуйте все підряд
Хороший тест-план має не тільки список перевірок, а й межі. Якщо щось не входить у перевірку, краще сказати це прямо. Наприклад: “не перевіряємо стару мобільну верстку”, “не перевіряємо зовнішню інтеграцію”, “не робимо тест продуктивності”.
Це не халтура. Це чесне керування ризиком.
Коротко
Маленька фіча не потребує великої тестової стратегії. Але вона потребує ясного мінімуму: що має працювати, що може зламатися поруч, що перевірити руками і що подивитися після деплою.
AI добре допомагає з таким планом, якщо дати йому межі перевірки, критерії приймання і ризики поруч.
Короткий чеклист
- Назвати критерії приймання перед тестами.
- Перевірити основний сценарій і 2-3 межові випадки.
- Додати регресійні перевірки для сусідніх частин.
- Відділити автоматичні тести від ручної перевірки.
- Підготувати швидку перевірку після деплою.
- Чесно записати, що не входить у межі перевірки.
Скласти план тестування маленької фічі
Допоможи скласти короткий план тестування для маленької фічі. Контекст: - Що змінюється: [короткий опис фічі] - Для кого ця зміна: [користувач, адміністратор, API-клієнт, внутрішня команда] - Критерії приймання: [список очікуваної поведінки] - Де це працює: [сторінка, endpoint, команда, задача, інтеграція] - Що може зламатися поруч: [логін, платежі, права доступу, валідація, кеш, UI] - Доступні перевірки: [модульні тести, інтеграційні тести, e2e, ручна QA-перевірка, staging] - Обмеження: [немає часу, немає тестових даних, немає staging, інше] Побудуй план: 1. Основний сценарій: що обов'язково має працювати. 2. Межові випадки: які межові або дивні сценарії перевірити. 3. Регресійні перевірки: що поруч могло зламатися. 4. Ручні перевірки: що треба клацнути або перевірити руками. 5. Швидка перевірка після деплою. 6. Що можна не тестувати зараз і чому. Формат відповіді: - Межі перевірки - Обов'язкові перевірки - Межові випадки - Регресійні перевірки - Ручна QA-перевірка - Швидка перевірка після деплою - Що не входить у перевірку