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

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

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

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

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

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

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

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

МОДУЛЬНОЕ ТЕСТИРОВАНИЕ

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

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

НЕДОСТАТКИ МОДУЛЬНОГО ТЕСТИРОВАНИЯ

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

Этот вид тестирования необходим, прежде всего, самим разработчикам, чтобы быстро находить и устранять пофиксенные ошибки.

ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ

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

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

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

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

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

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

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

ИНСТРУМЕНТЫ ТЕСТИРОВАНИЯ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ

Существует ряд автоматических тестов для мобильных устройств, для каждой платформы – свои. Они позволяют сэкономить время разработчику и улучшить качество исправления. Со списком инструментов тестирования аппов подробнее можно ознакомиться на сайте http://www.enterra.ru/blog/tools_for_qa/.

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

А/В ТЕСТИРОВАНИЕ или СПЛИТ-ТЕСТИРОВАНИЕ

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

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

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

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

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

Источники сплит-тестирования лучше задействовать те, на которых впоследствии будете выставлять свою рекламную кампанию: выставив объекты тестирования на своей страничке в Fasebook, вы получите более лояльные отзывы, чем на других платформах, за использование которых придется платить. Чтоб не «смазывать» результативную картинку, лучше действовать через незнакомых юзеров.

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