Баланс между
качеством и дедлайном

Приемочое тестирование

Ты протестировал все фичи, отловил баги, написал автотесты, провёл регрессию - вроде бы всё. Но... готово ли приложение к выпуску? Точно ли оно делает то, что нужно бизнесу и пользователю?
Вот тут на сцену выходит приёмочное тестирование - последняя проверка перед тем, как сказать: «Да, можно выкатывать».

завершенный баг

Что такое приёмочное тестирование?

Приёмочное тестирование (Acceptance Testing) - это финальная стадия тестирования, целью которой является подтверждение соответствия продукта бизнес-требованиям и ожиданиям заказчика или пользователя.

Это момент, когда бизнес или клиент говорит: «Да, именно это мы хотели».

Кто выполняет приёмочное тестирование?

Зависит от контекста, но чаще всего:

  • Клиент или заказчик (если проект внешний)
  • Бизнес-аналитик, продакт или стейкхолдер (если внутренний)
  • QA-инженеры (в некоторых случаях, если им делегирована эта роль)

Приёмочное тестирование - это не просто «ещё одна проверка». Это доказательство, что продукт делает то, ради чего его создавали.

Основные цели

  • Проверить, что все бизнес-требования реализованы
  • Убедиться, что критические пользовательские сценарии работают
  • Принять решение о готовности к релизу
  • Зафиксировать подтверждение готовности от клиента или владельца продукта

Когда проводится?

  • Перед выкатыванием в прод
  • После регрессионного тестирования
  • Иногда - на отдельной тестовой или staging-среде
  • В рамках спринта - в конце, перед демо

Типы приёмочного тестирования

Alpha Testing
Выполняется внутри команды, до передачи клиенту. Часто - QA + бизнес.

Beta Testing
Выполняется реальными пользователями в реальной или приближённой к ней среде. Цель - собрать фидбэк перед масштабным запуском.

Как выглядит приёмочное тестирование?

Как правило, используется набор acceptance-кейсов - это не технические юнит-тесты, а сценарии, написанные на языке бизнеса.

Пример:

  • Сценарий: Пользователь может оформить заказ с оплатой онлайн
  • Ожидаемый результат: Счёт успешно выставлен, платёж прошёл, статус заказа - «оплачен»

Иногда используют BDD-формат (Given-When-Then), особенно в Agile/Scrum-проектах.

Отличие от других видов тестирования

| Вид теста         | Цель                                   | Кто выполняет            |
|-------------------|----------------------------------------|--------------------------|
| Юнит-тесты        | Проверить отдельные функции            | Разработчики             |
| Интеграционные    | Проверить взаимодействие модулей       | QA / Dev                 |
| Системное         | Проверить всю систему целиком          | QA                       |
| Приёмочное        | Подтвердить, что продукт соответствует целям | Заказчик / Бизнес |

Частые ошибки

  • Считать, что если пройдена регрессия - значит всё готово
  • Забывать бизнес-контекст и проверять «по технике», а не по смыслу
  • Проводить приёмку без документации (при этом потом спорить, «так должно быть или нет»)
  • Отдавать продукт без согласования с бизнесом

Приёмочные критерии (Acceptance Criteria)

Каждая фича в нормальной разработке должна сопровождаться приёмочными критериями - условиями, при которых она считается завершённой.

Пример:

  • Кнопка «Отправить» активна только при заполнении всех обязательных полей
  • После отправки формы пользователь видит подтверждение
  • Сообщение сохраняется в базе

Если все критерии выполнены - фича принята.