Приемка программного обеспечения: как проверить работу и акт

Почему приемка — не формальность

Типичная картина: сайт, CRM или бот «запущены», менеджер пару раз нажал на кнопки, всё открылось, акт подписан. Через неделю выясняется, что заявки не доходят до отдела продаж, оплата через Click проходит, а статус заказа не меняется, и у оператора нет прав на нужный раздел. Формально работа принята, и любые правки теперь выглядят как новые пожелания.

Приемка программного обеспечения нужна, чтобы этого не случилось. Её задача проста: сопоставить то, что вы заказывали, с тем, что получили, и зафиксировать разницу письменно. Это не недоверие к разработчику. Нормальные подрядчики сами заинтересованы в чёткой приемке: она защищает и их от бесконечных правок «по ощущениям».

Шаг 1. Договоритесь о критериях приемки заранее

Критерии пишутся не в конце, а до начала разработки, вместе с техническим заданием. Для каждой функции нужен ответ на вопрос: по какому признаку мы скажем, что она готова. Формулировка «бот должен принимать заказы» слишком расплывчата.

Рабочая формулировка: клиент выбирает товар, указывает адрес или отправляет геолокацию, видит итоговую сумму в сумах, получает подтверждение, а менеджер в тот же момент получает уведомление в рабочем чате. Когда критерии записаны, приемка превращается в проверку по списку, а не в спор о вкусах.

Если договор уже подписан, а критериев нет, составьте их до начала проверки и согласуйте перепиской. Это лучше, чем проверять «как получится».

Шаг 2. Подготовьте тестовые сценарии

Сценарий — это цепочка действий реального человека с ожидаемым результатом. Берите не абстрактные функции, а живые ситуации вашего бизнеса. Для Telegram-бота интернет-магазина или доставки это может быть так:

• Новый клиент запускает бота, выбирает язык (русский или узбекский) и видит корректное меню на этом языке
• Клиент собирает корзину, меняет количество, удаляет позицию и оформляет заказ
• Клиент оплачивает через Click или Payme, и заказ получает статус «оплачен» без ручных действий
• Клиент закрывает окно оплаты, не дойдя до конца: заказ не должен считаться оплаченным
• Менеджер меняет статус заказа, и клиент получает сообщение в Telegram
• Администратор выгружает отчёт за период, и сумма совпадает с ручным подсчётом
• Сотрудник без прав администратора пытается открыть чужой раздел и получает отказ

Шаг 3. Проверяйте не только удачные сценарии

Большинство проблем прячется не в основном пути, а на его краях. Проверьте ошибки ввода: буквы вместо номера телефона, пустое сообщение, стикер вместо адреса, очень длинный текст. Проверьте нестандартные ситуации: клиент нажимает «назад» посреди оформления, дважды жмёт кнопку оплаты, пишет боту в момент, когда товар закончился.

Отдельно проверьте объёмы. Бот, который отлично работает при трёх тестовых заказах, может тормозить, когда в акцию одновременно пишут десятки людей. Попросите показать работу на данных, близких к реальным: настоящий прайс, настоящий список филиалов, названия на кириллице и латинице, слова с апострофом вроде «o‘rik» или «Qo‘qon».

Кто проверяет и на каких данных

Проверять должны те, кто будет работать с системой каждый день: операторы, менеджеры, кладовщик, бухгалтер. Они быстро замечают неудобства и несоответствия процессу, которые не видит директор. Со стороны заказчика нужен один координатор, который собирает замечания в единый список, чтобы разработчик не получал десять противоречивых сообщений из разных чатов.

Тестовые данные удобны разработчику, но слабо похожи на реальность. Если можно, используйте копию реальных данных или близкий к ним набор. Но для платёжных и персональных данных клиентов сначала согласуйте безопасный режим проверки, а не тестируйте на живых картах и настоящих базах без необходимости.

Чек-лист: что проверить перед подписанием акта

Пройдите список целиком и отметьте каждый пункт отдельно. Пропущенный пункт — это будущая проблема.

• Функции соответствуют требованиям и критериям приёмки
• Интеграции работают: платёжные системы, CRM, Google Sheets, SMS, уведомления в Telegram
• Права ролей: администратор, менеджер, оператор видят и меняют только своё
• Скорость на реальном объёме данных; работа на разных телефонах и версиях Telegram, а для веб-части — в разных браузерах
• Тексты на двух языках без ошибок и обрезанных кнопок
• Документация: инструкция для сотрудников и техническое описание
• Передача исходного кода, домена, серверов, ключей и паролей на ваше имя

Типичные ошибки заказчика

Первая ошибка — принять работу по демонстрации. Когда показывает разработчик, он идёт по заведомо рабочему пути. Нажимать должны вы или ваши сотрудники.

Вторая — подписать акт ради того, чтобы «не задерживать проект», с мыслью «недочёты потом поправим». Без договорённости о сроках исправления такие недочёты могут висеть месяцами. Третья — не проверить доступы: код и аккаунты остаются на подрядчике, и сменить исполнителя становится сложно. Четвёртая — принимать устно: замечания в голосовых сообщениях Telegram через месяц невозможно найти. Пятая — проверять только на своём телефоне и в удобное время, а не на типичных устройствах клиентов в регионах с медленным интернетом.

Приемка по частям или целиком

Есть два подхода. Приемка в конце проще в организации, но ошибки находятся поздно, когда их исправление дороже и спорнее. Приемка по этапам требует больше вашего времени, зато каждый блок — меню, оформление заказа, оплата, админка — проверяется, пока разработчик ещё в контексте.

Для проекта с оплатой и интеграциями разумно принимать этапами, а финальную приемку делать как сквозной прогон всех сценариев подряд. Так вы проверяете не отдельные детали, а то, как они работают вместе.

Замечания, передача, гарантия и акт

Каждое замечание записывается в одном формате: что проверялось, что ожидалось, что получилось, скриншот или запись экрана. Затем замечания делятся на критичные (мешают работе или грозят потерей денег и заказов — исправляются до подписи) и некритичные (неудобства и косметика — фиксируются со сроком). После правок проверку повторяют по тем же сценариям, потому что исправление одного места иногда ломает соседнее.

Передача — часть приёмки, а не вежливый бонус. Исходный код должен лежать в репозитории на вашем аккаунте, домен и хостинг оформлены на вас, а токен бота, ключи платёжных систем и пароли переданы безопасным способом и при необходимости заменены после сдачи. Гарантийный период — срок, в течение которого разработчик бесплатно исправляет ошибки, найденные после приёмки; его длительность и границы между ошибкой и новой доработкой нужно прописать в договоре.

Подписывайте акт, когда критичные замечания закрыты, некритичные записаны со сроками, документация и доступы переданы. Если вы заказываете Telegram-бота или другой цифровой продукт в markdev, критерии и сценарии проверки лучше согласовать до начала работы — тогда приемка идёт по понятному списку. Хотите обсудить свою задачу — напишите нам, и мы вместе продумаем порядок приемки под ваш проект.