Автор: Дэниэл Нотт (Daniel Knott)

Оригинал статьи

Перевод: Ольга Алифанова

Если поискать в Интернете список мнемоник тестирования, можно найти более 30 мнемоник, связанных с тестированием. Одна из наиболее известных эвристик (мнемоник)– это SFDPO (San Francisco Depot), созданная Джеймсом Бахом. Мнемоники не только помогают держать в голове важные разделы, которые нужно покрыть во время тестирования – они также могут поспособствовать генерации новых идей.

Мнемоника MOBILE APP TESTING

Тестируя мобильные приложения, я в основном пользуюсь мнемоникой I SLICED UP FUN, созданной Джонатаном Колом. Она помогает мне сконцентрироваться на различных областях наших приложений. Сегодня я хочу поделиться своей собственной мнемоникой – она называется MOBILE APP TESTING. Правда, легко запомнить? Ниже – подробное описание мнемоники с объяснениями, подсказками и ресурсами, которые помогут вам тестировать мобильные приложения.

M – Мобильное устройство

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

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

O – Ориентация

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

• Поверните устройство из ландшафтной ориентации в ландшафтную (поворот на 180 градусов)
• Из портретной в ландшафтную (поворот на 90 градусов влево или вправо) и обратно.

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

B – мобильные Браузеры

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

На ранних этапах процесса разработки вам пригодятся инструменты разработчика Google Chrome, позволяющие менять тип устройства или разрешение экрана на десктопном браузере Chrome. Финальное тестирование должно проводиться на реальном устройстве с наиболее распространенным среди целевой аудитории браузером. Посмотрите вебинары "Mobile Testing 101" от Стивена Янавея, объясняющие, как пользоваться инструментами разработчика Chrome в мобильном тестировании.

I – Interrupts (прерывания)

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

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

• Выглядит ли приложение так же, как до звонка?
• Все ли данные верны и правильно отображаются?

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

Чтобы получить первое быстрое представление об устойчивости вашего приложения, можно пользоваться инструментами вроде ADB monkey для Android для генерации случайных прерываний и наблюдейний, как приложение с ними справляется. Антуан Мерле написал отличное руководство по настройке и использованию этого инструмента.

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

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

L – Look (внешний вид)

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

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

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

E – потребление Энергии

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

Простой (но не идеальный) способ проверить расход батареи – это зарядить телефон на 100 процентов, установить приложение, запустить его, и оставить телефон на несколько часов. После этого проверьте, как изменилось состояние батареи, и какой процент расхода батареи ушел на ваше приложение. iOS и Android предоставляют некоторые данные о расходе батареи в системном разделе "Батарея". Если ваше приложение находится в этом списке, команда разработки должна изучить вопрос, чтобы найти проблему.

Это всего лишь простейшая проверка на расход батарейки – на этот тест могут влиять и другие факторы, например, системные приложения или другие, установленные на телефоне. Чтобы получить более реалистичную картину потребления батареи приложением, воспользуйтесь инструментом Apple Energy Diagnostics tool. Похожий инструмент и руководство к нему предлагается Google для Android.

A – Автоматизация

Автоматизация, как и в любом проекте разработки ПО – это инструмент, поддерживающий тестирование. Если скрипты автоматизации пишутся и поддерживаются так же, как код приложения, это позволит тестировщикам высвободить много времени, дабы сосредоточиться на более сложном тестировании. В мире тестирования мобильных приложений существует множество инструментов тест-автоматизации – например, Appium, Calabash, Espresso, XCUITest, Earlgrey. Очень важно, чтобы команда уделила время оценке различных инструментов и нашла наиболее подходящий для себя, чтобы получить от него максимум пользы. Информация об автоматизации мобильного тестирования есть в 5 главе книги Hands-On Mobile App Testing.

P – Производительность

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

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

1. Бэкэнд-сервер.
2. Мобильная сеть.
3. Мобильное устройство.
4. Другие установленные на устройстве приложения.

Команда разработки может измерить только производительность бэкэнда и приложения. Сеть не находится под их контролем и может только имитироваться во время тестирования. Рассматривая производительность приложения изолированно, команда может провести дополнительные измерения в поисках узких мест производительности для, к примеру, таких сценариев:

• Время загрузки приложения
• Время, требующееся на отображение первого экрана после авторизации (если она есть).
• Производительность скролла.
• Переходы между экранами.

У Apple и Google есть инструменты и руководства по оптимизации производительности приложений. Это непросто и занимает много времени. Если команда стремится улучшить производительность после релиза, то существуют SDK производительности, которые можно использовать для сбора реальных данных от пользователей. К примеру, это Firebase Performance SDK и FLOWUP.

P – Персоны (Пользователи)

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

T – Time & Date (время и дата)

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

E – Эргономика

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

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

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

S – Security (безопасность)

Безопасность критично важна для ПО и бизнеса, который им владеет. Если хакеры крадут данные пользователей, то эти люди, скорее всего, никогда больше не воспользуются продуктом. Тестирование безопасности должно выполняться экспертами. Это широкая область, и один-единственный человек не может охватить все аспекты этого вида тестирования. Команде разработки, желающей сделать первые шаги в снижении рисков атак на приложение, стоит ознакомиться с Open Web Application Security Project для руководства по тестированию безопасности мобильных приложений. Это отличная стартовая точка, однако бизнесу стоит задуматься о найме экспертов в области тестирования безопасности.

T – Трекинг

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

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

I – Inputs (ввод)

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

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

N – Network (сеть)

Телефон, в зависимости от своего местоположения, может подключаться к разным сетям данных, позволяющих принимать и передавать данные в Интернет. Каждая сеть может предоставлять разным пользователям разную скорость доступа, и эта скорость может влиять на работу приложения. Пользователям доступны GPRS (самый медленный вариант), Edge, 3G, LTE/4G, и грядущая вскоре 5G. Мобильный телефон также может подключаться к Wi-Fi, тоже варьирующих по доступности и скоростям.

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

Команда должна тестировать приложение в реальных боевых условиях – это может дать вам ценную информацию о нем. Очень важно протестировать приложение в тех сетях, в которых им, скорее всего, будет пользоваться клиент. Проверяя сети, не забудьте проверить ситуации с обрывом связи или недоступностью Интернета, чтобы посмотреть, как приложение отреагирует (к примеру, использование в полетном режиме). Если команда не может покидать офис для тестирования, воспользуйтесь инструментами вроде Charles Proxy, чтобы искусственно снизить скорость сети. Если вы пользуетесь инструментами разработчика Chrome, вы также можете имитировать низкую скорость.

G – Гайдлайны платформы

Пользовательский интерфейс – это центральный элемент приложения. Если он слишком сложен и/или перегружен элементами, пользователи запутаются и могут удалить приложение. Каждое приложение должно следовать гайдлайнам интерфейса той платформы, для которой оно создается.

Если в команде разработки нет отдельного дизайнера, тестировщик должен знать, как проверить приложение на соответствие гайдлайнам (Android & iOS) и убедиться, что элементы интерфейса им соответствуют. Если у компании есть корпоративные гайдлайны, команда должна удостовериться, что они соответствуют гайдлайнам платформы. Категорически не следует смешивать элементы дизайна разных платформ – иными словами, приложение Android не должно выглядеть, как приложение iOS или использовать элементы дизайна iOS.

Мнемоники – это весело!

Вот так расшифровывается мнемоника Mobile App Testing. Надеюсь, она вам пригодится и улучшит ваше тестирование. Хотите узнать, что еще можно протестировать? Распечатайте этот чит-лист и повесьте его на видное место, чтобы все могли им воспользоваться.

Обсудить в форуме