Баг всплыл только в проде: зачем мобильному приложению e2e-тест сценария с 1С

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

Баг, который прошёл все проверки, кроме e2e

Кладовщик сканирует накладную в приложении, экран показывает «отправлено» — и ещё вчера этого было достаточно: документ уходил в 1С за пару секунд. После обновления обмена на стороне сервера 1С формат ответа изменился. Приложение по-прежнему пишет «отправлено», но документ в базу не попадает. Юнит-тест экрана сканирования зелёный: он проверяет только отрисовку и запись в локальную очередь. Ручной QA тоже прошёл — тестировщик открыл приложение на эмуляторе, где 1С подменена заглушкой, и подтвердил, что кнопка работает. Целиком цепочку «сканер → API → база 1С» никто не прогнал.

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

Что обязан проверять e2e-тест мобильного приложения с 1С

Экран может отрисовываться безупречно и всё равно обманывать пользователя, если проверка останавливается на интерфейсе. Для мобильного приложения, которое работает с 1С, сценарий обязан пройти по всей цепочке целиком:

• ✓авторизация под ролью из 1С — и проверка, что пользователю доступны именно те документы и справочники, которые разрешены этой роли, а не все подряд;
• ✓отправка данных в 1С с обратной проверкой: документ действительно создался в базе, а не просто получил ответ 200 от сервера;
• ✓работа без сети — приложение копит действия в очереди и досылает их при восстановлении связи без дублей и без потерь;
• ✓push-уведомление о смене статуса документа в 1С доходит до устройства и открывает нужный экран, а не просто прилетает текстом;
• ✓поведение при рассинхронизации версий: старая версия приложения на телефоне сотрудника и обновлённый API 1С не должны ломать сценарий молча, без внятной ошибки;
• ✓округление и формат сумм в документе совпадают с тем, что покажет 1С — расхождение на копейки в счёте выглядит как ошибка учёта, а не как мелочь мобильного экрана.

Каждый пункт из этого списка — отдельная точка отказа. Рассинхронизация версий встречается ровно там, где разработку мобильного приложения и обновление 1С ведут разные подрядчики без общего графика релизов. А роли стоит проверять не абстрактно, а по факту: у кладовщика в приложении не должно быть кнопки списания без согласования, даже если он случайно её увидит, — эту границу задаёт не интерфейс, а права, которые приложение получает из 1С при входе.

Частое заблуждение: «мы гоняем тесты на эмуляторе — этого достаточно»

Эмулятор честно показывает, что кнопка нажимается и экран открывается. Он не показывает, что происходит с очередью синхронизации, когда сеть пропадает на несколько секунд посреди отправки документа, — а именно так ведёт себя мобильный интернет на складе в цокольном этаже или у курьера в лифте. Он не воспроизводит push-уведомление, если тестовый профиль подключён к боевому серверу пушей, а сама 1С в тесте — заглушка. И он не ловит расхождение форматов даты или кодировки, которое всплывает только на реальном устройстве с реальной локалью — например, когда сотрудник сменил язык интерфейса телефона, а сервер 1С по-прежнему ждёт даты в другом формате.

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

Три способа гонять e2e-тест — и что каждый закрывает на самом деле

Компании выбирают между тремя вариантами, и на практике рабочей оказывается их комбинация, а не один способ в чистом виде.

Как выстроить процесс: путь от сценария до регрессии

Порядок работы одинаков независимо от того, кто пишет тесты — своя команда или подрядчик:

1. ✓Собрать сценарии не из головы, а из реальных обращений в поддержку и логов 1С — какие действия чаще всего приводят к расхождениям между приложением и базой, и в каком порядке пользователь обычно их совершает.
2. ✓Поднять отдельный тестовый контур 1С, а не гонять тесты на боевой базе: сервер должен соответствовать системным требованиям 1С, а данные в нём — быть обезличенной копией, а не документами реальных клиентов.
3. ✓Выбрать инструмент под платформу: для нативного iOS и Android — XCUITest и Espresso, для кросс-платформенного приложения — Detox или Appium, если разработка мобильного приложения ведётся на React Native или Flutter.
4. ✓Прогнать сценарий на нескольких версиях ОС и моделях устройств, а не только на телефоне разработчика — старый Android на складском терминале ведёт себя иначе, чем новый флагман в офисе.
5. ✓Включить e2e-прогон в сборку перед публикацией, а не после неё — правки, вышедшие после релиза, доходят до пользователя App Store и Google Play с задержкой на модерацию.
6. ✓Держать набор регрессионных сценариев и прогонять его при каждом изменении обмена с 1С, а не только при новых экранах — основная часть таких багов приходит именно со стороны учётной системы, а не интерфейса.

Что входит в e2e-тестирование, если разработку делаем мы

В интеграции мобильного приложения с 1С e2e-сценарии закладываем в план тестирования на старте проекта, а не добавляем после первого прод-инцидента: пишем сценарии по ролям реальных пользователей, поднимаем тестовый контур 1С и прогоняем связку перед каждым релизом в сторах. Для B2B-приложения с 1С это ощутимо сильнее — там несколько ролей, офлайн-режим у курьеров и складов, и цена необнаруженного бага выше цены лишнего прогона теста.

Разработка мобильного приложения с интеграцией 1С начинается от 500 000 руб, и построение e2e-тестирования входит в эту работу, а не оформляется отдельной строкой сверху. После запуска тестовый контур 1С не бросаем — обновление тестовой базы и сопровождение 1С у нас считается отдельно, от 3800 руб/час, и не привязано к стоимости разработки. Если проекту нужна готовая архитектура обмена без мобильного приложения с нуля, для этого есть 1С:Мобильная платформа — там сценарии тестирования проще за счёт готовой связки с базой. Актуальные условия — на странице тарифов.

Чек-лист: когда e2e-тест — условие релиза, а не опция

Проверьте, попадает ли проект хотя бы в один пункт — тогда e2e-тест перед релизом не роскошь, а условие, без которого баг найдёт не тестировщик, а клиент:

• ✓приложение пишет данные в 1С в реальном времени, и расхождение всплывает не сразу, а на закрытии периода;
• ✓сотрудники работают в местах с нестабильной сетью — на складе, в поле, у курьера — и приложение обязано досинхронизироваться корректно;
• ✓в приложении несколько ролей с разными правами, унаследованными из 1С;
• ✓релиз проходит модерацию в App Store или Google Play, и откат после публикации занимает дни, а не минуты;
• ✓обновления 1С и обновления приложения выпускают разные команды в разное время;
• ✓от точности данных в приложении зависят деньги — остатки склада, суммы в заказах, статусы оплаты.

❓ Частые вопросы

Чем e2e-тестирование отличается от юнит- и интеграционных тестов?

Юнит-тест проверяет один модуль в изоляции, интеграционный — связку двух компонентов, например экрана и локальной базы. E2e-тест прогоняет весь путь пользователя целиком: экран, сеть, API и реальную 1С — и ловит баги, которые видны только на стыке всех звеньев сразу.

Нужно ли e2e-тестирование маленькому приложению без сложной логики?

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

Сколько стоит внедрить e2e-тестирование в существующий мобильный проект?

Стоимость зависит от числа сценариев и того, есть ли уже тестовый контур 1С. Разработка мобильного приложения с интеграцией 1С у нас начинается от 500 000 руб, и в эту сумму входит построение процесса тестирования — точную оценку под конкретный проект даёт разбор текущей архитектуры.

Можно ли автоматизировать e2e-тесты для приложения, которое уже в продакшене?

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

Как часто нужно гонять e2e-тесты — при каждом релизе или периодически?

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