Научная методология оценки качества и выявления дефектов

Введение: от субъективных жалоб к объективным измерениям

Уважаемые коллеги! В современном мире мобильные приложения стали не просто инструментом коммуникации или развлечения, но и критически важным компонентом бизнес-процессов, банковских операций, медицинских услуг и государственных сервисов. Однако практика показывает, что значительная часть разрабатываемых приложений не соответствует заявленным характеристикам, техническому заданию и требованиям нормативных документов. Возникают конфликты между заказчиками и разработчиками, споры о качестве, сроках и стоимости исправлений. Разрешить такие споры на научной основе призвана инженерная экспертиза мобильных приложений  — междисциплинарное исследование, объединяющее методы программной инженерии, теории тестирования, анализа производительности, безопасности и соответствия стандартам. Союз «Федерация судебных экспертов» представляет систематическое изложение методологии, подкреплённое тремя реальными кейсами из практики.

Глава 1. Предмет и объекты инженерной экспертизы мобильных приложений

Предметом экспертизы являются фактические данные о качестве, работоспособности, безопасности и соответствии мобильного приложения требованиям, установленным в техническом задании, договоре, стандартах и нормативных актах. Объектами исследования выступают: исходный код приложения (при наличии), бинарные файлы (IPA для iOS, APK/AAB для Android), серверная часть (API, базы данных, логи), техническая документация, протоколы тестирования, скриншоты, видеозаписи воспроизведения дефектов, а также сами мобильные устройства (как физические, так и эмуляторы). Инженерная экспертиза мобильных приложений рассматривает их в совокупности, позволяя установить причинно-следственные связи между дефектами кода, архитектурными решениями и наблюдаемыми сбоями в работе.

Глава 2. Нормативно-правовая база оценки качества мобильных приложений

В Российской Федерации действует система стандартов, регламентирующих качество программного обеспечения. Ключевыми являются:
📌 ГОСТ Р ИСО/МЭК 25010-2017 «Системная и программная инженерия. Требования к качеству систем и программных продуктов (SQuaRE). Модели качества», который определяет восемь характеристик: функциональная пригодность, надёжность, производительность, удобство использования, безопасность, совместимость, сопровождаемость, переносимость.
📌 ГОСТ Р 58823-2020 «Мобильные приложения. Требования к качеству и показатели», содержащий специфические для мобильных платформ метрики: время запуска, потребление батареи, использование сетевого трафика, размер установочного пакета, реакция на прерывания (звонки, сворачивание).
📌 ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения. Общие требования».
📌 Техническое задание (ТЗ), которое является основным документом, определяющим функциональные и нефункциональные требования к приложению.
Инженерная экспертиза мобильных приложений проверяет соответствие каждому из применимых стандартов и пунктов ТЗ, что обеспечивает юридическую обоснованность выводов.

Глава 3. Классификация дефектов мобильных приложений: таксономия и тяжесть

Для систематизации недостатков используется многоуровневая классификация:
🔹 Критические дефекты (Severity 1): приложение не запускается, постоянно вылетает (crash) на этапе выполнения ключевой функции, происходит потеря данных пользователя, нарушается безопасность (утечка паролей, финансовых данных), работа в фоновом режиме приводит к критическому расходу батареи (более 20% в час).
🔹 Значительные дефекты (Severity 2): отдельные функции работают некорректно (неправильный расчёт суммы, отображение не тех данных), приложение зависает на длительное время (более 10 секунд), пользовательский интерфейс отображается неверно на целевых устройствах, сбой при офлайн-режиме.
🔹 Незначительные дефекты (Severity 3): опечатки, мелкие артефакты интерфейса, некритичные задержки (менее 3 секунд), несоответствие дизайну в неосновных экранах.
🔹 Пожелания (Severity 4): улучшения, не влияющие на функциональность.
Инженерная экспертиза мобильных приложений обязательно классифицирует каждый обнаруженный дефект по тяжести, что позволяет суду или сторонам оценить реальное влияние на бизнес-процессы.

Глава 4. Кейс №1: Финансовое приложение с ошибками округления и потерянными транзакциями

Контекст: Банк «Авангард» (название изменено) заказал разработку мобильного приложения для торговли ценными бумагами. После запуска пользователи стали жаловаться на расхождения в суммах комиссий: приложение показывало 0.5%, а списывало 1.5%. Также периодически исчезали записи о совершённых сделках. Общий ущерб от ошибочных списаний и репутационных потерь составил 12 млн рублей. Разработчик утверждал, что проблема «на стороне бэкенда».
Объекты исследования: исходный код Android-версии (Kotlin), бэкенд-логи, скриншоты пользователей, протоколы тестирования, техническое задание.
Методы:

Статический анализ кода (Android Studio Inspector, SonarQube). Обнаружен класс FeeCalculator, содержащий метод calculateFee(amount), который возвращал значение с типом Double, но при передаче в API выполнялось неявное преобразование в Float с потерей точности. Ошибка округления до 2 знаков давала расхождение до 0.0001%, но на крупных суммах (более 1 млн руб.) это составляло тысячи рублей.

Динамический анализ: на тестовом стенде при совершении 1000 транзакций зафиксировано 47 случаев, когда локальная база данных SQLite не синхронизировалась с сервером из-за отсутствия механизма ретраев (повторных попыток) при временных сбоях сети.

Анализ логов бэкенда: сервер получал все транзакции корректно, но мобильное приложение не обновляло кэш после восстановления соединения.
Выводы эксперта: Критические дефекты (неправильный расчёт комиссии, потеря транзакций) полностью обусловлены ошибками в клиентском коде. Разработчик не выполнил требования ТЗ о «точности финансовых вычислений до 6 знаков после запятой» и «надёжной синхронизации». Инженерная экспертиза мобильных приложений позволила локализовать проблему. Суд обязал разработчика выплатить 12 млн руб. убытков и 3 млн руб. штрафа.

Глава 5. Методология анализа производительности: количественные метрики

Одной из частых жалоб заказчиков является медленная работа приложения. Для объективной оценки производительности применяется система метрик, зафиксированных в стандартах и измеряемых инструментально:
⏱️ Время холодного старта (cold start): интервал от момента нажатия на иконку до полного отображения главного экрана. Норма для приложений среднего размера  — менее 3 секунд на устройствах трехлетней давности. Измеряется через adb shell am start -W для Android и instruments -t «Time Profiler» для iOS.
⏱️ Время горячего старта (warm start): приложение уже было в памяти (запуск из многозадачности). Норма  — менее 1 секунды.
⏱️ Интерфейсная плавность (jank): количество пропущенных кадров за минуту скроллинга. В идеале  — 0 пропусков из 3600 кадров (при 60 FPS). Допустимо  — не более 0.1% пропусков. Измеряется через Android Profiler (Frame Timing) и Xcode Instruments (Core Animation).
⏱️ Потребление оперативной памяти: приложение в типичном сценарии не должно превышать 256 МБ на бюджетных устройствах. Тестируется через Memory Profiler, выявляются утечки (непрерывный рост памяти при повторяющихся действиях).
⏱️ Энергопотребление: приложение в фоне (background) должно потреблять не более 1-2% батареи в час. Для GPS-приложений допустимо до 5-7% при условии предупреждения пользователя. Измеряется через Battery Historian (Android) и Energy Log (iOS).
Инженерная экспертиза мобильных приложений представляет результаты в виде таблиц и графиков, что исключает субъективизм.

Глава 6. Кейс №2: Приложение доставки с критическим расходом батареи (упущенная выгода 15 млн руб.)

Фабула: Сеть пиццерий «Папа Джон» (бренд изменён) заказала приложение для заказа еды с доставкой. В течение первого месяца после запуска 68% пользователей удалили приложение, жалуясь, что смартфон разряжается за 2-3 часа. Разработчик (сторонняя студия) заявил, что «это особенности операционной системы и старых телефонов». Компания потеряла заказы на сумму 15 млн руб. за три месяца.
Исследование:

Лабораторный стенд: пять физических устройств (iPhone 11, 12, 14; Samsung Galaxy S10, Pixel 6) с чистой ОС, установлено только тестируемое приложение.

Замер энергопотребления через Battery Historian (Android) и Energy Diagnostics (iOS). Результат: в фоновом режиме приложение потребляло 18% батареи в час  — в 9 раз выше нормы.

Декомпиляция кода (jadx для Android, Hopper для iOS): обнаружен вызов requestLocationUpdates с параметрами minTime=0, minDistance=0 и приоритетом PRIORITY_HIGH_ACCURACY (GPS). Запрос геолокации происходил непрерывно, даже когда приложение было свёрнуто. В ТЗ было указано: «Определение местоположения только при активном использовании карты, интервал  — не чаще 1 раза в 5 минут».

Анализ разрешений: манифест Android содержал разрешение ACCESS_BACKGROUND_LOCATION, которое в ТЗ не требовалось.

Дополнительный дефект: отсутствовала проверка состояния сети; при потере сигнала приложение каждую секунду пыталось отправить геоданные, создавая циклические запросы.
Заключение: Выявлены критические дефекты (Severity 1)  — нарушение требований к энергопотреблению, необоснованное использование GPS в фоне, отсутствие оптимизации. Инженерная экспертиза мобильных приложений установила прямую причинно-следственную связь между дефектами и оттоком пользователей. Суд взыскал с разработчика 15 млн руб. упущенной выгоды и обязал исправить приложение за свой счёт.

Глава 7. Анализ безопасности мобильных приложений: типовые уязвимости

Согласно OWASP Mobile Top 10 (актуальная версия), наиболее распространённые уязвимости в мобильных приложениях включают:
🔓 Небезопасное хранение данных (M1): пароли, токены, персональные данные сохраняются в SharedPreferences/UserDefaults в открытом виде. Проверяется через чтение файлов приложения на рутированном устройстве или через резервную копию (iTunes/iCloud).
🔓 Небезопасная передача данных (M3): использование HTTP вместо HTTPS, отсутствие проверки сертификата (доверие всем), передача конфиденциальных данных в URL или заголовках. Выявляется через MITM-прокси (Burp Suite, Charles).
🔓 Слабый код аутентификации (M4): проверка пароля на клиенте, хранение пароля в коде, отсутствие биометрической защиты.
🔓 Обратная разработка (reverse engineering) (M9): отсутствие обфускации, незащищённый код легко декомпилируется, что позволяет извлечь API-ключи, алгоритмы шифрования.
Инженерная экспертиза мобильных приложений включает обязательный пентест. В одном из дел мы обнаружили, что финансовое приложение хранило логин и пароль в открытом виде в SharedPreferences. Злоумышленники (сотрудники разработчика) украли учётные данные и вывели 7 млн руб. Экспертиза доказала, что уязвимость была заложена на этапе проектирования. Разработчик выплатил компенсацию в полном объёме.

Глава 8. Кейс №3: Медицинское приложение с потерей данных пациентов и нарушением 152-ФЗ

Обстоятельства: Стартап «МедТех» разработал приложение для врачей и пациентов: хранение истории болезней, рецептов, результатов анализов. Через 2 месяца после запуска пациенты стали жаловаться, что записи исчезают. Врачи не могли получить доступ к новым анализам. Ущерб клиники (потеря времени, пересдача анализов, репутация) оценён в 9 млн руб. Разработчик утверждал, что «пользователи сами удаляют данные».
Методика экспертизы:

Получены APK-файлы, дампы локальной БД SQLite с устройств пациентов (с согласия по решению суда). Исходный код был закрыт, но мы декомпилировали приложение через jadx (Android) и Ghidra (для нативного кода).

В коде класса SyncManager обнаружена функция cleanOldRecords(), которая запускалась каждые 48 часов и выполняла DELETE FROM medical_records WHERE created_at < datetime(‘now’, ‘-2 days’). В ТЗ такого требования не было; наоборот, было указано «хранить историю бессрочно». Это была явная ошибка программиста, скопировавшего код из другого проекта.

Проверка передачи данных: приложение отправляло результаты анализов на сервер через HTTP (не HTTPS). Тело запроса содержало ФИО, адрес, диагноз в открытом виде. С помощью Wireshark и Charles Proxy мы перехватили более 200 записей. Это прямое нарушение Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных».

Восстановление потерянных данных: с помощью анализа нераспределённого пространства SQLite-файлов (через sqlite3_analyzer и ручной парсинг страниц) восстановлено 89% записей, что подтвердило, что удаление было автоматическим, а не по воле пользователей.
Выводы: Критические дефекты (потеря данных, нарушение безопасности ПДн). Инженерная экспертиза мобильных приложений доказала, что разработчик нарушил ТЗ и закон. Суд обязал разработчика выплатить 9 млн руб. убытков, 1.5 млн руб. штрафа в Роскомнадзор и переработать приложение за свой счёт.

Глава 9. Статический анализ исходного кода: инструменты и метрики

При наличии исходного кода (что бывает при судебном споре) эксперт проводит статический анализ  — исследование программы без её фактического выполнения. Используются следующие инструменты:
📊 SonarQube / SonarLint: анализ качества кода (запахи, дублирование, сложность цикломатическая). Норма: не более 5% критических замечаний на 1000 строк.
📊 Android Lint (для Java/Kotlin) и SwiftLint (для Swift): выявление потенциальных багов, проблем производительности, устаревших API.
📊 Detekt (Kotlin статический анализ), PMD, FindBugs.
📊 Анализ покрытия тестами: если разработчик заявлял о тестировании, но покрытие составляет менее 70%  — это снижает качество.
В одном из дел мы обнаружили, что разработчик закомментировал блок обработки ошибок (try-catch), из-за чего приложение вылетало при любом сетевом сбое. Статический анализ показал 47 предупреждений категории «критический». Это стало основанием для признания кода некачественным.

Глава 10. Динамический анализ: нагрузочное и стресс-тестирование

Динамический анализ позволяет выявить дефекты, проявляющиеся только при выполнении кода. Инженерная экспертиза мобильных приложений включает:
📱 Функциональное тестирование по чек-листу (содержит 200–500 пунктов в зависимости от сложности).
📱 Нагрузочное тестирование: эмуляция 50, 100, 500 одновременных пользователей с использованием JMeter + плагины для мобильного трафика, Appium для автоматизации. Замеряем время ответа API, частоту крашей.
📱 Стресс-тестирование: резкое увеличение нагрузки, отключение сети, низкий заряд батареи (1%), недостаток памяти (заполнение диска). Результат: приложение не должно падать, должно корректно обрабатывать ошибки.
📱 Тестирование на совместимость: 20+ реальных устройств с разными версиями ОС (iOS 15-17, Android 10-14). Процент устройств, на которых есть критические баги, не должен превышать 5% от целевой аудитории.
В кейсе с банковским приложением мы обнаружили, что на Android 12 (API 31) приложение падало при попытке сканировать QR-код из-за необновлённого разрешения «MANAGE_EXTERNAL_STORAGE». Разработчик не провёл тестирование на этой версии, хотя она была указана в ТЗ как поддерживаемая.

Глава 11. Анализ сетевого взаимодействия: API, синхронизация, кэширование

Современное мобильное приложение почти всегда взаимодействует с сервером. Типовые дефекты:
🔌 Неверное API-соглашение: приложение ожидает JSON одного формата, а сервер присылает другой (или наоборот). Анализируется через перехват трафика и сравнение с документацией OpenAPI/Swagger.
🔌 Отсутствие ретраев: при временном сбое сети приложение не повторяет запрос, теряет данные. Эксперт проверяет, использует ли код паттерны Retry with Exponential Backoff.
🔌 Неадекватное кэширование: приложение каждый раз загружает одни и те же данные (например, список стран) вместо сохранения на устройство.
🔌 Неэффективные запросы: N+1 проблема  — приложение запрашивает список из 100 элементов, а затем на каждый элемент шлёт отдельный запрос.
Инженерная экспертиза мобильных приложений анализирует все API-вызовы (через логи, дампы трафика), оценивает их количество, объём, частоту. В одном кейсе мы выявили, что приложение отправляло аналитический запрос при каждом нажатии кнопки (200 запросов за сеанс), что создавало нагрузку и приводило к замедлению.

Глава 12. Соответствие ТЗ: сравнительный анализ и методика выявления невыполненных требований

Наиболее частый конфликт: заказчик утверждает, что разработчик не сделал половину функций; разработчик  — что всё реализовано. Эксперт действует следующим образом:
1️⃣ Изучает утверждённое ТЗ (и дополнения к нему). Каждое требование должно быть однозначным, измеримым, тестируемым. Размытые формулировки (например, «приложение должно быть удобным») не рассматриваются.
2️⃣ Составляет матрицу трассировки требований: для каждого требования  — реализовано ли, частично, не реализовано, реализовано с дефектом.
3️⃣ Тестирует каждое требование в изолированной среде. Фиксирует несоответствия, используя скриншоты, видеозаписи, логи.
4️⃣ Если в ТЗ есть количественные показатели (тайминги, количество шагов до действия)  — проверяет их инструментально.
В одном из дел ТЗ требовало «функцию офлайн-режима, при которой пользователь может просматривать последние 50 заказов без интернета». Реально приложение без интернета показывало белый экран. Экспертиза признала требование невыполненным, что повлекло снижение цены контракта на 30%.

Глава 13. Методика экспертного эксперимента: воспроизводимость как критерий истины

Для того чтобы дефект был признан судом, он должен быть воспроизводим. Эксперт составляет детальный протокол эксперимента, включающий:
📋 Описание тестового стенда (модель устройства, версия ОС, версия приложения, сетевое окружение).
📋 Исходное состояние (установлено ли приложение, какие данные в нём).
📋 Пошаговая инструкция: «1. Открыть приложение, 2. Авторизоваться с логином X, 3. Нажать на кнопку „Перевести средства“, 4. Ввести сумму 1000, 5. Нажать „Подтвердить“, 6. Выключить Wi-Fi, 7. Нажать „Повторить“».
📋 Ожидаемый результат (согласно ТЗ) и фактический результат (краш, ошибка в UI, потеря данных).
📋 Повторяемость: эксперимент проводится не менее 3 раз. Если дефект воспроизводится в 100% случаев  — это жёсткий дефект; если в 30%  — периодический, но также фиксируется.
Инженерная экспертиза мобильных приложений прилагает к заключению видеозапись экрана устройства (через скринкаст) и логи. Это делает выводы наглядными и неопровержимыми.

Глава 14. Типовые ошибки разработчиков, выявляемые экспертизой (по материалам 100+ дел)

Анализ нашей практики (более 100 судебных экспертиз) позволяет выделить наиболее частые системные ошибки разработчиков:
❌ Отсутствие обработки ошибок сети: приложение падает или зависает при потере соединения (63% дел).
❌ Утечки памяти: при многократном открытии/закрытии экрана потребление памяти неограниченно растёт (47%).
❌ Неправильная работа с многопоточностью: состояние гонки (race condition) при загрузке данных из разных потоков, что приводит к случайным сбоям (41%).
❌ Жёстко зашитые (хардкод) URL, ключи, пароли в клиентском коде, что позволяет злоумышленникам извлечь их при декомпиляции (35%).
❌ Отсутствие логирования критических событий  — невозможно диагностировать баги в продакшене (52%).
❌ Игнорирование тёмных режимов, различных разрешений экрана, шрифтов  — интерфейс съезжает на некоторых устройствах (38%).
Инженерная экспертиза мобильных приложений выявляет каждую из этих ошибок, количественно оценивает их влияние на качество.

Глава 15. Заключение: роль научной экспертизы в защите прав заказчиков ПО

Цифровизация экономики и повсеместное использование мобильных приложений требуют адекватных механизмов защиты прав заказчиков и пользователей. Субъективные претензии («приложение тормозит», «оно неудобное») не могут служить основанием для юридических решений. Необходима объективная, воспроизводимая, нормативно обоснованная оценка. Эту функцию выполняет инженерная экспертиза мобильных приложений.
Инженерная экспертиза мобильных приложений даёт ответы на вопросы: соответствует ли приложение техническому заданию, имеются ли в нём критические дефекты, являются ли эти дефекты следствием ненадлежащего качества разработки, какова стоимость устранения дефектов и каков размер ущерба от их наличия.
Инженерная экспертиза мобильных приложений  — это мост между миром программирования и миром права, позволяющий судье, не имеющему технического образования, принять обоснованное решение.
Инженерная экспертиза мобильных приложений  — это гарантия того, что недобросовестный разработчик не сможет уйти от ответственности, ссылаясь на «сложности технологии» или «особенности платформы».
И последнее: инженерная экспертиза мобильных приложений в исполнении Союза «Федерация судебных экспертов» базируется на лучших мировых стандартах и многолетней практике.

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

https://krimexpert.ru/ekspertiza-kachestva-razrabotki-mobilnyh-prilozhenij/

Наша методология  — это наука, наши инструменты  — инженерия, наша цель  — истина.