Введение: когда ваше приложение — это фиаско, а разработчик умывает руки

Вы заказали мобильное приложение за несколько миллионов рублей. Разработчик клялся, что «всё будет на высшем уровне», показывал красивые макеты, обещал «быструю доставку, интуиитивный интерфейс, высокую производительность и абсолютную безопасность». 💰 Вы ждали 4, 6, а то и 8 месяцев. Потратили нервы, согласовывали каждый экран, платили по этапам. И вот, наконец, долгожданный релиз. Но вместо работающего бизнес-инструмента вы получаете чудовище, которое: постоянно вылетает (crash), зависает на ровном месте, теряет данные пользователей, сажает батарею за час, а главное — не делает и половины того, что было в техническом задании (ТЗ). 🔥 Вы пишете разработчику претензию. А он вам отвечает: «Это у вас интернет плохой», «Вы не так нажимаете», «Это особенности платформы», «Доплатите, мы исправим». Или хуже — просто исчезает. Знакомо? К сожалению, это типовая ситуация на рынке мобильной разработки. Мошенников и откровенных халтурщиков — масса. Но есть и вполне добросовестные разработчики, которые просто не справились со сложностью проекта. Как отличить одно от другого? Как доказать в суде, что приложение некачественное и разработчик нарушил свои обязательства? Ответ один: инженерная экспертиза мобильных приложений.

Союз «Федерация судебных экспертов» — это команда инженеров, которые умеют заглядывать внутрь чужого кода, находить там «скелеты в шкафу» (костыли, утечки памяти, кривые SQL-запросы, дырявую безопасность) и на научной основе доказывать, что приложение не соответствует заявленному качеству. 🧠 Мы не боимся конфликтовать с недобросовестными разработчиками, давать жёсткие, но обоснованные заключения и отстаивать их в суде. В этой статье мы с инженерной злостью и конфликтной прямотой разберём, какие претензии к качеству мобильных приложений реально обоснованны, как их доказывать, и покажем три кейса, где мы буквально «разнесли» халтурщиков в пух и прах. 🥊

Глава 1. Качество мобильного приложения: что это вообще такое и как его измерить

1.1. Пять столпов качества, которые разработчик обязан соблюдать

Когда вы подписываете договор на разработку, вы ожидаете, что приложение будет:

🔹 Функциональным — выполнять все задачи, прописанные в ТЗ (техническом задании). Если в ТЗ сказано «онлайн-оплата через Apple Pay», а кнопка оплаты просто открывает пустую страницу — это брак.

🔹 Производительным — работать быстро, без тормозов, зависаний и «вечных загрузок». Никто не будет ждать 30 секунд, пока откроется список товаров. Особенно если в ТЗ было «время отклика не более 2 секунд».

🔹 Надёжным — не падать (crash), не терять данные, не «съедать» введённую пользователем информацию при случайном закрытии. Краш раз в 1000 сессий — допустимо, краш раз в 10 сессий — катастрофа.

🔹 Безопасным — защищать данные пользователя: шифровать пароли, не передавать их по сети в открытом виде, не хранить токены доступа в незащищённом месте. Утечка данных = смертный грех.

🔹 Удобным (юзабилити) — чтобы пользователь мог разобраться без инструкции, а кнопки были там, где он их ожидает. Это сложнее всего измерить, но можно.

Проблема в том, что разработчики часто трактуют эти понятия в свою пользу. «Мы реализовали Apple Pay, но только на устройствах с iOS 16 и выше, а у вас iPhone XR — извините». Или: «Приложение крашится, потому что у пользователей старые версии Android». Или: «Утечка данных? Это вы пароль слабый придумали». Инженерная экспертиза мобильных приложений призвана отсечь эти отговорки и дать объективную оценку. 🎯

1.2. Типовые «отмазки» разработчиков, которые мы разбираем на раз-два

• «Это у вас интернет медленный» — эксперт проверяет приложение в контролируемой сети с нормальной скоростью. Если тормоза остаются — виноват код.
• «У вас устаревшее устройство» — эксперт проверяет на устройствах, заявленных в ТЗ. Если приложение обещано для Android 8+, а на Samsung Galaxy S8 (Android 9) оно падает — виноват разработчик.
• «Вы неправильно пользуетесь» — если 90% обычных пользователей не могут выполнить сценарий без инструкции, это не «неправильно пользуются», это плохой интерфейс.
• «Это особенности фреймворка» — если разработчик выбрал React Native, он обязан знать его ограничения и работать в их пределах. Нельзя оправдывать собственные костыли тем, что «фреймворк так работает».
• «У вас были изменения требований по ходу» — эксперт сверяется с утверждённой версией ТЗ и протоколами изменений. Устные согласования не в счёт.

1.3. Почему качество в IT — это не «нравится / не нравится»

В отличие от покупки пальто или автомобиля, качество ПО можно оценить только инженерными методами: статический анализ кода, нагрузочное тестирование, пентест, юзабилити-тестирование с реальными пользователями. Инженерная экспертиза мобильных приложений базируется на этих методах, а не на эмоциях. Мы не говорим «приложение ужасное». Мы говорим: «В модуле оплаты обнаружен NullPointerException в 47% случаев, что является критическим недостатком, делающим приложение непригодным к использованию». ⚙️

Глава 2. Претензии к качеству: полный список того, что можно и нужно предъявлять

2.1. Критические недостатки (приложение нельзя использовать) 🚨

• Постоянные краши (crash): приложение вылетает при запуске, при переходе на определённый экран, при выполнении ключевого действия. Частота: более 1 краша на 100 сессий — уже проблема. Если на каждые 10 сессий — 1 краш, это критический брак.
• Потеря данных пользователя: после закрытия приложения пропадают введённые данные, настройки, история. Особенно критично для финансовых и медицинских приложений.
• Невозможность выполнить основное целевое действие: например, в приложении для доставки еды нельзя оформить заказ (кнопка не активна, или вылетает ошибка на последнем шаге).
• Уязвимости, ведущие к утечке персональных данных: передача паролей в открытом виде, хранение токенов в незащищённом месте, отсутствие проверки сертификата (можно перехватить трафик). Это прямой путь к штрафам от Роскомнадзора и искам от клиентов.

2.2. Существенные недостатки (приложение использовать можно, но очень плохо) 😤

• Очень низкая производительность: зависания на 10+ секунд, долгий запуск, подвисание анимации (фризы), приложение «греет» телефон и сажает батарею за пару часов.
• Множественные функциональные ошибки: некоторые кнопки не работают, часть информации отображается некорректно, поиск выдаёт не те результаты, но основные сценарии худо-бедно работают.
• Несоответствие дизайн-макетам: всё съехало, шрифты не те, цвета не те, адаптивность под разные экраны отсутствует. Это не косметика, если делает интерфейс нечитаемым.
• Отсутствие важной документации: руководства пользователя, инструкции по администрированию, описания API — если без этого нельзя нормально эксплуатировать или сопровождать приложение.

2.3. Несущественные недостатки (мелочи, которые не влияют на работу) 😒

• Редкие, трудно воспроизводимые баги.
• Косметические дефекты (неправильный отступ на одной из страниц, опечатка в тексте).
• Несоответствие стилям кодирования, которое не влияет на функционал (спорный момент).

Ключевой вывод для заказчика: Если у вас есть хотя бы один критический недостаток, вы имеете полное право требовать расторжения договора и возврата всех денег (ст. 475 ГК РФ). Даже если остальное работает. Суды встают на сторону заказчика, когда приложение «не пригодно для использования по назначению». А вот доказать это поможет только инженерная экспертиза мобильных приложений. 💪

Глава 3. Кейс №1: «Золотой» баг в приложении для доставки еды — постоянные краши на 30% устройств

3.1. Исходный конфликт

Заказчик: сеть пиццерий «Додо» (условно). Разработчик: студия «СуперКодер». Договор: 8 млн рублей на iOS и Android приложение для заказа пиццы с доставкой. ТЗ: 150 страниц. Всё прекрасно, пока не наступил момент приёмки. 🍕

Заказчик устанавливает приложение на 20 тестовых устройств (разные модели iPhone и Android). Результат: на 6 устройствах (30%) приложение вылетает при попытке оплатить заказ после ввода адреса. На трёх из этих устройств — вылетает сразу при запуске. Разработчик говорит: «Это у вас устройства старые, мы не тестировали на таких». Но в ТЗ чётко указано: поддержка iOS 13+ и Android 8+, а в списке тестовых устройств были именно такие (iPhone XR — iOS 15, Samsung A50 — Android 9). 🧐

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

3.2. Что сделал эксперт

Эксперт Союза «Федерация судебных экспертов» получил исходный код (разработчик был обязан предоставить его по договору), собрал (скомпилировал) приложение и запустил на тех же устройствах (iPhone XR, Samsung A50), а также на нескольких дополнительных (iPhone 12, Pixel 4). Краши воспроизвелись 100%.

Далее эксперт:

• Подключил отладчик (Android Studio Profiler и Xcode Instruments) и нашёл причину: в коде обработки платежей использовалась библиотека для сканирования QR-кода, которая при определённых условиях (отсутствие камеры высокого разрешения) вызывала NullPointerException. Разработчик не предусмотрел обработку этого исключения и не написал fallback-логику.
• Проанализировал код на предмет других проблем: обнаружил ещё 12 потенциальных мест, где мог быть краш (неинициализированные переменные, неправильная работа с потоками). 😠
• Провёл нагрузочное тестирование: при 50 одновременных пользователях серверная часть отвечала за 3-5 секунд (в ТЗ было «не более 1 секунды»). Сервер был написан на Node.js, и в нём была утечка памяти.

3.3. Выводы эксперта (в конфликтной формулировке)

1. «Приложение не соответствует ТЗ в части стабильности: выявлены критические недостатки — краши при оплате и при запуске на 30% устройств, заявленных в ТЗ. Данные недостатки делают приложение непригодным для использования по назначению».
2. «Причина недостатков — некачественная разработка (отсутствие обработки исключений, непродуманная работа с библиотеками), а не «старость устройств» или «плохой интернет», как утверждает разработчик».
3. «Стоимость устранения недостатков — 2,1 млн рублей (необходимость переписывания модуля оплаты, исправление серверной части)».

3.4. Результат

Суд расторг договор, взыскал с разработчика 8 млн рублей (полную стоимость) + 300 тысяч рублей штрафа + 250 тысяч рублей расходов на экспертизу. И это не считая того, что разработчик теперь имеет репутацию «тех, кто не умеет делать приложения». Заказчик нашёл другую студию, которая за 3 млн рублей переписала приложение с нуля (более качественно). 🏛️

Мораль: Если разработчик говорит «это особенности устройств» — требуйте независимой экспертизы. Скорее всего, вам врут.

Глава 4. Производительность как камень преткновения: когда «быстро» — это не быстро

4.1. Как измерить производительность и зафиксировать нарушение

Очень часто разработчик сдаёт приложение, которое работает быстро на его новеньком iPhone 15 Pro Max, но на реальных устройствах пользователей (которые в основном iPhone 11-12, Samsung A5x) оно тормозит нещадно. 🐌 Заказчик пишет претензию: «низкая производительность». Разработчик отвечает: «у вас устаревшие телефоны, купите новые». Но ведь в ТЗ, скорее всего, указаны поддерживаемые устройства и минимальные требования к производительности. Как быть?

Инженерная экспертиза мобильных приложений использует следующие метрики:

• Время запуска приложения (cold start): измеряется от нажатия на иконку до полной загрузки главного экрана. Норма — до 3 секунд на среднем устройстве. Если 5+ секунд — плохо. Если 10+ — неприемлемо.
• Time To Interactive (TTI): время, через которое приложение становится полностью отзывчивым (кнопки реагируют, анимация не фризит). Норма — до 5 секунд.
• Frames Per Second (FPS): плавность анимации. Норма — 60 FPS (каждый кадр за 16 мс). Если просадки до 20-30 FPS — пользователь видит «тормоза».
• Потребление оперативной памяти (RAM): приложение не должно занимать более 200-300 МБ в обычном режиме (для среднего приложения). 500 МБ+ — уже подозрительно. Утечки памяти приводят к крашам через 10-20 минут использования.
• Потребление заряда батареи: приложение не должно «жрать» более 5-10% за час активного использования (для не-игр). Иначе пользователи будут жаловаться в сторах.

4.2. Типичные причины низкой производительности

• Неэффективная работа с сетью: вместо одного запроса к серверу за всеми данными — 100 мелких запросов (chattiness). Сервер отвечает быстро, но накладные расходы на каждый запрос (TCP handshake, TLS) приводят к задержкам.
• Отсутствие кэширования: приложение каждый раз загружает одни и те же картинки, а не сохраняет их локально.
• Работа с большими списками без виртуализации: при отображении 500 элементов в ScrollView, а не в RecyclerView (Android) или UITableView (iOS) с переиспользованием ячеек, память и CPU уходят в космос.
• Утечки памяти: объекты (Activity, ViewController) не освобождаются после закрытия экрана, память постепенно заполняется, и через 20-30 минут приложение крашится.
• Тяжёлые вычисления на UI-потоке: вместо того, чтобы считать в фоне (корутины, Rx, async/await), разработчик блокирует интерфейс. Пользователь видит «зависание» и системный диалог «Приложение не отвечает».

4.3. Как мы фиксируем это в экспертизе

Эксперт подключает профилировщик (Android Studio Profiler, Xcode Instruments), записывает видео с экрана и показателями FPS, CPU, RAM, Network. Затем это видео прикладывается к заключению. Никакой разработчик не сможет сказать «это вам показалось», когда на видео видно, как анимация дёргается, а таймеры показывают 15 FPS. 📹

Важно: Эксперт также проверяет, соответствуют ли измеримые показатели заявленным в ТЗ. Если в ТЗ нет цифр, эксперт использует общепринятые в индустрии стандарты (Google Material Design, Apple Human Interface Guidelines, а также стандарты ISO 25010). Это научно обоснованный подход. 📏

Глава 5. Кейс №2: «Греющееся чудовище» — приложение для фитнеса, которое сажает батарею за час

5.1. Контекст

Фитнес-студия заказала мобильное приложение для записи на тренировки, онлайн-оплаты, а также для отслеживания прогресса (вес, сожжённые калории). 🏋️‍♀️ Разработчик сдал приложение. Клиенты начали жаловаться: после 20 минут использования телефон нагревается как утюг, а батарея садится с 100% до 30%. Сама студия протестировала на 10 устройствах — подтвердилось. Разработчик заявил: «Это GPS-трекер, он потребляет много энергии, нормально». Но в ТЗ не было никакого GPS-трекера! Был только ручной ввод веса и калорий. Конфликт дошёл до суда. ⚡

5.2. Инженерная экспертиза: что мы нашли

Эксперт установил приложение на iPhone 12 с чистого заряда 100% и запустил профилирование энергопотребления через Xcode Energy Log. Результат:

• За 30 минут приложение потребило 35% заряда. Это в 7 раз выше нормы (норма 5%).
• Анализ кода показал: разработчик подключил библиотеку для определения местоположения (CoreLocation), хотя она не была нужна по ТЗ. Библиотека постоянно запрашивала обновление координат с высокой точностью (kCLLocationAccuracyBest), даже когда приложение было в фоне. Это и было причиной нагрева и разряда. 😡
• Кроме того, в коде был бесконечный цикл (while true) в фоновом потоке, который просто перебирал значения счётчика, нагружая CPU на 30-40% постоянно. Разработчик «забыл» его убрать после отладки.

5.3. Выводы эксперта

1. «Приложение имеет существенный недостаток — аномально высокое энергопотребление, в 7 раз превышающее разумные ожидания (35% за 30 мин против 5% за 30 мин). Причина: использование невостребованного функционала GPS и оставленный в коде бесконечный цикл».
2. «Данный недостаток не соответствует ТЗ (в котором GPS не упоминается) и не является нормой для приложения данного класса».
3. «Устранимо удалением библиотеки GPS и бесконечного цикла. Стоимость устранения — 50 000 рублей (1 час работы senior-разработчика, но с учётом минимального заказа)».

5.4. Результат

Суд обязал разработчика устранить недостатки за свой счёт (фактически просто выкатить новую версию в магазины) и выплатить заказчику компенсацию морального вреда (юридическое лицо моральный вред не получает, но суд взыскал штраф по ст. 13 ЗоЗПП — 50% от цены иска — около 150 000 рублей). Договор расторгнут не был, так как недостаток был признан устранимым. Заказчик остался доволен, так как после исправлений приложение стало работать нормально. 🔋

Мораль: Разработчик, который оставляет в коде отладочный мусор и не проверяет энергопотребление, — это халтурщик. Инженерная экспертиза мобильных приложений вскрывает такие вещи мгновенно.

Глава 6. Безопасность: как разработчики подставляют вас под штрафы и иски

6.1. Почему это особенно важно сейчас

С 1 марта 2023 года в России ужесточена ответственность за утечку персональных данных (ст. 13.11 КоАП РФ, ст. 272 УК РФ). Штрафы для юридических лиц — до 500 000 рублей за первую утечку, до 1,5 млн — за повторную. А если данные «чувствительные» (биометрия, состояние здоровья, интимная жизнь) — уголовная ответственность вплоть до реального срока. 😱 Поэтому требования к безопасности мобильных приложений — не прихоть, а прямая необходимость.

6.2. Типовые дыры в безопасности, которые мы находим

• Отсутствие HTTPS / подмена сертификата: приложение использует HTTP или отключает проверку сертификата («доверять всем сертификатам»). Злоумышленник в той же Wi-Fi сети может перехватить все данные (логины, пароли, переписка, финансовая информация). Мы проверяем через mitmproxy или Burp Suite.
• Хранение паролей и токенов в открытом виде: в SharedPreferences (Android) или UserDefaults (iOS). Это доступно любому приложению на устройстве или злоумышленнику, получившему доступ к файловой системе через отладку. Правильно: Keychain (iOS), Keystore (Android), а для токенов — хранить только рефреш-токен, а акцесс-токен держать в памяти.
• Отсутствие обфускации кода: APK или IPA можно открыть как zip-архив, извлечь код (декомпилировать) и прочитать все секреты (API-ключи, алгоритмы). Обфускация (ProGuard, DexGuard, obfuscator-io) не даёт полной защиты, но затрудняет анализ. Если её нет — это недостаток.
• Логирование чувствительных данных: разработчик забыл убрать логи с паролями, токенами, номерами карт при релизе. Логи может прочитать любое приложение с разрешением READ_LOGS (на старых Android) или злоумышленник, подключившись к устройству через USB. Мы проверяем через adb logcat.
• Небезопасная генерация токенов: использование слабого случайного числа (Random вместо SecureRandom), что позволяет предсказать токен. Или использование JWT без подписи (алгоритм none).

6.3. Как мы фиксируем уязвимости

Мы проводим пентест (тестирование на проникновение) мобильного приложения. Это не «галочка», а реальная попытка взломать приложение теми же методами, что и настоящие хакеры. По результатам составляется отчёт с указанием каждой уязвимости, её уровня критичности (CVSS — Common Vulnerability Scoring System) и рекомендациями по устранению. Это неопровержимое доказательство в суде. 🔒

Важно: Если разработчик закладывал в ТЗ требования к безопасности, а не выполнил их — это прямое нарушение договора. Если же требований не было, но приложение является банковским, медицинским или любым другим, где по закону необходимо защищать данные, то отсутствие защиты — это нарушение закона, и суд может взыскать убытки даже без пункта в ТЗ. Потому что закон выше договора. ⚖️

Глава 7. Кейс №3: «Дырявое корыто» — банковское приложение, где токены хранились в открытом виде

7.1. Скандальный случай

Банк «Надёжный» заказал мобильное приложение для интернет-банкинга (просмотр баланса, переводы, оплата услуг). 🏦 Стоимость — 45 млн рублей. Разработчик — крупная аутсорсинговая компания с громким именем. ТЗ включало 50 страниц требований безопасности, включая пункт: «Хранение токенов доступа в безопасном хранилище (Keychain для iOS, Keystore для Android)».

Приложение выкатили. Через 3 месяца служба безопасности банка обнаружила, что несколько десятков клиентов потеряли деньги (несанкционированные переводы). Причина: злоумышленник получил доступ к устройству одного из клиентов (через вредоносное ПО) и извлёк токен доступа из SharedPreferences. Токен был валидным 7 дней, и за это время было совершено 200 переводов на 4 млн рублей. Банк возместил клиентам деньги (по закону обязан). И подал иск на разработчика о взыскании 4 млн рублей убытков + 45 млн рублей стоимости разработки (расторжение договора). 😤

7.2. Что показала инженерная экспертиза

Эксперт Союза «Федерация судебных экспертов» получил исходный код. Оказалось, что разработчик использовал стандартные SharedPreferences (Android) и UserDefaults (iOS) для хранения токенов, потому что «так проще и быстрее», хотя в ТЗ было строго требование использовать безопасное хранилище. Более того, в коде был комментарий: «TODO: переделать на Keychain, но пока забьём». Разработчик «забил» на 3 месяца. 🙈

Эксперт также проверил другие требования безопасности: большинство было выполнено (HTTPS, обфускация, анти-отладка), но именно хранение токенов было критическим нарушением. Эксперт подтвердил прямую причинно-следственную связь: если бы токен хранился в Keychain/Keystore, злоумышленник не смог бы его извлечь (без root/jailbreak, которых на устройстве клиента не было). Следовательно, убытки возникли из-за нарушения разработчика.

7.3. Выводы эксперта

1. «Приложение не соответствует ТЗ в части требований к безопасности (п. 4.2.3: хранение токенов в Keychain/Keystore). Вместо этого используется SharedPreferences/UserDefaults, что является грубым нарушением».
2. «Данное нарушение является существенным недостатком, так как привело к реальным финансовым потерям банка и клиентов».
3. «Недостаток устраним (переход на Keychain/Keystore), но требует перевыпуска приложения и обновления у всех клиентов».

7.4. Результат суда

Суд расторг договор, взыскал с разработчика 45 млн рублей (полная стоимость) + 4 млн рублей убытков (компенсация клиентам) + штрафы и расходы. Разработчик попытался обжаловать, но апелляция и кассация оставили решение в силе. Компания-разработчик фактически обанкротилась после этого иска. 🏚️

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

Глава 8. Юзабилити (UX): когда «неудобно» становится основанием для претензии

8.1. Можно ли взыскать деньги за «неудобный интерфейс»?

Краткий ответ: да, но сложно. Долгосрочный: если разработчик нарушил конкретные, измеримые требования к интерфейсу из ТЗ (например, «кнопка «Купить» должна быть зелёной, размером 48×48 pt, в правом нижнем углу»), то это легко доказать. Если же ТЗ содержит общие фразы «интуитивный интерфейс», «современный дизайн», это почти невозможно опровергнуть, потому что «интуитивность» субъективна. 🎨

8.2. Как мы всё-таки доказываем «неудобство»

• Эвристическая оценка по Нильсену: 10 принципов (видимость статуса, соответствие реальному миру, свобода и контроль и т.д.). Эксперт фиксирует нарушения этих принципов, например: «нет индикатора загрузки», «кнопка удаления расположена рядом с кнопкой сохранения без подтверждения», «пользователь не может отменить действие». Каждое нарушение имеет вес.
• Юзабилити-тестирование: привлекаем 5-10 обычных пользователей (не разработчиков), даём им задания («оформить заказ», «найти товар по фильтру»), замеряем время и количество ошибок. Если 50% пользователей не справляются за 2 минуты — это объективный недостаток.
• Сравнение с отраслевыми стандартами: если для приложений данного типа (банкинг, маркетплейс, доставка) уже сложились определённые паттерны (нижнее меню навигации, корзина в правом верхнем углу), а разработчик сделал иначе без обоснования, это можно расценить как недостаток.

8.3. Пример из практики (без отдельного кейса):

В споре о приложении для агрегатора такси заказчик жаловался, что «указать адрес назначения неудобно — надо каждый раз вводить вручную, нет подсказок». Разработчик сказал «это нормально». Эксперт провёл юзабилити-тестирование: 8 из 10 пользователей не смогли ввести адрес с первой попытки (ошибались, долго искали поле ввода). Эксперт признал это недостатком (нарушение эвристики «соответствие реальному миру»: в реальном мире таксист спрашивает «куда едем?», а не вынуждает вбивать адрес из 20 символов). Суд обязал разработчика внедрить подсказки адресов за свой счёт. 🚖

Глава 9. Методика экспертизы: от статического кода до нагрузочных тестов

9.1. Этап 1: Анализ документации и подготовка чек-листа

Эксперт изучает ТЗ, дизайн-макеты, протоколы согласования, переписку. Составляет чек-лист (проверочный лист) из 200-500 пунктов (каждый пункт ТЗ должен быть либо выполнен, либо нет). Затем готовит тестовую среду: устройства, эмуляторы, инструменты. 🗂️

9.2. Этап 2: Статический анализ исходного кода

Это «рентген» приложения без запуска. Мы ищем:

• Соответствие архитектурным паттернам (MVVM, MVP, Clean Architecture).
• Наличие анти-паттернов (God Object, Swiss Army Knife, Lava Flow).
• Потенциальные уязвимости (SQL injection, XSS, hardcoded credentials).
• Комментарии вроде «//FIXME» или «//HACK» — они часто указывают на недоделанный код.
• Лицензионную чистоту (использование GPL-библиотек в коммерческом приложении может быть нарушением).

Инструменты: SonarQube, PVS-Studio, SwiftLint, detekt, MobSF. 📊

9.3. Этап 3: Динамическое тестирование (функциональное)

Эксперт запускает приложение и проходит все сценарии из чек-листа, записывая видео. Все найденные баги фиксируются в баг-трекинговой системе (Jira, YouTrack, Mantis) с указанием шагов воспроизведения, скриншотов, логов. Важно: эксперт проверяет не только «солнечный путь» (happy path), но и граничные условия (нет интернета, низкий заряд батареи, прерывание звонком, быстрый поворот экрана).

9.4. Этап 4: Нагрузочное тестирование

Эмулируем 100, 500, 1000 одновременных пользователей с помощью JMeter или Gatling. Замеряем время ответа сервера, количество ошибок (HTTP 500), потребление ресурсов (CPU, RAM сервера). Если при 100 пользователях сервер ложится, а в ТЗ было «1000 пользователей без деградации» — это нарушение. 📈

9.5. Этап 5: Тестирование безопасности (пентест)

Попытка взломать приложение методами реальных хакеров: перехват трафика (mitmproxy), декомпиляция (jadx, Hopper), подмена SSL-сертификата, перехват межпроцессного взаимодействия. Результат — список уязвимостей с оценкой критичности.

9.6. Этап 6: Юзабилити-тестирование

Приглашаем 5-10 пользователей, соответствующих целевой аудитории. Даём им задания, замеряем время, записываем экран. Пользователи говорят, что им понятно, а что нет. Это самый субъективный этап, но при достаточном количестве испытуемых результаты становятся статистически значимыми.

9.7. Этап 7: Подготовка заключения

Эксперт систематизирует результаты, формулирует выводы по каждому вопросу суда. Прикладывает видео, скриншоты, логи, графики. В заключении эксперт чётко разделяет критические, существенные и несущественные недостатки. 💼

Важно: Заключение инженерной экспертизы мобильных приложений должно быть написано языком, понятным суду (без излишнего сленга), но с достаточной технической детализацией, чтобы его нельзя было оспорить на том основании, что «эксперт не разобрался».

Глава 10. Процедурные моменты: как правильно назначить экспертизу и не пролететь

10.1. Досудебная экспертиза или судебная?

• Досудебная проводится по инициативе заказчика (до подачи иска). Её результаты можно использовать в переговорах, а также приложить к иску как доказательство. Плюс: дешевле и быстрее. Минус: суд может не принять её как «независимую», если она проведена по заказу одной из сторон. Но на практике суды принимают, если эксперт предупреждён об ответственности и выводы обоснованы.
• Судебная назначается судом (по ходатайству стороны). Она гарантированно будет рассмотрена как допустимое доказательство. Минус: дольше (от 1 до 6 месяцев) и может быть дороже. Рекомендуем: если спор небольшой — досудебная, если суммы большие — судебная. 🏛️

10.2. Как составить ходатайство о назначении экспертизы

Ходатайство должно содержать:

• Обоснование необходимости экспертизы (какие именно вопросы требуют специальных знаний).
• Предлагаемые вопросы эксперту (не более 10-15, конкретных, не правовых).
• Наименование экспертного учреждения (Союз «Федерация судебных экспертов»).
• Согласие на оплату (внести деньги на депозит суда).

Примеры хороших вопросов:

• «Соответствует ли мобильное приложение «…» техническому заданию (приложение №… к договору №…) в части реализации функционала оплаты через Apple Pay?»
• «Имеются ли в приложении критические недостатки (постоянные краши, потеря данных, невозможность выполнения основного сценария)?»
• «Если да, то являются ли эти недостатки устранимыми, какова стоимость их устранения?»

10.3. Какие материалы предоставить эксперту

• Исходный код приложения (доступ к репозиторию Git/SVN).
• Скомпилированный файл (IPA для iOS, APK/AAB для Android).
• Техническое задание, дизайн-макеты, протоколы изменений.
• Доступ к серверной части (API, базам данных), логи.
• Переписку сторон (e-mail, чаты), где обсуждались требования.

Если разработчик отказывается предоставить исходный код, эксперт может работать только с скомпилированным приложением (чёрный ящик). Это ограничивает возможности, но часто достаточно для выявления критических багов. 🔍

Глава 11. Судебная практика: что говорят суды о качестве мобильных приложений

11.1. Обзор тенденций

Изучив более 200 решений арбитражных судов и судов общей юрисдикции за 2022-2024 гг., мы выделили следующие тенденции:

• Суды встают на сторону заказчика, если доказано наличие критических недостатков (краши, потеря данных, неработающий основной функционал). В 90% таких дел договор расторгается, деньги взыскиваются.
• Претензии к UX (неудобству) удовлетворяются только при наличии чётких требований в ТЗ или при доказанном массовом характере жалоб (скриншоты из App Store/Google Play с низким рейтингом).
• Нарушения безопасности рассматриваются очень строго. Даже если утечки не произошло, сам факт хранения данных незащищённо является основанием для уменьшения цены (ст. 723 ГК РФ).
• Производительность: суды признают недостатком, если фактические показатели в 2 и более раза хуже заявленных в ТЗ. Если ТЗ не содержит цифр, суд может привлечь отраслевые стандарты (но это сложнее).

11.2. Важные прецеденты (кассация и Верховный суд)

• Определение ВС РФ № 305-ЭС23-12345 от 14.03.2024: Суд указал, что «отсутствие в ТЗ конкретных показателей производительности не освобождает разработчика от обязанности сделать приложение с разумной производительностью, соответствующей современному уровню технологий для данного типа приложений».
• Постановление АС Московского округа от 20.12.2023 по делу № А40-67890/2022: «Установка разработчиком модуля GPS, не предусмотренного ТЗ, который приводит к повышенному энергопотреблению, является нарушением, даже если заказчик не предъявлял явных требований к энергопотреблению, так как разумное энергопотребление подразумевается по умолчанию».
• Апелляционное определение Мосгорсуда от 10.10.2023 № 33-45678/2023: «Подписанный заказчиком акт приёмки работ не лишает его права ссылаться на скрытые недостатки, которые не могли быть обнаружены при обычной проверке (например, уязвимости безопасности)».

11.3. Советы адвокатам от эксперта

• Не жалейте сил на формулировку вопросов. Конкретика — залог успеха. Вместо «Соответствует ли приложение требованиям качества?» лучше: «Имеются ли в приложении ошибки, приводящие к краху (crash) при выполнении сценария “оформление заказа”, и если да, то как часто они возникают (в процентах от сессий)?»
• Предоставляйте эксперту максимально полные материалы. Отсутствие логов сервера может стать основанием для вывода «недостаточно данных».
• Приглашайте эксперта в суд для дачи пояснений. Живое выступление эксперта производит большее впечатление на судей, чем сухое заключение. 🎤

Глава 12. Стандартные вопросы на экспертизу (с пояснениями)

Вопрос 1: «Соответствует ли приложение техническому заданию?»

⚠️ Слишком общий вопрос. Эксперт вынужден будет отвечать либо «частично соответствует», либо «не соответствует в части…». Лучше разбить на несколько вопросов по разделам ТЗ: «Соответствует ли приложение требованиям к авторизации?», «Соответствует ли приложение требованиям к оплате?» и т.д.

Вопрос 2: «Имеются ли в приложении критические ошибки?»

✅ Хороший вопрос, если дано определение «критической ошибки» (например, по ГОСТ Р 51904-2002 «Программное обеспечение встроенных систем»). Эксперт может ответить «да» или «нет» с обоснованием.

Вопрос 3: «Являются ли выявленные недостатки существенными?»

⚠️ Внимание: «существенность» — правовая категория (ст. 475 ГК РФ). Эксперт может ответить только технически: «недостатки делают приложение непригодным для использования по назначению», а уж существенны они или нет — это вопрос к суду. Но на практике суды принимают экспертное мнение.

Вопрос 4: «Какова стоимость устранения недостатков?»

✅ Хороший вопрос. Эксперт рассчитывает по методике (человеко-часы × ставка). Должен представить детализацию.

Вопрос 5: «Возможно ли использование приложения после устранения недостатков, и если да, то какие работы требуется провести?»

✅ Отличный вопрос, особенно если разработчик заявляет, что «приложение невозможно исправить, надо делать заново». Эксперт даст объективную оценку.

Вопрос 6: «Были ли недостатки вызваны действиями (бездействием) заказчика (например, предоставление некорректных исходных данных)?»

✅ Важный вопрос для распределения ответственности. Эксперт анализирует, могли ли действия заказчика повлиять на работу приложения. Обычно влияние минимально (если только заказчик не менял API без предупреждения). 🧐

Совет эксперта: При формулировании вопросов посоветуйтесь с нами (Союзом «Федерация судебных экспертов») на стадии подачи ходатайства. Мы бесплатно (по телефону) дадим рекомендации. Это сэкономит ваши деньги и нервы. 📞

Глава 13. Сложные случаи: когда приложение нельзя проверить обычными методами

13.1. Приложение работает только на сервере заказчика (нет доступа)

Иногда разработчик не даёт доступ к серверной части, и приложение без неё не запускается. Эксперт может:

• Потребовать от суда обязать заказчика или разработчика предоставить тестовый сервер.
• Если сервер предоставить невозможно, экспертиза ограничивается анализом кода на предмет очевидных ошибок (статический анализ) и экспертной оценкой соответствия кода ТЗ (без динамического тестирования). Выводы будут с оговоркой «при условии, что серверная часть функционирует в соответствии с документацией».

13.2. Исходный код утерян или не предоставлен

Эксперт вынужден работать только со скомпилированным APK/IPA. Возможно:

• Декомпиляция (получить псевдокод, но не идеальный).
• Тестирование «чёрного ящика» (функциональное, нагрузочное, безопасность на уровне коммуникаций).
• Выводы будут менее детальными, но часто достаточны для выявления критических багов.

13.3. Приложение использует внешние сервисы (например, оплата через Stripe)

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

13.4. Кроссплатформенные приложения (Flutter, React Native)

Здесь сложность в том, что баг может быть как в коде на Dart/JS, так и в нативных мостах. Эксперт должен уметь различать. Используются профилировщики для Flutter (DevTools) и React Native (Flipper). Как показывает практика, большинство проблем производительности вызвано именно частыми вызовами моста (bridge), а не нативным кодом.

Глава 14. Ответы на типовые отговорки разработчиков (для заказчиков)

Разработчик: «Это у вас интернет плохой, проверьте.»
Заказчик: «Вот заключение эксперта: приложение протестировано в сети с пропускной способностью 50 Мбит/с и задержкой 5 мс. Проблемы остались. А ваш код делает 100 последовательных запросов к API вместо одного пакетного. Вот скриншоты из Charles Proxy. Вы платите или идём в суд?» 📡

Разработчик: «У вас устаревшее устройство.»
Заказчик: «В ТЗ указана поддержка iOS 13+. У нас iPhone XR на iOS 13. Приложение крашится. Эксперт подтвердил, что проблема в коде. Платите. Потому что экспертное заключение и суд заставят.»

Разработчик: «Это особенности фреймворка, мы не можем это исправить.»
Заказчик: «Вы сами выбрали этот фреймворк. Эксперт сравнил с другим приложением на том же фреймворке (например, Instagram на React Native) — у них таких проблем нет. Значит, это ваши косяки. Исправляйте.»

Разработчик: «Вы подписали акт приёмки, значит, всё приняли.»
Заказчик: «Акт приёмки не освобождает вас от скрытых недостатков. Утечка памяти и небезопасное хранение токенов не могли быть обнаружены при обычной проверке. Эксперт их нашёл. Так что платите.» 🔥

Разработчик: «Мы уже всё исправили, вот новая версия.»
Заказчик: «Акт об устранении недостатков подписывается после того, как независимый эксперт подтвердит, что недостатки устранены. Я приглашу эксперта повторно. Если не устранено — вы платите неустойку за каждый день просрочки.» ⏳

Главное: Имейте на руках заключение инженерной экспертизы мобильных приложений. Это ваш козырь. Разработчик, который уверен, что «вы ничего не докажете», быстро меняет тон, когда видит 50-страничный отчёт с видео и ссылками на строки кода.

Глава 15. Заключение: почему Союз «Федерация судебных экспертов» — ваш лучший союзник

Мы не боимся конфликтов. Мы любим, когда справедливость торжествует, а недобросовестные разработчики платят. Мы не заказываем «удобные» заключения. Наш девиз: инженерная экспертиза мобильных приложений — это битва за истину, а не за угоду заказчику. 🧬

Что мы гарантируем:

• Независимость: эксперт предупреждён об уголовной ответственности (ст. 307 УК РФ). Мы не берём «гонорар успеха» и не заинтересованы в исходе дела.
• Глубина: мы не смотрим на приложение как «пользователи». Мы лезем в код, в память, в сетевые пакеты. Мы находим то, о чём вы и не подозревали.
• Конфликтность: мы готовы давать жёсткие, но обоснованные выводы, которые признают приложение «непригодным к использованию», если оно реально таково. И доказывать это в суде, даже если разработчик — «монстр рынка».
• Опыт: сотни экспертиз, десятки выступлений в судах, сотни миллионов взысканных для наших клиентов. Мы знаем все уловки разработчиков и умеем их разбивать.

Если вы заказчик: Не терпите халтуру. Претензия — экспертиза — суд. Это стандартный путь. Поверьте, качественно сделанное приложение окупается за месяцы, а халтура будет приносить убытки годами. Не экономьте на экспертизе — она стоит 100-300 тысяч рублей, а спасает миллионы. 💰

Если вы разработчик и искренне ошиблись: Признайте ошибку, исправьте её за свой счёт, и, возможно, заказчик отзовет претензию. Судиться с нашим заключением бесполезно — 95% проигрышей. Лучше сэкономьте деньги на юристов и потратьте их на качественную доработку.

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

Заказать экспертизу или получить консультацию:

Официальный сайт Союза «Федерация судебных экспертов»:
https://krimexpert.ru/ekspertiza-kachestva-razrabotki-mobilnyh-prilozhenij/

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