И как не утонуть между БКИ, Госуслугами и тремя платформами одновременно

Один QA, три платформы, шесть внешних сервисов, легаси-код и огромное количество неопределённости — в требованиях и поведении интеграций, а также в том, что вообще считать корректным результатом. Расскажу, как выстроить тестирование сложного финансового процесса, чтобы до релиза «добиралось» не более 5—7 багов, и все они были известны заранее.

?Контекст: что вообще происходит

Речь идёт об ипотечном процессе в экосистеме Сбербанк/Домклик. Приложение работает на iOS, Android и в вебе. Стек — Java и Kotlin на бэкенде, Swift, Java и Kotlin на фронтенде. Задача QA — обеспечить стабильную работу одного из самых критичных клиентских сценариев: подачи заявки на ипотеку.

Процесс выглядит так:

Лендинг
   └─▶ Анкета с данными клиента
          └─▶ Подтверждение операции по СМС
                  └─▶ Рассмотрение заявки
                          └─▶ Одобрение / Отказ / Отправка на доработку
                                  └─▶ Загрузка документов по недвижимости
                                          └─▶ Проведение сделки и выдача кредита

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

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

? Архитектура интеграций: откуда берутся данные

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

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

?️Техники тест-дизайна: почему здесь нельзя обойтись чек-листом

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

Классы эквивалентности и граничные значения

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

• Минимально и максимально допустимые значения

• Значения на единицу меньше или больше допустимого диапазона

• Нулевые и отрицательные значения (особенно при ручном вводе)

• Поведение калькулятора при изменении одного параметра относительно других

Именно здесь обнаружили один из ключевых багов: после подтверждения дохода через Госуслуги пересчёт суммы одобрения не подтягивался корректно. Приложение продолжало отображать значение из предыдущего расчёта. Баг воспроизводился только при определённой последовательности действий: сначала расчёт без Госуслуг, затем авторизация и повторный расчёт в той же сессии.

Таблицы принятия решений

Решение о результате рассмотрения заявки зависит от комбинации факторов: данных БКИ, типа дохода, гражданства, наличия созаёмщика. Таблица принятия решений позволяет явно описать все значимые комбинации и убедиться, что ни один граничный случай не упущен.

Попарное тестирование (Pairwise)

Три платформы (iOS, Android и веб) × несколько типов устройств × несколько сценариев авторизации × несколько состояний профиля — это комбинаторный взрыв. Pairwise‑подход позволяет сократить матрицу тестовых сценариев до управляемого размера без потери покрытия на уровне попарных взаимодействий.

Тестирование состояний (State Transition)

Процесс заявки — это конечный автомат. Каждый статус (черновик, на рассмотрении, одобрено, отказ, архив) допускает определённые переходы и запрещает другие. Тестирование некорретных переходов (например, попытка повторной подачи заявки в статусе «на рассмотрении») часто выявляет баги, которые пропускаются при позитивном тестировании.

? Самые показательные баги: разбор по категориям

1. Потеря данных анкеты при сворачивании приложения

Сценарий: пользователь частично заполнил анкету, свернул приложение (например, чтобы уточнить паспортные данные в другом приложении), вернулся — часть полей сброшена.

Корневая причина: отсутствие сохранения промежуточного состояния формы. Поведение при background/foreground‑переходе различалось на iOS и Android: на одной платформе данные сохранялись, на другой — нет.

Почему это критично: ипотечная анкета — это не форма с тремя полями. Пользователь тратит время, а часть данных требует обращения к документам. Потеря данных означает потерю пользователя.

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

2. Расхождение данных между профилем и Госуслугами

Сценарий: данные клиента в профиле Сбера (например, адрес регистрации или серия паспорта) не совпадают с данными, полученными через ЕСИА.

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

Как обнаружили: перехват трафика через Proxyman с анализом тела запроса на каждом шаге. Сравнение данных в трёх точках: профиль клиента, ответ ЕСИА, тело заявки, отправленной на рассмотрение.

3. Некорректное отображение суммы одобрения из базы данных

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

Корневая причина: интерфейс получал данные из кеша, который не инвалидировался при обновлении записи в базе данных.

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

4. Параллельные изменения в iOS, Android и в вебе

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

Почему это системная проблема: при кросс‑платформенной разработке версионирование API и синхронность фича‑флагов требуют явного тестового покрытия. Нельзя считать задачу закрытой, протестировав одну платформу.

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

?️ Инструментарий и инфраструктура

Proxyman — главный инструмент анализа интеграций

Перехват HTTPS‑трафика на реальных устройствах позволяет видеть то, что не видно через интерфейс: что именно уходит в запросе, что возвращает внешний сервис, где происходит сопоставление данных. Для тестирования интеграций с Госуслугами и БКИ это незаменимый инструмент, особенно когда нужно воспроизвести конкретный ответ от внешней системы без её реального вызова.

Zephyr + Allure — управление тест‑артефактами

Zephyr используется для ведения тестовых сценариев и отслеживания выполнения регрессии. Allure применяется для генерации отчётов по прогонам автотестов. Эта связка даёт полную картину: что было запланировано, что запущено автоматически, что упало, что проверено вручную.

Внутренние админки — источник истины

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

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

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

Между командами

В рамках одного процесса QA взаимодействует минимум с тремя‑четырьмя смежными командами: владельцами профиля клиента, командой авторизации, интеграционными командами на стороне Домклик. У каждой команды свой ритм релизов, своя тестовая среда и свои дежурные.

Практика, которая работает: устанавливать прямые контакты с QA и разработчиками смежных команд ещё до того, как что‑то сломалось. Когда баг на стыке систем уже в работе — знакомиться не лучшее время. Если смежная команда планирует изменения в API или поведении сервиса, то об этом нужно знать заблаговременно, а не из Сhangelog после развёртывания.

Отдельный навык — уметь чётко сформулировать, где именно находится граница проблемы. «У нас что‑то сломалось с Госуслугами» — это не баг‑репорт для смежной команды, а приглашение к долгому выяснению. «После авторизации через ЕСИА в теле запроса поле registrationAddress приходит на рассмотрение пустым, хотя в ответе ЕСИА оно присутствует» — это уже разговор.

Внутри команды: QA ↔ разработчик ↔ аналитик

Треугольник QA — разработчик — аналитик в финансовом продукте работает только при одном условии: у каждого есть чёткое понимание зоны ответственности другого. Аналитик описывает бизнес‑логику, но редко указывает граничные случаи и поведение при ошибках, поскольку это зона ответственности QA. Если QA пассивно ждёт «полного» ТЗ, то получает его постфактум в виде багов на проде.

Разработчик реализует то, что написано в задаче. Если в задаче не описывается поведение при конфликте данных из ЕСИА и профиля, то разработчик сделает так, как ему показалось логичным. QA должен поднимать эти вопросы до начала разработки, а не после.

На практике это выглядит так: при появлении задачи в бэклоге QA изучает её первым. Не для того чтобы написать тестовые сценарии, а чтобы задать неудобные вопросы, пока ещё не поздно. Вопросы в Refinement вроде «Что происходит, если пользователь авторизовался через ЕСИА, но его паспортные данные там отличаются от профиля?» на этом этапе стоят в разы дешевле, чем после релиза.

⚙️Автоматизация: что покрыто и почему?

Регресс бэкенда и мобильный регресс — наиболее стабильная и повторяемая часть тестирования. Автоматизация регрессионного прогона на реальных устройствах (iOS + Android/back) обеспечивает стабильное время выполнения и исключает человеческий фактор из рутинных проверок. Это особенно важно при кросс‑платформенном тестировании, где объём комбинаций для ручной проверки неприемлем.

Работа с легаси: специфика, которую нельзя игнорировать

Кодовая база частично является легаси и продолжает им оставаться в ряде модулей. Это накладывает специфику на тестирование.

Неочевидные зависимости: изменение одного компонента может неожиданно сломать другой, не связанный с ним напрямую. Регрессия должна быть шире, чем зона изменений.

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

Технический долг как источник регрессионных багов: баги, которые кажутся новыми, нередко оказываются проявлениями давно существующих проблем, проявившихся в новом контексте. Для легаси‑флоу история багов — часть знаний QA.

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

Метрики процесса

Точных количественных метрик по конверсии или Crash Rate я не привожу, поскольку сбор таких данных выходит за рамки QA‑процесса. Однако есть операционные показатели, которые характеризуют стабильность процесса:

• 5—7 багов стабильно фиксируются в тестовой среде перед каждым релизом, и все они известны команде до момента выпуска. Отсутствие неожиданностей на проде — это и есть главный KPI.

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

• Нет критических инцидентов в проде по процессу подачи заявки. Финансовые данные клиентов не повреждаются, заявки не теряются.

Выводы

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

Вот несколько принципов, которые работают в этом контексте:

• Интерфейс — не источник истины. Всегда проверяй данные через бэкенд и административные системы.

• Каждая интеграция — отдельная точка отказа. Тестируй не только Happy Path, но и поведение при частичном ответе, таймауте и конфликте данных.

• Кросс‑платформа — это не «запусти на втором устройстве». Это отдельная матрица тестовых сценариев с учётом версионирования и поэтапного развёртывания.

• Легаси требует более широкой регрессии. Зона изменений и зона риска в легаси‑коде не совпадают.

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

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

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