Стратегія тестування починається з ризику
Команда «згенеруй тести» не є стратегією. Спочатку потрібно визначити, яку поведінку слід довести, які помилки найдорожчі, на якому рівні тест дасть найкращий сигнал і що свідомо залишиться поза межами PR.
Claude Code може допомогти спроєктувати набір перевірок і розкласти ризики, але рішення про достатність тестування залишається за інженером.
- Прочитайте специфікацію та acceptance criteria.
- Перегляньте змінені й повʼязані файли.
- Визначте business risk і change risk.
- Зафіксуйте TEST_STRATEGY.md або секцію стратегії в задачі.
- Виберіть рівні тестування для пріоритетних сценаріїв.
- Після реалізації запустіть checks і проаналізуйте diff.
Два виміри risk-based testing
| Вимір | Приклади сигналів |
|---|---|
| Business risk | Фінанси, доступ, дані, публічний API, критичний user flow, довіра |
| Change risk | Великий diff, кілька шарів, новий модуль, слабке покриття, інтеграції |
| Високий пріоритет | Обидва ризики значні — потрібен сильніший і точніший evidence |
| Низький пріоритет | Мала зміна та низька ціна помилки — достатньо локальної перевірки |
Різні рівні плану та review не слід плутати
L1 verification може означати загальний план: потрібні regression, API та smoke-перевірки. L2 verification деталізує конкретні сценарії, рівні тестування та їхнє обґрунтування. Layer 2 review — окремий CI або review-етап, а не назва тестового рівня.
| Рішення | Питання |
|---|---|
| L1 verification | Які категорії перевірок потрібні? |
| L2 verification | Які конкретні inputs, рівні й assertions потрібні? |
| Layer 2 review | Чи може технічний gate пропустити зміну далі? |
Приклад TEST_STRATEGY.md
# Test strategy
## Unit
- ...
## Integration / API
- ...
## Smoke
- ...
## Manual checks
- ...
## Risks not covered
- ...Coverage — індикатор, а не мета
- Високий відсоток покриття не гарантує захисту критичного flow.
- Coverage допомагає бачити сліпі зони та падіння покриття після змін.
- Другорядні форматери можуть підняти цифру, не захистивши refund або payment flow.
- Основним критерієм має бути якість evidence щодо ризикової поведінки.
- Під час планування Claude не повинен одразу генерувати тестовий код.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush