Ответ
UAT (User Acceptance Testing) — это финальная фаза тестирования, в ходе которой конечные пользователи или заказчики проверяют, соответствует ли готовое программное обеспечение их бизнес-требованиям и готово ли оно к использованию в реальных условиях.
Цель: Убедиться, что система решает правильную бизнес-задачу, а не просто технически корректна.
Пример сценария (Gherkin-нотация):
Feature: Оформление заказа
Scenario: Успешное добавление товара в корзину
Given Пользователь авторизован на сайте
And Пользователь находится на странице товара "Книга"
When Пользователь нажимает кнопку "В корзину"
Then В шапке сайта отображается "1 товар в корзине"
And Товар "Книга" появляется в корзинеКлючевые аспекты UAT:
- Кто выполняет: Реальные пользователи, бизнес-аналитики или представители заказчика, а не команда разработки/тестирования.
- Где выполняется: В среде, максимально приближенной к продакшену (staging/pre-production).
- Что проверяется: Работоспособность ключевых бизнес-процессов (happy path), удобство использования, соответствие спецификациям.
- Результат: Формальное подписание акта приемки (Sign-off), которое дает зеленый свет для выпуска продукта в продакшен.
Ответ 18+ 🔞
Давай я тебе на пальцах объясню, что за зверь такой UAT, а то в этих умных книжках так заумно пишут, что мозг набекрень можно поставить.
Представь, ты заказал себе новый диван. Мастера его собрали, покрасили, вроде всё ровно. Они-то своё дело знают — молотком стучать, шурупы закручивать. Это unit-тесты и интеграционные. Но ты-то, как заказчик, приходишь и проверяешь не шурупы, а садишься на него жопой. Удобно ли? Не скрипит? Не развалится, когда тёща приедет? Вот это и есть UAT, блядь — User Acceptance Testing. Проверка на своей, прости господи, заднице.
Соль в чём: Цель — не найти баг в коде (этим пусть программисты друг другу мозги ебут), а понять, решает ли эта штука правильную задачу. Можно написать идеальный калькулятор, который складывает цифры со скоростью света, но если бухгалтеру надо считать налоги, а он только складывает — это просто красивая, но бесполезная хуйня.
Вот смотри, как это выглядит на деле, на примере интернет-магазина:
Feature: Оформление заказа
Scenario: Успешное добавление товара в корзину
Given Пользователь авторизован на сайте
And Пользователь находится на странице товара "Книга"
When Пользователь нажимает кнопку "В корзину"
Then В шапке сайта отображается "1 товар в корзине"
And Товар "Книга" появляется в корзинеТеперь главные правила, чтобы не облажаться:
- Кто рулит: Это делают не технари. Никаких тестировщиков, которые знают, где спрятаны костыли. Только реальные юзеры, бизнес-аналитики или сам заказчик — те, кому потом этим пользоваться. Иначе получится "о, да тут кнопка на 2 пикселя съехала, давайте две недели фиксить!", а бизнес-процесс нихуя не работает.
- Где рулит: Не на локальном компе какого-нибудь Виталика из отдела тестирования. Нужна среда, один в один как боевая. Чтобы все интеграции, все письма, все платежи летели как надо. Иначе в продакшене вылезет такое, что волосы дыбом встанут — "ёпта, а мы это не проверяли!".
- Что проверяют: Счастливый путь (happy path), ёбушки-воробушки! Основные сценарии: заказ оформить, отчёт получить, документ создать. Не надо ковыряться в дебрях настроек — проверяют, решает ли система ту самую бизнес-проблему, из-за которой всё и затевалось.
- Чем заканчивается: Самое важное — подписание акта приёмки (Sign-off). Это как роспись в паспорте. Заказчик говорит: "Да, мужики, я своей жопой проверил, диван меня устраивает, везите в дом". После этого можно запускать в продакшен и спать спокойно (ну, почти). Если акта нет — всё, пиздец, можно бесконечно дорабатывать и править, потому что "а вот нам ещё вот это хочется".
Короче, UAT — это последний и самый важный рубеж. Когда все технари уже выдохлись и думают, что сделали шедевр, приходят нормальные люди и проверяют, можно ли этим шедевром пользоваться без желания разбить монитор об стену.