🟩 Компьютерно-техническая экспертиза мобильных приложений: методология оценки качества и спорные аспекты разработки

В современном мире мобильные приложения стали неотъемлемой частью бизнес-процессов, банковского обслуживания, логистики, медицины и повседневной жизни. Однако вместе с ростом их значимости увеличилось и число споров между заказчиками, разработчиками и конечными пользователями. Неработающие кнопки, потеря данных, некорректная синхронизация, необоснованное потребление ресурсов — всё это становится предметом судебных разбирательств. Компьютерно-техническая экспертиза мобильных приложений представляет собой системное научно-обоснованное исследование, направленное на установление фактов соответствия или несоответствия программного продукта заявленным требованиям, выявление дефектов и определение причин их возникновения. Союз «Федерация судебных экспертов» объединяет специалистов, владеющих методологией анализа мобильных приложений на платформах ANDROID и IOS, способных дать объективное заключение о качестве разработки, производительности, безопасности и надёжности. В данной статье мы подробно рассмотрим методологические подходы, классификацию дефектов, инструментарий эксперта и три реальных кейса из практики. 🧬📱⚖️🔬

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

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

📱 Работа в условиях ограниченных ресурсов (ОЗУ, аккумулятор, процессор);
🔄 Прерывание жизненного цикла (сворачивание, переход в фон, уничтожение системы);
🌐 Зависимость от сетевого соединения и качества сигнала;
🔐 Строгие ограничения безопасности (песочница, разрешения);
📲 Разнообразие устройств (модели, версии ОС, диагонали экранов).

Объектами экспертизы выступают:

Исходные коды приложения (JAVA, KOTLIN, SWIFT, OBJECTIVE-C) или скомпилированные бинарные файлы (APK, IPA, AAB);
Техническая и проектная документация (техническое задание, спецификации API, архитектурные схемы);
Серверная часть (логи доступа, базы данных, API-эндпоинты);
Устройства для тестирования (смартфоны, планшеты, эмуляторы);
Логи работы приложения (Android Logcat, iOS Console, Crashlytics, Firebase);
Сетевой трафик (дампы PCAP, логи прокси).

Каждый из этих объектов требует применения специфических методов исследования, что делает экспертизу комплексной и наукоёмкой. 🗂️🔍

Глава 2: Классификация дефектов и критерии качества 📊

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

По критичности:

🚨Критические (блокирующие): приложение вылетает (CRASH), не запускается, «зависает» намертво (ANR — Application Not Responding), теряет данные пользователя, допускает несанкционированный доступ. Такие дефекты делают приложение непригодным к использованию.
⚠️Значительные: функциональность работает некорректно (неправильный расчёт, отображение чужих данных, потеря части информации), но приложение не падает полностью.
🔧Незначительные: опечатки в интерфейсе, неверное выравнивание элементов, редкие вылеты при специфических действиях.
💡Рекомендательные: не влияют на работу, но снижают удобство (например, отсутствие тёмной темы, если она не была обещана).

По происхождению:

🧬Логические ошибки: неправильные алгоритмы, неверные условия, ошибки в расчётах.
🔗Ошибки взаимодействия: некорректная работа с API (неправильные параметры, необработанные HTTP-статусы), проблемы с синхронизацией.
🖥️ Платформенные ошибки:зависимость от конкретной версии ОС, модели устройства, разрешений.
🧩Ресурсные ошибки: утечки памяти (MEMORY LEAKS), неоптимальные запросы к БД, избыточное потребление батареи.
🔐Ошибки безопасности: передача данных по HTTP, хранение паролей в открытом виде, отсутствие проверки сертификатов.

Критерии качества, на которые опирается эксперт, включают: функциональную полноту (соответствие ТЗ), стабильность (отсутствие крашей), производительность (время отклика, потребление ресурсов), безопасность, удобство использования (юзабилити) и совместимость с заявленными устройствами. 📏✅

Глава 3: Методологическая основа — от общих принципов к частным методикам 📐

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

Анализ представленных материалов:изучение технического задания, проектной документации, исходных кодов (при наличии), протоколов изъятия устройств.
Формирование гипотез о возможных дефектах:на основе жалоб заказчика или пользователей, а также типовых ошибок для данной платформы.
Выбор инструментария и среды тестирования:подбор физических устройств (разные версии ОС, производители) и эмуляторов.
Статический анализ:исследование исходного кода или декомпилированного бинарного файла без запуска приложения.
Динамический анализ:запуск приложения, выполнение сценариев, мониторинг поведения, сбор логов, перехват трафика.
Нагрузочное тестирование (при необходимости):имитация большого количества пользователей или объёмов данных.
Документирование результатов:фиксация каждого дефекта с фото/видео, логами, скриншотами, временными метками.
Формулирование выводов:ответы на поставленные судом или сторонами вопросы.

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

Глава 4: Инструментарий эксперта — обзор технических средств 🛠️

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

Для статического анализа (ANDROID):

JADX — декомпиляция DEX-файлов в читаемый JAVA-код;
APKTOOL — распаковка ресурсов и манифеста;
BYTECODE VIEWER — визуализация байт-кода;
MOBSF (Mobile Security Framework) — автоматизированный анализ уязвимостей.

Для статического анализа (IOS):

IDA PRO / GHIDRA — дизассемблирование и декомпиляция Mach-O-файлов;
HOOPER — анализ Objective-C и Swift;
CLASS-DUMP — извлечение заголовков классов.

Для динамического анализа:

FRIDA — инструмент для инъекции JavaScript в рантайм (перехват функций, обход проверок);
OBJECTION — надстройка над FRIDA для быстрого динамического анализа;
CHARLES PROXY, BURP SUITE — перехват и модификация сетевого трафика, подмена SSL-сертификатов;
ADB (Android Debug Bridge) — доступ к логам (LOGCAT), файловой системе, установка приложений;
XCODE + INSTRUMENTS — профилирование iOS-приложений (память, CPU, сеть).

Для анализа производительности:

ANDROID STUDIO PROFILER (CPU, Memory, Network, Energy);
PERFETTO — системные трейсы для Android;
GAPID (Graphics API Debugger) — для анализа графики и игр.

Аппаратное обеспечение:

Набор физических устройств (Samsung, Xiaomi, Google Pixel, iPhone разных поколений);
Write-blocker для изъятия образов памяти (по необходимости);
Стенды для захвата сетевого трафика.

Важно, что каждый инструмент должен быть задокументирован (указана версия, источник получения, параметры запуска), чтобы обеспечить воспроизводимость. 🧰🔧

Глава 5: Анализ соответствия техническому заданию — пошаговая методика 📋

Техническое задание (ТЗ) является основным документом, определяющим требования к приложению. Эксперт проверяет соответствие следующим категориям:

Функциональные требования:

Все ли экраны, кнопки и переходы реализованы согласно спецификации;
Корректность алгоритмов (например, расчёт доставки, скидки, рейтинга);
Наличие офлайн-режима (если заявлен);
Работоспособность форм и валидация ввода.

Нефункциональные требования:

Время запуска приложения (должно быть не более N секунд);
Потребление оперативной памяти (не более N МБ в типовом сценарии);
Совместимость с заявленными версиями ОС и моделями устройств.

Требования к интеграции:

Корректная работа с API (обработка ошибок 4xx, 5xx, таймауты);
Синхронизация данных между устройствами (если предусмотрено);
Работа push-уведомлений.

Требования к безопасности:

Использование HTTPS (не HTTP);
Отсутствие хранения чувствительных данных в открытом виде;
Проверка подлинности сервера (SSL PINNING).

Если ТЗ составлено нечётко («удобный интерфейс», «быстрая работа»), эксперт не может признать это несоответствием. Однако он может зафиксировать объективные измеримые показатели (например, время отклика 5 секунд) и указать, что это является дефектом качества, если подобные метрики косвенно вытекают из рыночных стандартов (обычно для данного класса приложений). 🎯📑

Глава 6: Кейс №1 — Торговое приложение с некорректным списанием бонусов 🛍️

Ситуация: Крупная розничная сеть заказала разработку мобильного приложения для лояльности клиентов. По ТЗ, при каждой покупке должно начисляться 5% бонусами от суммы чека, а списание бонусов должно происходить в размере 1 бонус = 1 рубль. Однако после релиза пользователи массово жаловались: бонусы начислялись не всегда, а при списании вместо 100 бонусов списывалось 120. Заказчик потребовал от разработчика исправить ошибку, но тот утверждал, что «всё работает по формуле». Сумма претензии — перерасход бонусов за три месяца составил 2,3 млн рублей. 💰📉

Действия эксперта «Федерации»:

Эксперт провёл комплексное исследование:

Статический анализ исходных кодов (KOTLIN):В классе BonusCalculator он нашёл функцию calculateBonus(purchaseAmount), где вместо purchaseAmount * 0.05 использовалось purchaseAmount * 0.05 / 1.2 (непонятный делитель). При списании в функции redeemBonus(bonusAmount) вместо bonusAmount * 1 было bonusAmount * 1.2.
Динамическое тестирование:Эксперт выполнил покупку на 1000 рублей — начислилось 41,67 бонуса (должно быть 50). Попытался списать 100 бонусов — списалось 120 рублей, баланс ушёл в минус.
Анализ логов сервера:В POST-запросах к API /api/v1/bonus/accrue передавались неверные значения. Эксперт проверил, что серверная логика была верной — ошибка была именно в мобильном приложении.
Сравнение с ТЗ:В техническом задании чётко прописаны формулы начисления и списания. Эксперт зафиксировал несоответствие по пункту 4.2.3 и 4.2.4.

Результат: Суд признал, что приложение не соответствует ТЗ, разработчик обязан выплатить убытки в размере 2,3 млн рублей и переделать приложение за свой счёт. Компьютерно-техническая экспертиза мобильных приложений выявила ошибку на уровне одной строчки кода, но с серьёзными финансовыми последствиями. 💸⚖️

Глава 7: Анализ производительности и потребления ресурсов ⚡

Одной из частых причин споров является низкая производительность приложения: оно тормозит, «жрёт» батарею, перегревает телефон. Эксперт оценивает:

Потребление CPU:

В рабочем профиле (прокрутка списка, анимация) — не выше 30–40% на среднестатистическом устройстве;
В фоновом режиме — не выше 1–2% (если не идёт синхронизация).

Потребление оперативной памяти (RAM):

Типичное приложение не должно превышать 200–300 МБ на современных устройствах;
Утечки памяти (MEMORY LEAKS) выявляются через повторяющиеся действия: открыть/закрыть экран — память не возвращается.

Энергопотребление (BATTERY DRAIN):

Измеряется через встроенные профилировщики (Android Battery Historian, iOS Energy Log);
Аномально высокое потребление в фоне из-за WAKE LOCKS, частых сетевых опросов, некорректной работы GPS.

Время отклика:

Запуск приложения — не более 2–3 секунд (COLD START);
Переход между экранами — не более 0,5–1 секунды;
Сетевые запросы — зависит от скорости соединения, но UI не должен блокироваться (отсутствие ANR).

Эксперт фиксирует метрики с помощью скриншотов из профилировщика и предоставляет суду объективные данные. Например: «При прокрутке списка из 200 элементов частота кадров (FPS) падает до 15, что субъективно воспринимается как “тормоза”. Дефект классифицируется как значительный, поскольку влияет на пользовательский опыт». 📉🔋

Глава 8: Кейс №2 — Логистическое приложение с потерей заказов в офлайне 🚚

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

Действия эксперта «Федерации»:

Изучение архитектуры:В коде приложения (JAVA, ANDROID) эксперт обнаружил, что для сохранения данных использовалась библиотека ROOM (SQLite), но все операции записи выполнялись в UI-потоке. При обрыве сети система убивала приложение из-за ANR (Application Not Responding).
Динамическое тестирование в эмуляторе с отключением сети:При попытке создать заказ в офлайне приложение падало с SQLiteConstraintException (нарушение целостности внешнего ключа), поскольку не были выполнены предусловия.
Анализ очереди синхронизации:В ТЗ был пункт о фоновом сервисе WorkManager, но в коде он отсутствовал вообще. Вместо этого синхронизация пыталась выполняться сразу при восстановлении сети в том же UI-потоке, что приводило к подвисаниям.
Сравнение с ТЗ:Эксперт построчно сопоставил раздел «Офлайн-режим» (п. 5.1–5.7) с реализованным функционалом. Несоответствия по всем семи пунктам.

Результат: Суд удовлетворил иск заказчика. Разработчик не только выплатил 1,1 млн рублей убытков, но и был обязан за свой счёт переписать приложение с правильной архитектурой (MVVM, Repository, WorkManager). Компьютерно-техническая экспертиза мобильных приложений показала, что грубые архитектурные ошибки привели к полной неработоспособности ключевой функции. 🚛⚖️

Глава 9: Безопасность мобильных приложений — скрытые угрозы 🔒

В эпоху утечек персональных данных и киберпреступлений безопасность становится одним из ключевых критериев качества. Эксперт проверяет:

Хранение данных на устройстве:

🔐 Пароли, токены, номера карт, паспортные данные не должны храниться в открытом виде. Использование SharedPreferencesбез шифрования — это дефект. Должен применяться EncryptedSharedPreferences (ANDROID) или Keychain (iOS).
🗄️ Базы данных SQLite — должны быть зашифрованы (SQLCipher) или данные в них обезличены.

Сетевые взаимодействия:

🌐 Все запросы должны идти по HTTPS, а не HTTP. Эксперт проверяет через перехват трафика (CHARLES PROXY, BURP SUITE), возможно ли подменить сертификат (проверка SSL PINNING).
📡 Запрещена передача токенов в GET-параметрах (остаются в логах прокси, истории браузера).

Код и логи:

📜 В логах приложения (Logcat, NSLog) не должно быть конфиденциальной информации. Эксперт ищет следы логирования паролей, токенов.
🧩 Запрещено хранение секретов (API-ключей) в коде в открытом виде. Они должны быть в зашифрованном виде или на сервере.

Бинарная защита:

🛡️ Приложение не должно быть легко декомпилируемым. Эксперт проверяет наличие обфускации кода (PROGUARD, R8 для ANDROID; OBFUSCATOR для iOS). Отсутствие обфускации — не критический, но значительный недостаток.

Если экспертиза выявляет хотя бы один из перечисленных дефектов, в заключении делается вывод о несоответствии приложения современным требованиям безопасности, что может стать основанием для расторжения договора или снижения стоимости. 🔐⚠️

Глава 10: Кейс №3 — Медицинское приложение с утечкой данных пациентов 🏥

Ситуация: Клиника заказала приложение для записи к врачу и доступа к электронным медицинским картам. Разработчик сдал проект. Через месяц после запуска хакеры выложили в открытый доступ базу данных с ФИО, датами рождения, диагнозами и телефонами 50 000 пациентов. Клинике грозил штраф до 6 млн рублей по 152-ФЗ («О персональных данных»). Экспертиза должна была установить, виноват ли разработчик в утечке. 🏥💊

Действия эксперта «Федерации»:

Статический анализ APK:Эксперт декомпилировал приложение и обнаружил, что в коде API_KEY и SECRET_TOKEN хранятся в виде строковых констант в открытом виде.
Динамический анализ трафика:Приложение отправляло запросы к серверу по HTTP (не HTTPS). В теле запроса передавался patient_id и diagnosis в открытом виде. Перехват трафика через общедоступный Wi-Fi позволял любому злоумышленнику читать чужие диагнозы.
Анализ локального хранилища:В SharedPreferences эксперт нашёл файл xml, где логин и пароль хранились в BASE64 (легко декодируется, это не шифрование).
Сравнение с ТЗ:В техническом задании был отдельный раздел «Требования к защите персональных данных» (п. 8). В нём прямо указывалось: «использовать HTTPS, шифрование хранимых данных, обфускацию кода». Ни одно из требований не было выполнено.

Результат: Эксперт сделал вывод, что утечка данных стала возможна исключительно из-за грубых нарушений разработчиком требований безопасности. Суд обязал разработчика выплатить штраф клиники (6 млн рублей) и компенсировать моральный вред пациентам (ещё 2 млн рублей). Компьютерно-техническая экспертиза мобильных приложений помогла установить причинно-следственную связь между дефектами кода и реальным ущербом. 🔓⚖️

Глава 11: Жизненный цикл приложения и фоновые процессы 🔄

Одной из частых проблем мобильных приложений является некорректное поведение при сворачивании, блокировке экрана или переходе в фоновый режим. Эксперт проверяет:

📱Сохранение состояния: При сворачивании и последующем разворачивании приложение должно сохранять введённые данные (текст в полях, позицию списка). Если нет — это дефект (если только в ТЗ не сказано иное).
🔄Фоновые задачи: Синхронизация, загрузка файлов, геолокация должны корректно работать через WorkManager (ANDROID) или BackgroundTasks (iOS), не убивая систему и не расходуя батарею.
⚡Обработка нехватки памяти: При уничтожении приложения системой (из-за нехватки RAM) оно должно восстанавливать состояние через onSaveInstanceState / StateRestorationPolicy. Если этого нет — потеря данных неизбежна.

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

Глава 12: Анализ сетевого взаимодействия — качество API-интеграции 🌐

Приложение редко существует само по себе — оно общается с сервером через API. Некачественная интеграция — источник массы проблем. Эксперт исследует:

🔄Обработка ошибок: Что происходит, если сервер вернул 400 (Bad Request), 401 (Unauthorized), 403 (Forbidden), 500 (Internal Server Error), 503 (Service Unavailable)? Приложение должно показывать понятное сообщение, а не «падать» или «зависать».
⏱️Таймауты: Если сервер не отвечает 30 секунд, приложение не должно висеть вечно. Должен быть таймаут (10–30 секунд) и обработка ошибки.
📦Кэширование: Повторные запросы к одному и тому же ресурсу (например, список городов) не должны каждый раз ходить на сервер. Должен быть кэш с адекватным временем жизни (TTL).
🔁Ретранзакции (повторные попытки): При временных сбоях сети приложение должно автоматически повторить запрос (с экспоненциальной задержкой), а не сообщать об ошибке сразу.

Эксперт проверяет эти аспекты с помощью перехвата трафика и симуляции ошибок сервера (через MOCK-сервер или настройки прокси). Например, он может подменить ответ сервера на код 500 и посмотреть, не упадёт ли приложение. 📡🔍

Глава 13: Кроссплатформенные приложения — особенности экспертизы 🧩

React Native, Flutter, Xamarin, Cordova — всё это популярные фреймворки для создания приложений под ANDROID и iOS из одного кода. Однако у них есть особенности, которые эксперт должен учитывать:

Размер приложения:APK/IPA весят больше из-за встроенного рантайма (Flutter Engine, React Native Bridge). Если заказчик не предупреждён — это может быть претензией.
Производительность:Анимация на сложных экранах может «тормозить» из-за работы через мост (JavaScript ↔ Native). Эксперт должен измерить FPS и сравнить с нативным эталоном.
Нативные модули:Если приложение использует камеру, Bluetooth, NFC, геолокацию — эти модули пишутся на нативном коде (JAVA/Kotlin, Swift/Objective-C). Ошибки в них могут быть критическими.
Сторонние библиотеки:В кроссплатформенных приложениях часто много зависимостей. Устаревшие или конфликтующие библиотеки могут вызывать краши.

В одном из споров эксперт обнаружил, что приложение на React Native падает на ANDROID 11+ при открытии камеры из-за того, что используемая библиотека react-native-camera не обновлялась два года. Разработчик не проверил совместимость — это было признано его виной. 📱💥

Глава 14: Документирование дефектов — как фиксировать для суда 📸

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

Описание шагов воспроизведения (STR — Steps to Reproduce):
- Установить приложение версии 1.2.3 на устройство Samsung Galaxy S21, Android 12.
- Открыть экран «Профиль», нажать «Редактировать».
- Ввести в поле «Телефон» 10 цифр, нажать «Сохранить».
- Наблюдать вылет приложения (CRASH).
Скриншоты или видео:Обязательно с временными метками (таймер на экране, лог).
Логи:Выдержки из Logcat (ANDROID) или Console (iOS) с указанием исключения (Exception).
Сетевой дамп (при необходимости):Запрос и ответ сервера (PCAP-файл, скриншот из Charles Proxy).
Классификация:Критический / значительный / незначительный, с обоснованием.

Все материалы включаются в заключение и приложения к нему. Судья, не будучи айтишником, должен понять суть проблемы, даже если он не читал логи. Поэтому эксперт даёт краткое резюме: «При вводе номера телефона без кода страны приложение падает, что делает невозможным регистрацию пользователей. Дефект критический». 🖼️📝

Глава 15: Заключение — роль экспертизы в разрешении споров 🎯

Компьютерно-техническая экспертиза мобильных приложений является незаменимым инструментом для установления объективной истины в спорах между заказчиками, разработчиками и пользователями. Она позволяет:

🔬 Объективно оценить качество программного продукта на основе научно обоснованных методов;
🧩 Выявить дефекты, их причины и степень критичности;
⚖️ Предоставить суду воспроизводимые доказательства (логи, скриншоты, дампы трафика);
💰 Рассчитать финансовые последствия (убытки, неосновательное обогащение, штрафы);
🛡️ Защитить права добросовестных разработчиков, если претензии необоснованны.

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

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

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

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

Ознакомиться с перечнем услуг и заказать исследование можно на официальном сайте: https://krimexpert.ru/ekspertiza-kachestva-razrabotki-mobilnyh-prilozhenij/

Не позволяйте багам и недобросовестным разработчикам разрушать ваш бизнес. Пусть эксперты разберутся, где техническая ошибка, а где — нарушение обязательств. 🟩📱⚖️🔚