Тестирование мобильных приложений

1703 09-10-14 Время чтения: 6 мин

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

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

Тестирование – это особый пункт в договоре между компанией-исполнителем и заказчиком, оценивающийся отдельно. Этот процесс усложнен необходимостью учитывать различные ориентации/разрешения экранов, аппаратные отличия, версии операционных систем, разные типы внешних прерываний, внутренние ресурсы телефона и прочее. При этом должны быть в наличии различные девайсы, чтобы было на чем проводить тесты. Заранее в ТЗ прописывается, для каких платформ создается мобильное приложение.

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

Способы тестирования продукта

Существует две техники тестирования продуктов:

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

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

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

Модульное тестирование

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

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

Недостатки модульного тестирования

Любая методика проведения тестирования обладает определенными изъянами. Для юнит-тестов – это невозможность покрытия сложного кода. Также трудно подобрать тест для каждой ветви программы, что рождает неточность результата. Если в ходе дальнейшей работы найдены расхождения, то ошибки исправляются вручную. Еще один пункт, который необходимо учесть: при интеграции отдельных модулей, даже если каждый из них работает идеально, обязательно будут обнаружены баги. Этот вид тестирования необходим, прежде всего, самим разработчикам, чтобы быстро находить и устранять пофиксеные ошибки.

Функциональное тестирование

Когда завершена сборка продукта, проводится итерация, а потом быстрое тестирование. Для начала в ход пускаются smoke-тесты, чтобы проверить готовность к тестированию цельного продукта (в нашем случае – мобильное приложение). После исправления обнаруженных багов идет сверка описания заданных параметров и результата.

Создается тест-кейс для выполнения функциональной проверки, то есть специальный «сценарий» действий, за которым ведется испытание. Прогон всех тест-кейсов называется регресионным тестированием. Выверяются такие факторы:

• Функциональная пригодность.
• Точность.
• Способность к взаимодействию.
• Соответствие стандартам и правилам.
• Защищенность.

Функциональное тестирование может проводиться с доступом к коду системы (белый ящик или White Box), или без него (черный ящик или Black Box). Можно изучать сам код системы, или т.н. «серый ящик». Один из необходимых этапов – тестирование обновлений после исправления всех найденных багов. Здесь необходимо учесть, что все данные пользователя в результате обновления сохранятся, а также миграцию данных со старых версий.

Не стоит забывать об интеграции мобильного приложения с автоматическими инструментами аналитики Flurry. Этот вопрос требует проведения дополнительного ряда тестов на совместимость. Очень важный пункт тестирования мобильных приложений – проверка работы в нестандартных условиях, например, имитация хаотичных действий пользователя. Для устройств Android и  iOS существует специальный инструмент – monkey-тест. На других устройствах можно проводить этот тест вручную.

Инструменты тестирования мобильных приложений

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

А/В тестирование или сплит-тестирование

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

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

Методика предусматривает выполнение ряда условий:

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

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

Источники сплит-тестирования лучше задействовать те, на которых впоследствии будете выставлять свою рекламную кампанию: выставив объекты тестирования на своей страничке в Facebook, вы получите более лояльные отзывы, чем на других платформах, за использование которых придется платить. Безусловно, данный метод тестирования позволяет улучшить внешний дизайн без изменений начинки и используется при достижении оптимальных внутренних показателей. Наша команда готова помочь вам реализовать А/В тестирование для улучшения «продаваемости» вашего мобильного приложения!