Мобильное тестирование: быстрый гайд

• Суть
• Гибридная стратегия
• Что тестируется
• Когда
• Тест-план
  • Платформы, версии, девайсы, параллельное, исследовательское
  • API, debounce, шрифты-цвета UI, навигация, уведомления и прочее
• Дополнительные сценарии
  • Батарея
  • Спящий режим
  • Блок экрана
  • Сеть

Кратко

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

Хорошей практикой является, приступая к тестированию мобильных приложений, сначала определить стратегию тестирования, она поможет «разбить» процесс тестирования на этапы и выполнить всё качественно, без пропуска нужных этапов.

Стратегия зависит от архитектуры

Стратегия тестирования зависит от того, является ли это приложение нативным, веб-приложением, или гибридным.

Напомним для ясности:

• Нативное приложение — устанавливается непосредственно на смартфон вместе со всем нужным и в большинстве случаев может нормально работать и без подключения к Интернету. 
• Мобильные веб-приложения, оптимизированные на юзабельность на телефоне. Это, можно сказать, не совсем мобильные приложения в узком понимании, а скорее специфические веб-сайты, написанные на HTML/CSS и запускаемые в браузере. Хотя по дизайну и по виду они могут быть вообще идентичны нативным приложениям.
• Гибридные — концепция гибридного приложения представляет собой сочетание нативного и веб-приложения. Они рассчитаны на поддержку веб- и нативных технологий на разных платформах. Кроме того, такие приложения делать намного проще и быстрее (чем нативные). Потому и стали самыми популярными.

Итак, гибридное приложение = нативное + мобильное. Рассмотрим кейс гибридного мобильного приложения, как самого распространенного типа, в данное время. Прежде чем углубиться, наиболее распространенные типы тестирования мобильных приложений:

Типы

Это следующие типы:

• Функциональное тестирование
• Тестирование производительности
• Тестирование безопасности
• Тестирование юзабельности (эргономичности)
• UI/UX тестирование

Выше указаны типы с учетом личного опыта автора в мобильных проектах; а в вашем проекте акценты могут быть другими (например, в финансовом приложении исключительную важность имеет тестирование безопасности, а в игре — тестирование производительности).

Запуск QA-процесса

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

Приступая к планированию процесса, следует убедиться, что код был покрыт юнит-тестами, а если нет, то учитывать это при тестировании на интеграционном и сервисном уровнях. Просто отчета об успешно выполненном юнит-тестировании — мало, следует добиваться, чтобы покрытие юнит-тестами было как минимум 80%, а в идеале и 100%, если есть такая возможность. Хорошо если в компании отлажен пайплайн, позволяющий всем отслеживать жизненный цикл и выполнять корректирующие и тестовые действия на каждом этапе цикла разработки.

Тест-план

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

• Первый по порядку и очень важный кейс — это проверка успешности установки приложения через PlayStore/App Store.
• Далее необходимо проверить, корректно ли открывается/запускается приложение после успешной установки.

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

1. Проверьте, какие платформы мобильных ОС наиболее популярны в регионе.
2. На основании результатов, полученных на этапе 1, выясните, какие мобильные девайсы наиболее популярны в данном регионе, составьте список.
3. Из списка, полученного на этапе 2, выберите 5 топ-устройств и используйте их в тестировании. 

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

4. Важно учитывать и версии ОС. Например, в условном регионе «Восточная Европа» наиболее распространены iOS версий 14 и 15; соответственно необходимо убедиться, что тестирование будет проведено на iOS версий 14 и 15. Еще один важный момент, который может быть упущен из виду — поддержка минимальной версии. Например, если приложение поддерживает минимальную версию iOS 12, проведите регрессионное тестирование на iOS 12 на устройствах с большим и маленьким экраном. По опыту, какое-то количество багов возникает именно со старыми версиями.
5. Что касается автоматизации: хорошо если есть возможность запускать тесты параллельно на многих выбранных устройствах. Таким образом, с точки зрения регрессии, все ваши сквозные тесты выполняются в автоматическом режиме и в случае каких-то проблем вы вовремя о них узнаете.
6. Специфические тесты, которые по каким-то причинам не могут быть автоматизированы, передаются на ручное исследовательское тестирование.

Важные чеки

1. Проверка, что при переходе от одного экрана к другому одни и те же API не вызываются несколько раз.
2. Так называемый дебаунсинг (debouncing), это влияет на производительность и юзабельность приложения. 

Например, проверяется работа жеста pull-to-refresh (то есть жест “потянуть для обновления экрана”). Проведение дебаунсинга означает, что когда пользователь быстро делает такой жест несколько раз подряд (что часто случается), запросы на обновление экрана должны отправляться только через определенные, не слишком короткие промежутки времени, а не всякий раз. Это позволит избежать снижения производительности и юзабельности приложения из-за многочисленных запросов нетерпеливых/невнимательных пользователей в течение нескольких секунд.

3. В мобильных приложениях важно контролировать шрифты/цвета, и размер текста, поскольку для пользователей это имеет громадное значение. Даже незначительное изменение цвета фона, шрифта, размера шрифта — повлияет на юзабельность приложения. Поэтому необходимо проверять вид (и единообразие) цветовых сочетаний, шрифтов, размеров и подобные визуальные нюансы.
4. Хорошей практикой является привлечение к процессу специалистов по UI/UX, чтобы они могли более квалифицированно посмотреть, и наглядно показать проблемы с UX, если таковые возникнут.
5. Дополнительная ручная, очень тщательная проверка функциональности и производительности приложения на 1-2 самых «ходовых» девайсах.
6. Также необходимо следить за логами, генерируемыми при всех тестовых действиях, выполняемых на фронтенде. Это позволит легче отладить проблемы, если таковые возникнут в процессе.
7. Что касается логов, проверьте, не записывается ли в них неконтролируемо какая-либо личная информация (так называемая PII, personally identifiable information, позволяющая связать пользователя с данными), поскольку теоретически это может привести к юридическим последствиям.
8. Также нужно особо проверить навигацию по приложению, и открытие ссылок в web view, поскольку это гибридное приложение (а у нас пример — гибридное приложение как мы помним). Все внутренние ссылки в приложении должны открываться в web view, а не во внешнем браузере.
9. Проверьте, правильно ли приложение отправляет уведомления и правильно ли они отображаются в панели.
10. Нужно также проверить, перенаправляют ли уведомления в соответствующую область приложения, если их нажать.
11. Если пользователь запускает другое приложение, и оно отправляет тоже уведомления вперемешку с тестируемым, как это совмещается? Удобно ли это для пользователя, или может где-то проблемно.

Дополнительные важные сценарии: батарея, режим ожидания, блок экрана, сеть

Дополнительные сценарии проверки приложения (железо).

Батарея

Сценарии, связанные с батареей:

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

Айдл

Сценарии, связанные со спящим режимом девайса:

1. Если в приложении реализована функция входа в систему, можно проверить, не происходит ли выход (вылогинивание) пользователя из приложения после того, как оно перешло в фоновый режим.
2. Если у вас приложение, связанное с платежами, и например обрабатывающее платежи в фоновом режиме, то приложение должно работать без сбоев и успешно выполнять требуемые транзакции.
3. Если телефон в спящем режиме, приложение не должно сильно потреблять ресурс батареи; также можно проверить, не нагревается ли телефон в спящем режиме из-за фоновой работы приложения, это частая жалоба пользователей в сторе.
4. Что происходит если пользователь держит приложение в фоне и через какое-то время пытается открыть с того места, где он его оставил (частое «место поломки»). Это чисто технический сценарий, который лучше подробно обсудить с командой.

Блок экрана

1. Также проверим сценарии с блокировкой экрана; например, приложением запрошено получение данных, и в это время телефон пользователя блокируется; тогда приложение должно оставаться активным в фоновом режиме и успешно завершить нужную операцию.
2. Другой сценарий — если пользователь намеренно блокирует телефон во время выполнения операции, и в этом случае также нужно проверить, что операция будет успешно завершена и не будет отменена.
3. Еще один сценарий — если телефон заблокирован во время работы с приложением, проверить расход заряда батареи.

Сеть

Сценарии, связанные с подключением к Интернету/WiFi и сервисами определения местоположения:

1. Проверить, не нарушается ли работа приложения при выполнении какой-либо операции, когда интернет на телефоне отключается. В этом случае пользователю должен быть показано соответствующее сообщение.
2. Далее проверить, когда интернет появится и пользователь снова в сети, в этом случае приложение должно работать корректно и сообщение «Нет интернета» должно исчезнуть и ошибок не должно возникать.
3. Пользователь должен иметь возможность беспроблемно пользоваться приложением как при подключении к WiFi, так и к мобильному Интернету.
4. Другим способом проверки является подключение телефона к мобильному хот-споту и проверка работоспособности приложения; хотя этот сценарий не требует длительного глубокого тестирования, однако провести такой тест будет полезно.
5. Проверка режима В Самолете, поведение приложения. Если приложение имеет какую-либо зависимость, или например это приложение, связанное со смарт-часами, то устройство должно переходить в режим без ошибок, и это должно происходить плавно.
6. Аналогично, при отключении этого режима все должно вернуться в нормальное состояние при минимальном вмешательстве пользователя.
7. Включение/выключение геолокации в телефоне и проверка работы с геолокацией, соответствующие сообщения и пр.

Дисклеймер

Разумеется, этот гайд неполон. Многое зависит от специфики приложения. Но в целом таков общий план тестирования.»

Источники: 1,2

Вакансии QA Junior в Телеграме