Экспертиза фильтра рассылки в программе лояльности в Москве №104276

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

• Архивная версия программы лояльности на контрольную дату спорной рассылки.
• Рабочая версия программы на даты 2 выездных осмотров в Москве.
• Репозиторий — хранилище исходного кода и записей о его изменениях.
• Серверная среда, в которой была развёрнута проверяемая программа.
• Пользовательское руководство по настройке получателей и информационных рассылок.

Материалы дела описывали спорную операцию и содержали 1 экземпляр руководства для оператора. Этот документ задавал последовательность настройки рассылки и назначение фильтра по номерам карт.

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

Эксперты в области компьютерно-технической экспертизы и информационной безопасности провели работу с 2 выездами на осмотр в Москве. Они получили доступ к архивной и рабочей версиям программы, серверной среде и репозиторию. Доступ к консоли сервера выполняли по протоколу SSH. На каждой площадке эксперты фиксировали интерфейсные действия и состояние доступных программных компонентов снимками экрана.

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

• Тестовые сценарии — ввод номеров строками, с пробелами и дополнительными числовыми значениями.
• Анализ исходного кода — проверка обработки строк и обращения к базе данных.
• История версий — сопоставление записей репозитория с контрольной датой и серверной копией.
• Серверная архитектура — проверка способов размещения кода и фиксации его изменений.

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

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