Версия программного продукта: как связать испытания с текущей сборкой

В заявке на включение программного продукта в реестр название обычно выглядит самым понятным реквизитом. Но для технической экспертизы одного названия мало. Оно не отвечает на главный вопрос: какую именно сборку описывают документы и можно ли воспроизвести её свойства после обновления.

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

Коммерческое название не идентифицирует сборку

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

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

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

Протокол испытаний действует в пределах своего объекта

Лаборатория проверяет конкретный образец по согласованной программе. В протоколе должны быть признаки, которые связывают результат с этим образцом. Если после испытаний заменили критичный модуль, изменили алгоритм расчёта или собрали продукт с другим набором зависимостей, старый протокол нельзя автоматически считать подтверждением новой сборки.

Не каждое изменение требует полного повторения всех тестов. Исправление текста в справке и замена вычислительного компонента несут разный риск. Нужна классификация изменений: что затронуто, влияет ли правка на проверявшиеся свойства и достаточно ли выборочного контроля. Само решение и его обоснование лучше сохранить в журнале версий.

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

Почему у одного продукта могут быть разные допустимые конфигурации

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

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

Одинаковое коммерческое название не всегда означает одинаковую конфигурацию. В документах нужно фиксировать профиль и версию.

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

Что должно совпадать в комплекте документов

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

Практический чек-лист выглядит так:

• в заявлении и техническом описании указана одна редакция продукта;
• дистрибутив имеет уникальный номер версии или контрольную сумму;
• протокол называет тот же объект и перечисляет проверенные компоненты;
• руководство пользователя соответствует интерфейсу переданной сборки;
• журнал изменений объясняет переход от испытанной версии к текущей;
• для нескольких конфигураций есть таблица отличий и область применения каждой;
• даты документов складываются в последовательную историю, а не противоречат друг другу.

Часть расхождений кажется несущественной: дефис в названии, сокращённое обозначение редакции, старый скриншот. Но несколько таких мелочей вместе мешают установить объект проверки. Лучше заранее выбрать одно полное наименование и использовать его во всём комплекте.

Источник, дата и уровень подтверждения

Версия без источника тоже мало что доказывает. Номер можно увидеть в интерфейсе, получить из манифеста, взять из письма разработчика или прочитать в протоколе. Эти источники неравноценны. Для воспроизводимой проверки нужно сохранить, откуда получено каждое значение и когда оно было актуально.

Удобный принцип показан в методологии RTP Index. Там число, опубликованное оператором, наблюдение в демо-режиме, сообщение пользователя и значение из спецификации провайдера относятся к разным уровням достоверности. Новое наблюдение не стирает старое, а добавляется с датой. Для технического досье логика та же: первичный документ отделяют от наблюдения и не выдают предположение за подтверждённый факт.

Источник и дата превращают значение в проверяемую запись. Без них версия или параметр остаются утверждением без контекста.

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

Как описывать обновления после испытаний

После каждого релиза разработчик отвечает на три вопроса. Изменилась ли функция, которую проверяла лаборатория? Затронут ли модуль, входивший в объект испытаний? Можно ли подтвердить отсутствие влияния существующими тестами? Ответы определяют дальнейшие действия.

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

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

Чего не доказывает одна запись в реестре

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

То же относится к сертификату или протоколу испытаний. Документ нельзя распространять на все продукты разработчика только из-за общего бренда. Сначала сверяют объект, версию, дату и область проверки. Если этих реквизитов нет в открытой части документа, корректная формулировка будет осторожной: подтверждение для текущей сборки не установлено.

Как подготовить доказательную цепочку до подачи

1. Зафиксируйте точное название, редакцию и номер текущей сборки.
2. Составьте перечень компонентов, которые входят в поставку.
3. Свяжите протоколы и иные подтверждения с конкретными версиями.
4. Опишите изменения после испытаний и оцените их влияние.
5. Проверьте совпадение реквизитов во всех документах.
6. Сохраните источники, даты и ответственных за каждую запись.

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