Приемка приложения не должна сводиться к случайным кликам и сбору разрозненных замечаний. Сначала вернитесь к согласованному объему и опишите основные сценарии: кто выполняет действие, какие данные использует, какой результат должен получить и что должно произойти в нестандартной ситуации.
Каждый результат стоит записывать в одном месте. Замечания нужно разделить на несоответствие объему, препятствие для теста, неясную договоренность и новую потребность. Только после этого можно осознанно принять этап, принять его с условиями или указать элементы, которые необходимо исправить.
Критерии приемки лучше согласовать до начала разработки. Если этого не сделали, обе стороны могут описать ожидаемое поведение перед тестированием. Однако это не должно незаметно расширять первоначальный объем.
Сначала уточните, что именно вы принимаете
Отправная точка - согласованный результат, а не все функции, которые приложение когда-нибудь сможет выполнять. Соберите предложение, описание этапа, одобренные изменения и явно исключенные элементы. Если договоренности находятся в разных сообщениях и документах, до приемки подготовьте одно резюме действующей версии.
В резюме должны быть:
- проблема, которую должен был решить этап;
- функции и процессы в согласованном объеме;
- пользователи и их роли;
- данные, файлы и интеграции, необходимые для работы;
- явно исключенные элементы;
- человек, уполномоченный принять решение;
- примеры или критерии, подтверждающие завершение этапа.
Если компания принимает первую часть большой системы, ее нельзя оценивать по функциям, запланированным на будущее. При этом нужно проверить, дает ли сам этап результат, описанный в предложении. Статья Как выбрать исполнителя веб-приложения? объясняет, почему такие правила стоит согласовать до начала сотрудничества.
Подготовьте сценарии приемки
Сценарий приемки описывает реальную задачу пользователя. Он не обязан быть технической документацией, но должен отвечать на пять вопросов:
- Кто выполняет действие?
- Каково начальное состояние?
- Какие данные используются?
- Какие шаги выполняются?
- Какой результат должен появиться в приложении и связанных системах?
Сначала опишите основной ход процесса. Затем добавьте важные нестандартные ситуации, которые действительно могут возникнуть. В зависимости от решения это могут быть незаполненное обязательное поле, повтор одной операции, дублирование данных, отсутствие прав или недоступность внешней системы.
Единого правильного количества сценариев нет. Простая форма требует другой глубины проверки, чем система с несколькими ролями, платежами и интеграциями. Число тестов должно соответствовать согласованному объему, значимости процесса и последствиям ошибки.
Согласуйте безопасные данные и тестовую среду
До начала проверки определите, где пройдет тест и какие данные можно использовать. Безопаснее всего начинать в тестовой среде с демонстрационными данными или правильно подготовленной выборкой.
Не помещайте пароли, API-ключи или полные данные клиентов в обычную таблицу с замечаниями. Если действие может отправить сообщение, создать бухгалтерский документ, изменить остаток на складе или запустить платеж, заранее проверьте, не приведет ли тест к реальным последствиям.
Запишите:
- адрес или название среды;
- версию приложения, переданную на приемку;
- дату и примерное время теста;
- роль используемой учетной записи;
- обозначение набора тестовых данных;
- активные интеграции и функции, отключенные намеренно.
Это позволит исполнителю воспроизвести проблему. Без этих сведений один сценарий может дать другой результат из-за изменения версии, конфигурации или данных.
Записывайте результаты в одной таблице
Отдельные снимки экрана, отправленные по разным каналам, быстро теряют контекст. Полезнее одна общая таблица, где у каждого важного замечания есть ответственный и решение.
| Поле | Что записать |
|---|---|
| сценарий | короткое название проверяемого процесса |
| роль и данные | пользователь и набор тестовых данных |
| ожидаемый результат | результат из согласованного объема |
| фактический результат | что произошло во время теста |
| статус | пройдено, не пройдено, заблокировано или требует уточнения |
| подтверждение | снимок, сообщение, идентификатор операции или краткое описание |
| решение | исправление, дополнение данных, изменение конфигурации или отдельная новая потребность |
Таблица упорядочивает общение, но не заменяет технические тесты исполнителя. Это также не полный аудит безопасности или производительности. Если эти области влияют на приемку, для них нужен отдельный объем и критерии.
Разделите ошибку, препятствие и новую потребность
Больше всего недоразумений возникает, когда все замечания попадают в один список как «ошибки». Четыре вида замечаний требуют разных решений.
| Вид замечания | Что означает | Типичный следующий шаг |
|---|---|---|
| несоответствие объему | согласованный сценарий не дает записанного результата | исполнитель анализирует и исправляет элемент согласно договоренности |
| препятствие для теста | нет доступа, данных, конфигурации или зависимой услуги | ответственная сторона устраняет препятствие, после чего тест повторяется |
| неясная договоренность | стороны по-разному понимают ожидаемый результат | стороны возвращаются к решениям, примерам и записанным предположениям |
| новая потребность | ожидаемое поведение не входило в согласованный этап | отдельно принимается решение об объеме, сроке и оценке |
Не каждое замечание пользователя является ошибкой. Но это не значит, что его можно игнорировать. Каждое важное замечание должно получить классификацию, ответ и следующий шаг.
Проверьте роли, права и исключения
Основного хода процесса недостаточно, если у приложения несколько групп пользователей или оно выполняет действия с важными последствиями. Во время приемки проверьте хотя бы ключевые границы:
- видит ли пользователь только данные, предназначенные для его роли;
- блокирует ли система запрещенную операцию, а не только скрывает ее в меню;
- приводят ли ошибочные или неполные данные к понятному сообщению;
- остается ли система после ошибки в безопасном и понятном состоянии;
- не создает ли повтор операции неконтролируемый дубликат;
- известно ли, что произойдет при отсутствии ответа внешней интеграции.
Такая проверка не заменяет аудит безопасности веб-приложения. Она лишь показывает, соответствует ли основной процесс согласованному объему и не открывает ли очевидные действия неподходящей роли. Техническая проверка безопасности должна учитывать тип данных и последствия ошибки.
Пример одного сценария приемки
Предположим, этап должен позволять создавать рабочее задание на основании подтвержденного заказа. Это условный пример, а не описание готового продукта или проекта конкретного клиента.
| Элемент | Пример договоренности |
|---|---|
| роль | уполномоченный сотрудник отдела обслуживания |
| начальное состояние | подтвержденный заказ с полными данными |
| действие | создание рабочего задания из заказа |
| ожидаемый результат | задание получает номер, правильные данные и согласованный статус |
| повтор | повторное действие не создает неконтролируемый дубликат |
| исключение | отсутствие обязательного поля показывает понятное сообщение и не оставляет неполную запись |
Такое описание позволяет проверить результат без обсуждения реализации. Если тест не пройдет, будет понятно, относится ли проблема к основному результату, повтору операции или обработке отсутствующих данных.
Принимайте большой проект по этапам
Если отложить все тесты до конца проекта, придется одновременно разбираться со множеством неизвестных. При большом объеме лучше принимать отдельные области тогда, когда они достаточно стабильны для надежной проверки.
Перед следующим раундом:
- закройте прежние замечания или укажите их текущий статус;
- выберите одну версию приложения для тестирования;
- повторите исправленный сценарий;
- снова проверьте важные соседние действия, которые могло затронуть изменение;
- перенесите новые идеи в отдельный список дальнейшего развития.
Мы не навязываем одну методику всем проектам. Способ приемки должен соответствовать объему, риску и организации работы клиента. В нашей работе мы отделяем согласованный результат этапа от последующих идей, чтобы обе стороны принимали решение по одному и тому же списку.
После тестирования примите одно ясное решение
Список замечаний еще не является решением. По завершении раунда приемки нужно явно выбрать один из трех результатов.
Принято
Согласованные критерии выполнены. Остальные идеи или функции, исключенные из этапа, переходят в дальнейшее развитие.
Принято с условиями
Остались точно описанные элементы, которые не мешают согласованному использованию. У каждого есть ответственный, срок или определенный следующий шаг. Такая возможность должна следовать из договоренности сторон, а не возникать автоматически.
Переданный объем не принят
Важный согласованный сценарий не работает или его нельзя надежно проверить. Вместо общего утверждения, что «приложение не готово», нужно указать конкретный результат, данные и условие повторного теста.
Значение приемки для оплаты и договора зависит от конкретных условий сотрудничества. Этот материал не является юридической консультацией или шаблоном акта приемки.
До запуска проверьте готовность к эксплуатации
Принятый объем не всегда готов к безопасному запуску. До развертывания согласуйте:
- кто и когда выполняет запуск;
- есть ли актуальная резервная копия и практичный способ отката;
- кто предоставляет недостающие настройки, учетные записи и доступы;
- какие важные операции будут наблюдаться после запуска;
- кто принимает решение со стороны клиента и исполнителя при проблеме;
- куда и в какие часы сообщать о срочных проблемах.
Сроки реакции, часы поддержки и дополнительная готовность становятся обязательством только после записи в предложении или договоре. Разделение этих обязанностей описано на странице сопровождения приложений и интернет-магазинов.
Организуйте передачу результата этапа
До завершения работ подтвердите, что компания получает кроме доступа к работающему приложению. В зависимости от проекта это могут быть:
- доступ к приложению, репозиторию и нужным учетным записям;
- инструкции для пользователей или администратора;
- сведения о зависимостях, лицензиях и внешних услугах;
- известные ограничения и решения, отложенные на будущее;
- согласованные сведения о резервных копиях, запуске и сопровождении;
- результаты приемки и список дальнейших идей.
Если приемка связана со сменой исполнителя или получением всей системы, используйте чек-лист передачи приложения. Он помогает проверить код, данные, учетные записи, инфраструктуру и документацию. Введенная информация не отправляется автоматически.
Часто задаваемые вопросы
Кто должен принимать приложение со стороны компании?
Человек, который знает проверяемый процесс и может подтвердить ожидаемый результат. Для важной системы стоит объединить знания пользователя процесса с решением человека, отвечающего за объем. Исполнитель не должен быть единственной стороной, подтверждающей собственную работу.
Можно ли провести приемку без технических знаний?
Да, если сценарии описывают задачи пользователя, данные и ожидаемый результат. Нетехнический специалист может проверить бизнес-процесс. Тесты кода, безопасности, производительности и инфраструктуры требуют отдельного технического объема.
Что делать, если критерии приемки не были записаны заранее?
Перед тестированием соберите подтвержденные договоренности, примеры и исключения. Затем вместе опишите сценарии, вытекающие из согласованного объема. Если возник спор, не скрывайте его за новым критерием. Отметьте пункт как требующий уточнения.
Чем ошибка отличается от новой функции?
Ошибка или несоответствие возникает, когда согласованное поведение не работает в рамках объема. Новая функция расширяет или изменяет этот объем. Для определения границы может потребоваться вернуться к предложению, одобренным изменениям и примерам из планирования.
Каждое замечание блокирует приемку этапа?
Нет. Значение замечания зависит от согласованного результата и влияния на использование. Существенное несоответствие в основном процессе может блокировать приемку. Небольшой пункт можно обработать по согласованной процедуре приемки с условиями.
Заменяют ли пользовательские тесты тесты исполнителя?
Нет. Пользовательская приемка в первую очередь подтверждает процесс с точки зрения компании. Исполнитель по-прежнему отвечает за согласованные технические тесты. При повышенном риске безопасности или производительности могут потребоваться отдельные аудиты.
Нужно ли тестировать приложение на реальных данных?
Не всегда. Сначала используйте демонстрационные данные или правильно подготовленную выборку. Реальные данные могут понадобиться при контролируемой миграции или в особом случае, но их объем, доступ и защита должны быть согласованы заранее.
Что нужно передать после приемки?
Это зависит от объема. Подтвердите доступ к приложению и согласованным материалам, результаты приемки, известные ограничения, внешние услуги и сведения для запуска и дальнейшего сопровождения.
Согласуйте приемку до начала следующего этапа
Если вы планируете новое приложение или развитие существующей системы, посмотрите услуги Domin Software по разработке на PHP и Laravel. В рамках первого этапа мы определяем проблему, результат, необходимые данные и способ проверки выполненной работы. Большой или пока неясный проект можно сначала упорядочить с помощью бизнес-анализа и определения MVP.
Для первого разговора подготовьте описание текущего процесса, пользователей, важных данных и результата, который должен работать после первого этапа. Не отправляйте пароли, ключи или клиентскую базу. После изучения описания мы укажем, каких сведений не хватает для определения объема и оценки.
Источники
- OWASP Application Security Verification Standard, OWASP, стабильная версия 5.0.0 опубликована 30.05.2025, доступ проверен 30.10.2026.
- NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1, National Institute of Standards and Technology, опубликовано в феврале 2022 года, доступ проверен 30.10.2026.