Ты протестировал все фичи, отловил баги, написал автотесты, провёл регрессию - вроде бы всё. Но... готово ли приложение к выпуску? Точно ли оно делает то, что нужно бизнесу и пользователю?
Вот тут на сцену выходит приёмочное тестирование - последняя проверка перед тем, как сказать: «Да, можно выкатывать».
Что такое приёмочное тестирование?
Приёмочное тестирование (Acceptance Testing) - это финальная стадия тестирования, целью которой является подтверждение соответствия продукта бизнес-требованиям и ожиданиям заказчика или пользователя.
Это момент, когда бизнес или клиент говорит: «Да, именно это мы хотели».
Кто выполняет приёмочное тестирование?
Зависит от контекста, но чаще всего:
- Клиент или заказчик (если проект внешний)
- Бизнес-аналитик, продакт или стейкхолдер (если внутренний)
- QA-инженеры (в некоторых случаях, если им делегирована эта роль)
Приёмочное тестирование - это не просто «ещё одна проверка». Это доказательство, что продукт делает то, ради чего его создавали.
Основные цели
- Проверить, что все бизнес-требования реализованы
- Убедиться, что критические пользовательские сценарии работают
- Принять решение о готовности к релизу
- Зафиксировать подтверждение готовности от клиента или владельца продукта
Когда проводится?
- Перед выкатыванием в прод
- После регрессионного тестирования
- Иногда - на отдельной тестовой или staging-среде
- В рамках спринта - в конце, перед демо
Типы приёмочного тестирования
Alpha Testing
Выполняется внутри команды, до передачи клиенту. Часто - QA + бизнес.
Beta Testing
Выполняется реальными пользователями в реальной или приближённой к ней среде. Цель - собрать фидбэк перед масштабным запуском.
Как выглядит приёмочное тестирование?
Как правило, используется набор acceptance-кейсов - это не технические юнит-тесты, а сценарии, написанные на языке бизнеса.
Пример:
- Сценарий: Пользователь может оформить заказ с оплатой онлайн
- Ожидаемый результат: Счёт успешно выставлен, платёж прошёл, статус заказа - «оплачен»
Иногда используют BDD-формат (Given-When-Then), особенно в Agile/Scrum-проектах.
Отличие от других видов тестирования
| Вид теста | Цель | Кто выполняет |
|-------------------|----------------------------------------|--------------------------|
| Юнит-тесты | Проверить отдельные функции | Разработчики |
| Интеграционные | Проверить взаимодействие модулей | QA / Dev |
| Системное | Проверить всю систему целиком | QA |
| Приёмочное | Подтвердить, что продукт соответствует целям | Заказчик / Бизнес |
Частые ошибки
- Считать, что если пройдена регрессия - значит всё готово
- Забывать бизнес-контекст и проверять «по технике», а не по смыслу
- Проводить приёмку без документации (при этом потом спорить, «так должно быть или нет»)
- Отдавать продукт без согласования с бизнесом
Приёмочные критерии (Acceptance Criteria)
Каждая фича в нормальной разработке должна сопровождаться приёмочными критериями - условиями, при которых она считается завершённой.
Пример:
- Кнопка «Отправить» активна только при заполнении всех обязательных полей
- После отправки формы пользователь видит подтверждение
- Сообщение сохраняется в базе
Если все критерии выполнены - фича принята.