Ответ
Документация по регрессионному тестированию фиксирует набор проверок, предназначенных для подтверждения того, что существующая функциональность не сломалась после внесения изменений (новый функционал, исправления багов, обновления библиотек).
Ключевые компоненты такой документации:
## План регрессионного тестирования v3.5
**Цель:** Проверить стабильность основных модулей после интеграции нового платежного шлюза.
**Объем:** Полный регресс (ядро системы) — 85 тест-кейсов.
**Окружение:** Windows 11 / macOS 14, Chrome 120 / Firefox 115, API: staging-v3.
**Приоритетные области и примеры тест-кейсов:**
1. **Модуль аутентификации (Высокий приоритет)**
* TC-AUTH-01: Успешный вход по логину/паролю.
* TC-AUTH-05: Восстановление пароля по email.
2. **Модуль заказов (Критичный)**
* TC-ORD-10: Создание заказа с оплатой картой.
* TC-ORD-15: Просмотр истории заказов.
3. **Админ-панель (Средний приоритет)**
* TC-ADM-02: Изменение статуса заказа.
**Ссылки на артефакты:**
* Коллекция Postman: `Regression_Core_v3.5.json`
* Набор автотестов (Playwright): `/tests/regression/`
* Чек-лист для ручного тестирования: [Ссылка на Confluence]
**Критерии завершения:** Выполнение 100% тестов с высоким приоритетом и ≥95% от общего плана.Документация служит источником истины о том, что нужно проверять, как и когда. Она часто хранится в системах управления тест-кейсами (TestRail, Zephyr) или wiki (Confluence), интегрируясь с отчетами о выполнении.