Сразу оговорюсь, всё нижеописанное почерпнуто мною исключительно из своего небольшого по объёму затраченного времени (но большого по количеству авралов, злоключений и прочих баттхёртов) опыта. Оговорка номер до: эти принципы применимы только к мобильному ПО. Как там у других — я не знаю и гадать не хочу. И последнее, пожалуй, самое важное. Данные принципы лишь задают направление, а потому будут полезны в основном новичкам (хотя вы, конечно, можете написать о бесполезности сей статьи в комментариях).
Итак, когда я только начинал заниматься тестированием, прочитал доступную теорию, начальник начал второе собеседование с простого вопроса – в чём особенность мобильного тестирования по отношению к другим видам тестирования? Тогда я лишь приблизительно смог ответить на этот вопрос. Сейчас я выделяю для себя следующие принципы:
Принцип 1: Постоянная мобильность
Главное отличие мобильного от десктопного ПО заключается в том, что с айфоном вы передвигаетесь, тщетно ловите вайфай в столовых ваших вузов (совершая характерные движения руками), бегаете и вообще по максимуму загружаете все возможные сенсоры движений, что китайские умельцы встроили в него. Забывать об этом смерти подобно. Кто-то может сказать, что глупо бегать по офису, меняя ориентации экрана и теряя-восстанавливая коннект. На это у меня есть 2 контр-примера из жизни:
- Крэш в приложении при попытке восстановить приложение из бэкграунда с предварительной сменой ориентации экрана;
- Крэш в приложении при “потряхивании” девайса в момент совершения этим девайсом фотосъёмки (приложение изначально создавалось для создания фото).
Принцип 2: Ловля вай-фая на живца
Большая часть современных приложений, так или иначе, использует сеть. Далеко не всегда это “полный коннект”. Поэтому обязательно необходимо тестировать приложение как минимум 4-мя способами:
- Позитивный кейс (наличие отличной постоянной связи);
- Наличие постоянной неотличной связи;
- Отсутствие связи;
- Потеря связи.
Большинство пользователей вряд ли увидят ваши крэшы, но могут перестать пользоваться приложением, если оно плохо грузит и сохраняет данные при их (пользователей) проблемном коннекте. На случай отсутствия связи должны быть отображены хотя бы какие-то плейсхолдеры (чтобы пользователь мог понять, что приложение не может прогрузить данные сейчас). Ну и конфетка для тестера – потеря связи. Пользователи будут сталкиваться с этим постоянно, и тут самое важное: избежать по возможности потери данных.
Принцип 3: Прерывания
По-хорошему, этот принцип должен стоять во главе всего списка. Ведь прерывания наносят самый существенный вред приложению, при этом являясь одним из основополагающих принципов самих мобильных систем. Во время использования вашего приложения, пользователь может
- Неожиданно получить звонок (смс, напоминание, нотификацию и т.д.);
- Закрыть приложение для того, чтобы открыть какое-то другое на некоторое время и вернуться к вашему приложению позже;
- Послать девайс в сон на некоторое время.
Реакцию вашего приложения на эти раздражители нужно проверять сразу после функционального тестирования. Тут кроется бездна интересных ситуаций от безобидных (немного съехал интерфейс) до критичных (приложение падает, данные теряются, полный ахтунг).
Принцип 4: Особенности операционных систем и железа
Данный принцип находится тут с явной натяжкой, но всё же, я считаю, что ОС и железо, установленное в мобильных устройствах, сказывается на производительности ПО намного сильнее, чем в десктопах. Почему?
- Андроид и ЯблокоОсь существенно отличаются от десктопных систем. Активности (и их стэк), интенты, броадкаст ресиверы, манифест файл (с указанием permissions и user features), доступ к ресурсам, кэш и данные приложений – всё это и многое другое нужно хотя бы бегло изучить для того, чтобы понимать, как ваше приложение работает в данной конкретной среде, что может привести к его (приложения) отказу или потере данных. Отсюда вытекает тестирование перехода между состояниями, тестирование для нахождения утечек памяти и прочее. Всё это необходимо для полноценного обеспечения качества приложения.
- Прогресс не стоит на месте, но железо смартфонов всё ещё сильно ограничено по сравнению с настольными системами. Особенно важно то, сколько ваше приложение занимает оперативной памяти, при каких условиях система автоматически “выпилит” его из этой самой памяти, как приложение будет себя вести в этой ситуации.
Принцип 5: Человеческий фактор
Если приложение рассчитано на широкую аудиторию, будьте готовы к тому, что куча людей, бесконечно далёких от разработки ПО, будет вести себя совершенно по-разному с вашим приложением. Тут важно понимать, что мы не можем просчитать все возможные случаи использования приложения всеми криворукими пользователями. Но проверить, что приложение корректно выполняет весь свой функционал на основных юз-кейсах мы обязаны. Неплохо также обезопасить себя, пробежавшись по приложению в качестве пользователя-дурачка, тыкая во всё подряд, открывая и закрывая активности, не дожидаясь загрузки данных и т.д. Проблема с “замыленным глазом” решается путём привлечения в процесс ваших девушек, друзей и родственников. Просто дайте им приложение в руки и посмотрите, как они будут им пользоваться. Это даст вам примерную (насколько примерную зависит, конечно, от величины выборки) картину того, что следует тестировать в первую очередь и на что обратить внимание.
Вместо заключения
Конечно, в определённой степени эта подборка принципов субъективна и спорна и, возможно данная статья покажется надуманной или некорректной (как мне, так и вам). С другой стороны, я надеюсь, что статья всё же окажется полезной и поможет вам конкретизировать и не забывать вещи, наиболее важные при тестировании мобильных приложений. Ну и напоследок хотелось бы обменяться опытом:
Какие принципы мобильного тестирования вы используете?
Автор: justmedime
