Тестирование супераппов: особенности процесса и причины появления багов

Мобильные приложения подстраиваются под современные тренды: на смену узконаправленному софту приходят мощные инструменты, которые объединяют в себе десятки более простых, — супераппы. QA Lead IT Test (компания-разработчик TMS DoQA) Дмитрий Трофимов рассказывает об особенностях тестирования подобных многофункциональных приложений.

Суперапп — это большое и сложное мобильное приложение, которое состоит из множества компонентов и SDK. Как правило, такой софт создают крупные компании при выстраивании собственной экосистемы.

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

Помимо основных модулей приложения, супераппы часто интегрируют сторонние сервисы. Например, для определения адресов и возможности доставки нужен модуль с картой и API с адресами, но писать подобный модуль самостоятельно дорого и сложно, особенно, когда проект не масштабный и есть готовые решения с подобными SDK. Например, «Яндекс» и Google активно поставляют свои модули на рынок, тем самым помогая развивать индустрию.

Резюмируя различия между простыми приложениям и супераппами, можно выделить следующие.

Простое приложение:

Суперапп:

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

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

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

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

Для каждой из команд есть свои API, и получение огромного количества информации при запуске приложения — начиная от токенов и пользовательских настроек и заканчивая каталогами и конфигами — очень сложно оптимизировать. А помимо получения, нужно еще и отправить что-то обратно, в виде метрик, аналитики и запросов пользователя.

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

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

Раз мы делимся на команды по своим SDK, то и тестировать начинаем с отдельных SDK. Демо SDK представляет собой часть приложения со своим UI, функционалом и дебаг-панелью. Тестировать подобную демку можно, в целом, как и обычные приложения.

Если чуть усложнить, то у модуля может не быть никакого UI. Пример — контекстная реклама. Именно этот модуль начинает отправлять пользователям рекламные сообщения о новых кроссовках после покупки одной пары. Такие модули тестировать сложнее, и обычно они покрываются автотестами. Но если автотестирование затруднено или невозможно, то создаются отдельные демки, куда дописывается простой UI для взаимодействия с модулем.

Еще одна особенность — так как мы тестируем модуль в отрыве от основного приложения, у нас нет контекста работы нашего модуля. В реальных условиях мы должны что-то получить от приложения и что-то ему отдать. Это может быть JSON с данными, параметры для метода или нечто иное. В рамках демки нам неоткуда получать входные данные. Поэтому мы используем моки. Мок — это статичные данные, которые подменяют ответ или запрос сервера. Проверки на моках — не панацея, и при работе с реальным бэком могут возникать ошибки, но пока бэк не готов или к нему нельзя подключится, приходится довольствоваться тем, что есть.

После проверки демки — время интеграции. Если по учебнику, то интеграции — это обычно объединение двух модулей. Хороший пример — объединение бэка и фронта веб-приложения. Но с мобилками все немного иначе. Мы тоже можем объединить мобильный фронт и бэк, только процесс интеграции чуть сложнее.

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

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

Наконец, нужно проверить приложение целиком. Обычно этим занимается отдельная команда, но в системном регрессе принимают участие все. Если вдруг на данном этапе обнаружен баг, то команда системного тестирования передаст его в команду соответствующего модуля для локализации и фикса. Также команды сами проверяют свои модули в итоговой версии приложения. Это нужно, чтобы исключить баги, вызванные другими, иногда несвязанными между собой модулями.

Больше экспертных материалов о тестировании — в Telegram-канале системы управления тестированием DoQA.