Что именно мы проверяем — отличия от процессной статьи
Процесс приёмки — извещение комиссии, сроки подписания, виды актов, электронное закрытие в ЕИС — разобран в руководстве «Приёмка ПО: этапы и акты». Эта статья отвечает на вопрос, который остаётся, когда комиссия собрана: чем фактически доказывать, что разработанное ПО — то самое, что заказано. Ответ собирается из трёх контуров: функциональные испытания, нефункциональные проверки, документы и права. Пропуск любого контура превращает акт подписи в акт веры.
Контур 1. Функциональные испытания — каждое требование со сценарием
Основа — ТЗ. Метод: каждое функциональное требование превращается в тестовый сценарий «шаги → ожидаемый результат → факт». ГОСТ 34.603-92 закрепляет виды испытаний автоматизированных систем — предварительные испытания, опытная эксплуатация, приёмочные испытания: предварительные выявляют грубые несоответствия до показа комиссии, опытная эксплуатация проверяет систему в реальной работе пользователей, приёмочные формализуют результат протоколами. Практические правила:
- сценарии готовятся до начала испытаний и согласуются с поставщиком — спор о «правильном» поведении после прогона уже не спор, а позиционная война;
- каждый прогон фиксируется: дата, стенд, версия, результат — протокол испытаний и есть главное доказательство;
- критерий зачёта формулируется числом там, где это возможно (время отклика, доля успешных операций);
- для ИИ-компонентов добавляется проверка на эталонной выборке — порядок и метрики разобраны в экспертизе ИИ-компонентов.
Контур 2. Нефункциональные проверки — где «работает» ≠ «готово»
Система может пройти все функциональные сценарии и быть непригодной: тормозить под реальной нагрузкой, падать при десяти одновременных пользователях, хранить пароли открытым текстом. В проверку включаются:
- производительность: целевые показатели из ТЗ (пользователи, отклики, пропускная способность) проверяются нагрузочным тестированием в контуре, сопоставимом с боевым (как мы делаем это — услуга нагрузочного тестирования);
- информационная безопасность: разграничение ролей, журналирование, работа под целевой класс защищённости; для систем с персональными данными — требования по 152-ФЗ до ввода в эксплуатацию;
- интеграции: обмен со смежными системами заказчика на реальных стендах, а не «у нас в офисе работало»;
- миграция данных: перенос исторических данных с контролем полноты — сличением counts и контрольных сумм.
Контур 3. Документация, код, права
Комплект документации на программное обеспечение описывается стандартами ГОСТ 19 (ЕСПД) и ГОСТ 34 (для автоматизированных систем): руководство пользователя, руководство администратора, описание функций, программы и методики испытаний, формуляры. Проверяется не «стопка бумаг», а соответствие фактическому поведению системы: руководство, в котором кнопки не совпадают с интерфейсом, — несоответствие. Дальше — имущественное: если по контракту исключительные права переходят заказчику, приёмка включает передачу исходного кода (репозиторий, ветки, сборочные инструкции), акт передачи прав и сведения для реестра российского ПО, если система на него ставится. Без этого «своя система» остаётся чужой навсегда.
Кейсы несоответствий (обезличено)
- Кейс «идеальное демо». На показе — отрепетированный сценарий на подготовленных данных. На контрольных сценариях заказчика импорт файлов валится на 30% форматов. Вывод: испытания только на данных и сценариях заказчика, демо — не этап приёмки.
- Кейс «сайт без нагрузки». Сайт-визитка принят по акту; в день публикации на портале учреждения 200 одновременных подключений — ресурс отвечает таймаутами. В ТЗ не было показателей нагрузки — принять претензию нечего. Вывод: нефункциональные требования пишутся до контракта (как — в руководстве по ТЗ).
- Кейс «документация-призрак». Функции работают, документация — скриншоты другой версии. Приёмка остановлена на переоформление; срок контракта сгорел, поставщик получил просрочку. Вывод: комплектность документации — критерий этапа, а не «послепродажная мелочь».
- Кейс «код остался дома». Система эксплуатируется годами у хостинга подрядчика; при смене исполнителя выясняется, что код, сборка и доступы не передавались. Вывод: передача кода и доступов — отдельный этап приёмки с актом, независимо от того, где система физически живёт.
- Кейс «тестовые данные — боевые». При приёмке база наполнена тестовыми записями; после ввода в эксплуатацию выясняется, что чистка не предусмотрена контрактом. Вывод: очистка тестовых данных и подготовка к боевому наполнению — пункт ТЗ и сценарий испытаний.
Роль экспертизы и что делать при несоответствиях
По 44-ФЗ приёмка результатов включает экспертизу (ст. 94, ст. 41): заказчик проводит её своими силами или привлекает внешних экспертов; для отдельных случаев внешняя экспертиза обязательна. Независимый эксперт полезен именно в предметной части: сценарии, прогоны, протоколы — то, что внутренняя комиссия «смотреть умеет, проверять нет». Найдены несоответствия — они фиксируются замечаниями с конкретикой (сценарий, ожидание, факт), исполнителю даётся срок на устранение, повторный прогон закрывается протоколом; уклонение от устранения — путь к одностороннему расторжению и претензионной работе (последствия по штрафам — в разборе неустоек). Гарантийный хвост после подписания акта — тема гарантийных обязательств на ПО, электронное закрытие документов — актирования в ЕИС.
Чек-лист приёмочной проверки ПО
- Каждое требование ТЗ закрыто сценарием; сценарии согласованы до испытаний.
- Прогоны на данных и стендах заказчика; демо не засчитывается.
- Нагрузка и ИБ проверены по показателям ТЗ; протоколы есть.
- Документация соответствует версии системы (ГОСТ 19/34).
- Код, сборка, доступы, права переданы актами, если предусмотрены.
- Тестовые данные очищены; миграция проверена сличением.
- Замечания — письменно, с устранением и повторным прогоном до акта.
Что мы предлагаем
ООО «НЬЮ-ССТ» разработало и приняло не один десяток систем в госконтрактах — и как исполнитель, и как независимый проверяющий. Пришлите ТЗ и результат подрядчика на sales@vyshka.cloud — бесплатно, за 1 рабочий день вернём план проверки: сценарии, показатели, состав документации. Нагрузочные прогоны — услуга нагрузочного тестирования, аудит чужого кода — аудит кода и legacy; что делать, если система уже в эксплуатации и ошибается — ответ «Что делать, если ИИ выдаёт ошибки».