🕵️ Кто виноват в багах на проде – заказчик или подрядчик? 7 лет опыта в заказной разработке.
За 7 лет работы над проектами я видел десятки релизов, которые шли по одному сценарию:
Релиз → радость команды → через час сообщения: «Не работает!», «Куда пропала кнопка?», «Почему списало лишние деньги?».
И начинается переписка в духе:
Подрядчик: «Мы всё сделали по ТЗ, куда вы смотрели?»
Заказчик: «Вы нам сломанный продукт подсунули!»
На самом деле проблема не в людях, а в процессе. Точнее, в его отсутствии. И имя этому процессу – User Acceptance Testing (UAT), или приёмочное тестирование пользователем.
Что такое UAT
UAT – это финальная проверка системы перед релизом, которую проводит заказчик или его представители. Цель – убедиться, что продукт работает так, как нужно бизнесу, и удобен конечным пользователям. Это не про поиск багов в коде – это про проверку, что решение закрывает реальные задачи в боевых сценариях.
📌 QA ≠ UAT
QA проверяет: «Работает ли система так, как в ТЗ?»
UAT проверяет: «Решает ли система реальную задачу и удобно ли ей пользоваться?»
Простая аналогия: QA проверяет, что у машины крутятся колёса и горят фары.
UAT – это тест‑драйв: удобно ли сидеть, влезает ли коляска, комфортно ли ехать по дороге.
🛡️ Зачем нужен UAT
Подрядчику – чтобы зафиксировать, что заказчик видел и подтвердил результат. Это его страховка.
Заказчику – чтобы убедиться, что система реально пригодна для работы. Это его последний шанс.
Найти критический баг на UAT в 100 раз дешевле, чем на проде в руках реальных клиентов.
🎯 5 правил UAT, выстраданных на практике
1. Чёткие сценарии, а не «потестируйте»
Самая большая ошибка – дать доступ и сказать: «Ну, посмотрите». Тестирование должно идти по заранее написанным кейсам, описывающим реальный бизнес‑процесс.
Плохо: «Проверьте создание заказа».
Хорошо: «Сценарий: Авторизуйтесь под пользователем "Иван", добавьте товар X, примените промокод "SALE25", выберите доставку. Ожидаемый результат: скидка применилась корректно, итоговая сумма — 1500 рублей».
2. Тестируют реальные пользователи
Приёмку должен проводить не директор, а бухгалтер Мария Ивановна или менеджер Пётр – те, кто будет работать с системой каждый день. Их обратная связь – самая ценная.
3. Цель – логика и удобство, не пиксели
Основная задача UAT – ответить на вопрос: «Решает ли это мою проблему так, как я ожидал?».
Опечатки и съехавшая на 2 пикселя кнопка важны, но вторичны. Они не должны блокировать приёмку, если основной бизнес‑процесс работает.
4. Финальный статус в явном виде
UAT заканчивается не устным «ок», а формальным вердиктом в таск‑трекере.
Варианты:
Accepted – Принято;
Accepted with comments – Принято с некритичными замечаниями;
Rejected – Отклонено, есть блокеры.
5. Новые идеи – отдельно
Во время теста у заказчика часто рождаются гениальные идеи: «А давайте тут добавим кнопку!». Это прекрасно, но это новая хотелка. Фиксируем её как отдельную задачу, чтобы не срывать текущий релиз.
🏁 Кто отвечает за баги на проде
Если UAT был проведён и задача принята – ответственность на заказчике.
Если UAT не проводился или проводился формально – виноваты обе стороны: подрядчик не настоял, заказчик не проверил.
Правильный UAT переводит вопрос «кто виноват» в «что мы вместе сделали, чтобы этого не допустить». Это экономит деньги, нервы и сохраняет отношения между заказчиком и подрядчиком.
👉 Александр Андреев. Подписаться
