Шпаргалка по тестированию требований к мобильным приложениям

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

Статья ориентирована на тестировщиков, которых просят провести ревью ТЗ и найти в нём несоответствия, и на аналитиков, которым разработчики после прочтения ТЗ часто задают вопросы формата: «А что должно быть, если …?».

Итак, с чего начать?

Общие вопросы по приложению

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

1. Для каких платформ будет разрабатываться приложение и какие версии ОС будут поддерживаться? Необходимо всегда помнить о минимальной поддерживаемой версии ОС. Иначе можно обнаружить, что функциональность не работает у пользователей, когда задача уже закрыта.
2. На каких устройствах необходимо проверить приложение? Например, приложение должно работать как на смартфонах, так и на планшетах. Или должна быть поддержка Apple Watch.
3. Какую ориентацию экранов поддерживает приложение? Портретная и/или ландскейп? Неприятный момент: если смена ориентации экрана хорошо работает на смартфонах, это не значит, что всё будет так же на планшетах.
4. На каких девайсах приоритетнее всего смотреть? На ваших девайсах приложение может идеально работать, а вот у заказчика на любимом (вставьте китайский android-смартфон) все разъехалось...
5. Должен быть идеальный пиксель-перфект или допускаются некоторые погрешности? Привет, тестирование на соответствие макетам! Ещё неплохо уточнить, должна ли растягиваться вёрстка или под каждый размер экрана должны быть свои макеты?
6. Существуют ли другие клиентские приложения? Например, есть админка, которая внезапно начнет удалять или добавлять элементы. Или веб-версия, которая существует уже в продакшене. Главное – узнать об этом как можно раньше.
7. Есть ли какие-то внешние устройства, которые могут повлиять на логику мобильного приложения? Например, beacon'ы, отправляющие сигналы приложению, или принтеры, печатающие информацию из приложения.
8. Какая целевая аудитория у приложения? Все пользователи в Play Market/AppStore или 50 человек в компании заказчика?

Разбор приложения по экранам

1. Состав экрана и возможные действия на нем. Из каких элементов состоит экран? Какие действия можно совершить? Какие состояния экрана возможны? Какие есть переходы и на какие экраны они ведут? Что должно отображаться при возврате на этот экран? Ответы на эти вопросы необходимо найти, а лучше зафиксировать в документации.
2. Взаимодействие с сервером на экране. Какие запросы идут на экране? Понимание того, какие запросы на сервер отправляются на экране, поможет выявить такие требования, которые не сможет реализовать сервер по тем или иным причинам.
3. Активность по таймеру. Например, отправляется важная аналитика раз в две минуты или идет обновление данных.
4. Кэширование данных. Загрузка одних и тех же данных при каждом входе на экран может раздражать пользователей. При кэшировании необходимо продумать, когда должна обновляться информация на экране? Когда должен очищаться кэш?
5. Заглушки. Что отображается, если данных нет? Пустой экран – неинформативный для пользователя. А съехавшая заглушка может быть поводом для недовольства заказчика.
6. Поведение в случаях ошибки. Что должно отображаться, если произошла ошибка? Например, отсутствие интернета, серверная или незадокументированная ошибка.
7. Медленная загрузка данных. Что должно происходить при медленной загрузке данных? Лоадеры, блокировка действий, кастомные анимации – всё должно быть продумано.
8. Действия, которые влияют на поведение других экранов. Как действие на одном экране повлияет на поведение на других? Сквозные действия – опасная штука. Особенно, если разработка и тестирование идет по экранам или по отдельным фичам. Тут без регрессии обойтись сложно. Поэтому на некоторых проектах, прежде чем писать тест-кейсы, мы строим матрицу влияния для новых фич.
9. Обновление данных на экране. Когда происходит обновление? Есть следующие варианты и они могут сочетаться:
   • Каждый раз при открытии экрана (данные живут только пока у пользователя открыт экран).
   • Каждый раз при запуске приложения (данные живут только пока у пользователя запущено приложение).
   • По pull-to-refresh'у/по специальной кнопке обновления/по таймеру (данные хранятся в локальном хранилище устройства и при перезапуске приложения восстанавливаются).

Далее рассмотрим функциональность, которая часто используется в приложениях.

Навигация в приложении

1. С помощью бокового меню. Какие разделы являются корневыми? Какие разделы открываются поверх корневых? Сбрасывается ли история переходов между корневыми разделами?
2. С помощью таббара. Остаётся ли таббар на экране при углублении по навигации внутри раздела? Возвращает ли на корневой экран при повторном тапе на разделе?
3. Различие в переходах между аппаратной и программной кнопкой «Back» в Android.

Локализация

Виды поддерживаемой локализации:

1. Тексты зашиты внутри приложения. Пользователь в настройках приложения может выставить необходимый язык.
2. Тексты зависят от языка в системных настройках. Язык определяется в зависимости от установленного языка в системных настройках.
3. Тексты приходят с сервера. Тексты приходят с сервера, и язык зависит либо от настроек устройства, либо от настроек приложения.

Разрешения

1. Запрос на доступ к нотификациям, геолокации, галерее, камере, смс… Кастомный экран или просто системный алерт?
2. Пользователь отказался предоставить доступ. Как приложение поведет себя в этом случае? Предусмотрена ли логика перезапроса на доступ?
3. Пользователь отключил в системных настройках доступ (см. пункт выше).

Списки

Часто мобильные приложения включают в себя списки. Для них стоит обратить внимание на следующие моменты:

1. Первая загрузка списка. Сколько элементов загружаются за один раз? Что происходит при загрузке? Какое максимальное время может загружаться список?
2. Наличие пэйджинга. Есть ли подгрузка элементов при скролле или весь список загружается за раз? Если есть подгрузка, то обязательно надо проверить, что элементы на границах не пропадают и не дублируются.
3. Обновление списка (см. варианты выше).
4. Наличие разделов.
5. Наличие фильтров/сортировок. Фильтр может быть локальным или серверным. Для списков, которые загружаются целиком или зашиты внутри приложения, фильтры чаще всего локальные, и тестирование их не вызывает особых трудностей. Для списков с подгрузкой фильтры могут повлечь большое количество проверок. Аналогично для сортировок.
6. Состав каждого элемента в списке. Тут может быть как элементарный текст, так и целые экраны со своей внутренней логикой.
7. Взаимодействие с элементами. Добавление нового элемента, удаление, скрытие, перетаскивание.
8. Синхронизация списка между всеми устройствами. В качестве примера можно привести синхронизацию файлов после его изменения на всех устройствах.
9. Сохранение позиции скролла. При переходах между разделами или при возвращении на экран со списком может быть очень важной фичей. Например, если это лента постов.

Поиск по списку

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

Форма ввода

1. Перечень полей с их описанием и особенностями.
2. Условия сохранения и сброса данных в полях. Когда и какие поля должны сохранять свои значения? Когда очищаться?
3. Ограничения на количество и вид символов.
4. Клавиатура для ввода данных по выбранному полю. Вид клавиатуры: цифровая или символьная. Должна ли клавиатура сдвигать контент при открытии? При каких условиях она должна закрываться?
5. Логика переходов между полями. По кнопке «Далее», по «Next» на клавиатуре.
6. Валидация некорректно введенных данных. Проверки на сервере или на клиенте.
7. Автозапросы на сервер при определенных условиях. Например, если пользователь ввел 6-значный код подтверждения.

Учетные записи

1. Требования к регистрации и авторизации пользователей. Есть ли возможность регистрации не через мобильное приложение?
2. Восстановление учетной записи. Например, если пользователь забыл пароль от приложения.
3. Логаут. Очистка данных (в частности, сброс привязки пуш-нотификаций) для учетной записи.
4. Авторизация по смс-коду. Должны учитываться кейсы с телефонным номером, его форматом, кодом возможных стран. Переотправка смс в случае проблем с получением.
5. Авторизация через соцсети (см. подробности ниже в разделе «Регистрация/авторизация через соцсети»).
6. Авторизация на нескольких устройствах одновременно. Автологаут или обработка синхронизации данных.
7. Обработка ошибки неверного, устаревшего токена учетной записи.
8. Изменение данных учетной записи. Например, смена пароля.

Регистрация/авторизация через соцсети

1. Создание учетной записи при первой авторизации через соцсеть.
2. Подгрузка данных из соцсети. Синхронизация при их изменении в соцсети. Например, имя-фамилия пользователя и аватарка.
3. Авторизация через мобильное приложение, соцсети или браузер/вебвью.
4. Запрет доступа приложению к данным из соцсети.

Ролевая модель

1. Описание ролевой модели. Какие действия доступны для каждой роли?
2. Взаимодействие между представителями разных ролей. Взаимодействие между представителями одной роли.
3. Переход пользователей от одной роли к другой. Какие действия для этого должны выполниться?
4. Предполагаемое процентное соотношение представителей разных ролей. На какую роль обратить внимание в первую очередь?

Карта

1. Первая загрузка карты. Какая область должна загрузиться? Где и в каком масштабе должна быть отцентрирована карта?
2. Загрузка и отрисовка элементов. Должны ли загруженные элементы кэшироваться? Когда элементы должны обновляться? Этот момент очень важно продумать, чтобы обеспечить быструю загрузку данных и плавные перемещения по карте.
3. Логика работы элементов на карте. Пины, попапы над пинами, карточки для пинов, построение маршрута.
4. Поддержка масштабирования, вращения, наклона карты.
5. Обновление геопозиции и отправка координат текущего местоположения при свернутом приложении.

Чаты

1. Обработка кейсов, если отправка сообщений была при отсутствии интернет-соединения или при плохом интернете. Повторная отправка сообщений.
2. Групповые чаты. Логика добавления/удаления собеседников в чате. Максимальное количество собеседников.
3. Статусы отправки/получения сообщений. Тут лучше сразу обратить внимание на групповые чаты. Что считается прочитанным сообщением в групповых чатах?
4. Подгрузка истории чата (см. вопросы для списков).
5. Наличие дополнительных фич: удаление сообщений, отображение «<Вставь_имя> печатает», превью отправляемых файлов, пересылки сообщений.
6. Механизм работы чата. Например, необходимо понимать принцип работы чата на сокетах, чтобы во время тестирования локализовывать баги и определять, на чьей стороне проблема.

Отправка файлов на сервер и скачивание на устройство

1. Формат файлов. Какие форматы файлов система должна обрабатывать и на какие выдавать ошибку?
2. Возобновление прерванной отправки/скачивания. Автоматическое или после подтверждения пользователя?
3. Максимальное количество отправляемых/закачиваемых файлов.
4. Нехватка памяти на устройстве для скачивания файла. На практике были случаи, когда памяти не хватает, чтобы не просто скачать файл, а даже сделать запись в базу данных. Такие проблемы приходилось обрабатывать.
5. Отмена отправки/скачивания файла.
6. Замена файла один на другой.
7. Скачивание на внешнюю память SD Card.
8. Скачивание в фоне при свернутом приложении.

Внешние устройства

1. Подключение/отключение устройства. Канал связи, по которому оно взаимодействует с приложением (Wi-Fi/Bluetooth).
2. Влияние внешнего устройства на логику приложения.
3. Конфигурация внешнего устройства. Есть ли какие-то системы, которые администрируют внешнее устройство?
4. Максимальное расстояние, на котором происходит взаимодействие.
5. Сила/мощность сигнала. Выясните, от чего могут зависеть эти параметры? Например, если beacon спрятать в металлическую банку, то шансы на потерю его сигнала резко возрастает.
6. Подключение нескольких внешних устройств одновременно. Например, переключение с одного устройства на другое может привести к любопытным кейсам.
7. Подключение к внешнему устройству при свёрнутом приложении/при заблокированном экране.

Аудиоплеер/видеоплеер

1. Поддерживаемые форматы файлов.
2. Кэширование проигрываемого контента. Обязательно нужно понять, какой объем данных необходимо кэшировать для удобства пользователя.
3. Проигрывание в фоне. Нужна ли подгрузка данных при свернутом приложении?
4. Нотификация плеера в системной шторке.
5. Интеграция с Bluetooth-гарнитурой, CarPlay и с другими внешними системами.

Оплата банковской картой

1. Привязка к профилю и удаление банковской карты. Есть ли тестовое снятие минимальной суммы? Например, 1 рубль, который потом вернется на счет.
2. Оплата привязанной картой. Например, будет ли повторный запрос на смс-подтверждение при последующих оплатах?
3. Обработка ошибок при попытке привязать/оплатить по карте.
4. Синхронизация списка карт при наличии нескольких клиентов в системе. Например, есть веб-версия и есть iOS-версия.
5. Сканирование через камеру и распознавание номера карты.

Время, календарь, таймер

1. Календарь/время. Влияет ли на логику приложения некорректно выставленная дата и время? Можно ли выбрать период? Какая область допустимых значений?
2. Таймер. Локальный/серверный? Как происходит синхронизация серверного таймера? Например, в Android приложение может ориентироваться не на время, установленное на устройстве, а на время запуска устройства. Как бы пользователь не переводил часы в системных настройках, таймер не собьется.

Нотификации

1. Вид нотификаций. Есть ли нотификации на определенные события, которые зашиты в приложение? Или push-нотификации, которые присылает сервер?
2. Действия, которые доступны при нотификации. Что будет, если перейти по нотификации? Закрыть её? Что если нотификация устарела и она недоступна?
3. Привязка нотификаций к определенной учетке. Какие действия указывают серверу, что один пользователь вышел и зашел другой?

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

Автор: dontspeaker

Источник