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

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

Такая ответственность подразумевает наличие определенных навыков и качеств, которыми должен обладать тестировщик:

1. Понимание проблем, которые решает приложение. Без четкого понимания целей проекта, тестирование будет малоэффективным. Более того, без понимания специфики бизнеса тоже ничего не получится;
2. Организованность. Без должной организованности процесса тестирования, выход релиза приложения может переноситься на неопределенный срок, что явно не порадует разработчиков и владельцев приложения;
3. Планирование. Хаотично проведенные, тесты не принесут должной пользы даже в случае правильного проведения каждого. Только системный подход приносит ожидаемый результат;
4. Аналитический подход. Тесты — это конечная стадия процесса, которой предшествует аналитическая часть, призванная выявить все потенциально проблемные места;
5. Знания в области программирования приложений. Тестировщик не должен обладать всеми знаниями в области проектирования приложений, но он должен понимать архитектуру продукта. Без понимания технических аспектов, даже выявив проблему, тестировщик не сможет ее описать программисту;
6. Коммуникабельность. Тестировщик- связующее звено между заказчиком (менеджером) проекта и программистами. Сообщать плохие новости, да еще связанные с профессиональной деятельностью людей — задача не простая.

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

1. User Story. Вернее, пользовательские сценарии, содержащиеся в тексте User Story;
2. Тестовый сценарий. Написанная на основании пользовательского сценария последовательность действий при проведении различных тестов: изначальные условия, входные действия, действия пользователей, ожидаемый результат;
3. Набор тестовых сценариев. Или сгруппированный по категориям список сценариев;
4. Критерии проведения тестов.

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

С точки зрения процесса, тесты мобильных приложений можно разделить на две категории: общие (или Smoke) тесты и функциональные тесты. Тестировщик до сдачи первого билда может ориентироваться при составлении тестовых сценариев только на ту информацию, которую он получил в процессе обработки документации разработчикам. Поэтому, тестирование первого билда всегда начинается со Smoke-test. Впоследствии, проведение этих тестов будет критерием сдачи билдов для конечного релиза. Набор тестовых сценариев зависит от специфики приложения. Тем не менее, есть определенная совокупность тестов, чаще всего используемых тестировщиками.

Контент

Это самый важный элемент любого приложения. Особое внимание следует уделить именно проверке контента.

Должны быть проверены:

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

Отклик в приложении

Если пользователь пользуется каким-то функционалом приложения (нажимает кнопки, открывает меню, осуществляет поиск), он должен получать ожидаемый отклик от приложения, который будет означать, что последовательность действий верная.

Должны быть проверены:

• Адекватное отображение нажатого состояния элементов;
• Отклик кнопок при нажатии. Лучше всего проверять на слабых устройствах;
• Сообщения приложения при ошибках и процессах (загрузка, ошибка, отсутствие доступа, удаление информации и т.д.);
• Релевантное и правильное отображение медиа контента (звуков, вибраций).

Обновления

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

Должны быть проверены:

• Соответствие функционалов новой и старой версии;
• Адекватность обновления (все ли данные сохраняются).

Внештатные ситуации (Monkey test)

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

Должны быть проверены:

• Удобство навигации по приложению;
• Отсутствие пустых экранов;
• Одновременное нажатие на все клавиши;
• Нативные жесты, предусмотренные функционалом.

Прерывания работы приложения

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

Должны быть проверены:

• Реакция на входящую информацию (звонки, SMS, MMS, оповещения, работу других приложений);
• Реакция приложения на поведение устройства (выключение, ожидание, подключение к сети, зарядка, акселерометр, клавиатура и т.д.).

Мультиплатформенность

Не зря же дизайнеры отрисовывали макеты для разных типов экранов. Теперь приложение должно правильно отображаться на разных типах устройств.

Должны быть проверены:

• Работа на ретина-экранах элементов интерфейса;
• Переход приложения от горизонтального к вертикальному положению;
• Функционал проверки нужной версии операционной системы;
• Адекватная работа всех медиа файлов на разных устройствах и операционных системах.

Операционные возможности устройств

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

Должны быть проверены:

• Работа приложения в условиях нехватки памяти;
• Поведение приложения при открытии в условиях нехватки памяти;
• Поведение приложения в условиях нехватки свободного места для установки;
• Поведение приложения в условиях отсутствия какой-либо функции на устройстве (3G, SD-карта и т. п.);
• Установка, перенос и удаление приложения.

Соответствие сертификатам

Речь идет о гайдлайнах, которые есть у многих магазинов приложений. Также есть определенные правила для организации установочного файла (.apk) и правила оформления дизайна приложений от Google Play, гайдлайну по интерфейсам от App Store и требований к приложениям от Windows Phone.

После завершения стадии Smoke-test наступает стадия функциональных тестов. Уже к этой стадии приложение подвергнется многим исправлениям. Не следует рассчитывать, что процесс тестирования пройдет быстро. В любом случае он займет у тестировщика больше времени, чем он планировал потратить. Функциональные тесты касаются специфики пользования конкретным приложением и учитывают особенности целевой аудитории. Как раз на этой стадии и понадобятся знания специалиста о специфике бизнеса.

После устранения всех ошибок наступает этап полного или предрелизного тестирования. Оно включает в себя повторные smoke и monkey тесты на максимальном количестве устройств. Это последний этап перед сдачей релиза. Тщательно проверяются обновления и интеграции со счетчиками конверсии. После второго этапа проверки релиз приложения готов к публикации в сторах.