Это первый текст на канале, так что сначала я хочу представиться: вряд ли кто-то всерьез будет прислушиваться к анониму, даже если он весь из себя экспертный эксперт. Итак, привет, я - Женя Шаповалов, Senior Android/Flutter Developer в компании Innowise (и хэд mobile department там же). В мобильной разработке я с 2015 года, начинал с Android, а за Flutter мы принялись вместе с коллегами в Innowise - да так мощно, что в итоге в компании появилось отдельное направление разработки.

Ну что, вроде бы заслуживаю доверия? Тогда погнали!

Сегодня рассказываю, как правильно тестировать код,  и делимся личным опытом. Да-да, ты все понял верно: при разработке мобильных приложений тестирование проводит не только QA-инженер, но и сам автор кода. Причем не только в самом конце, когда приложение почти готово, но и в процессе. Мы сегодня рассмотрим оба этапа. 

Логика компонентов

Что проверяем: реализованная логика должна соответствовать описанной в задаче. Так что уделяем внимание и логике работы внутри приложения, и его взаимодействию с источниками данных и внешними компонентами. А именно:

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

1.1.1 Проверяем корректность данных в приложении (с помощью сопоставления данных в Postman или сборки противоположной платформы).

1.1.2 Тестируешь взаимодействие приложения с локальной базой данных? Используй внешний инструмент (DB Browser for SQLite) для управления базой данных. Это ускорит работу с SQL-запросами.

1.1.3 При тестировании взаимодействия с системным компонентом / внешним приложением (Внешний Браузер, Галерея, Камера, Почтовый клиент, ...) удели внимание следующим ситуациям:

• СК / ВП недоступны из приложения

• СК / ВП доступны с определённой версии OS

• СК / ВП вернули отрицательный результат

• СК / ВП вернули положительный результат

1.1.4 Важно, чтобы приложение правильно реагировало на внешние факторы и действия пользователя со стеком приложений:

1. Foreground-состояние:

1.1. Свернуть приложение в Background

1.2. Вернуть приложение в Foreground (через Task Manager и иконку приложения)

1.3. Остановка приложения и его перезапуск

1.4. Взаимодействие с Home кнопкой

2. Изменение скорости интернет-подключения:

2.1. Переход с WiFi на Mobile Data и обратно

2.2. Изменение скорости сети с 4G, 3G, 2G

3. Прерывание работы внешними ивентами:

3.1. Входящий вызов

3.2. SMS

3.3. Push-notification

UI

Что проверяем: верстку экрана. 

1.2.1 Она должна полностью совпадать с макетом:

• отступы

• шрифты

• цвета

• расположение элементов относительно друг друга

1.2.2 Верстка экрана проверяется на девайсах разных размеров (минимальном и максимальном):

• Android -> [ 540 × 960 - ... ]

• iOS -> [ 750 × 1334 - ... ]

1.2.3 Вёрстку экрана необходимо протестировать во всех возможных реализациях:

• портретная ориентация

• горизонтальная ориентация

• планшетная версия

• экран часов

UX

Что проверяем: реализацию экрана с точки зрения удобства для пользователя.

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

1.3.1 Случаи, когда экран становится неинтерактивным:

• Touch-event игнорируется

• Экран заблокирован и недоступен для взаимодействий (по причине прогресса, который не скрылся)

• Часть экрана перекрывает виджеты для ввода информации

1.3.2 При тестировании логики загрузки данных на экране необходимо проверить, что обработаны все необходимые состояния экрана:

• Прогресс первой загрузки

• Ошибки запроса

• Обновление данных

• Постраничная загрузка

• Пустое состояние экрана

1.3.3 При заполнении экрана контентом он должен быть отрисован в понятном и удобном для пользователя виде:

• Длинный текст усекается

• Вместо пустых блоков используются поясняющие описания

• В виджетах ввода есть подсказки

• В виджетах выбора есть первоначальное значение

1.3.4 При тестировании запросов и логики валидации данных проверяем, чтобы все состояния ошибок обработаны и понятны пользователю:

• Показывается сообщение о серверной ошибке

• Подсвечивается неправильно введенное поле

• При 401 ошибке происходит закрытие сессии пользователя

• Отсутствует подключение к интернету

• Что-то пошло не так :)

1.3.5 Если есть поля ввода, удостоверься, что пользователю удобно вводить текст:

• Поле для ввода email имеет @ /.com

• Поле для ввода password маскирует текст и позволяет просмотреть его

• Поле для ввода большого текста расширяется

• Поле для ввода цифрового кода не позволяет ввести что-нибудь, кроме цифр

• Между полями создана фокусная связь перехода

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

1.3.6. Тестируешь состояния виджетов действий? Убедись, что они обновляют свои состояния:

• При вводе правильного текста изменяется состояние enabled

• При нажатии изменяется состояние pressed/clicked

1.3.7 При тестировании локализации проверь, что приложение поддерживает требуемый набор языков:

• Статичные лейблы изменяются в зависимости от локали девайса

• Динамичные лейблы (ответы сервера, всплывающие подсказки) локализованы корректно

• При изменении языка внутри приложения статичные лейблы обновляются

1.3.8 Тестирование работы с системными компонентами требует проверки приложения на наличие permissions:  

• Permissions запрашиваются только тогда, когда это необходимо

• Перед использованием компонентов запрашиваются Permissions

• Кейс, когда пользователь сначала предоставил Permissions, а потом отозвал

• Обработано состояние, когда пользователь не предоставляет Permissions

• Показано пояснение, почему приложению необходимы данные Permissions

1.3.9 При тестировании функциональности приложения, которая доступна с определённой версии системы, проверь, что обработаны следующие состояния:

• Приложение не крэшится на версии, где этой функциональности нет

• Приложение показывает сообщение, что эта функциональность недоступна

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

Тестирование билда

Когда приложение более-менее готово, а ты вроде бы не прочь показать его миру ⎼ наступает время проверять сборку. Что надо тестировать на этом этапе? 

2.1.1 Файл сборки (.apk, .ipa) обязан быть рабочим и без проблем устанавливаться на любой девайс. Приложение не должно содержать явных крэшей, которые можно воспроизвести очень просто.

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

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

2.1.3 При подготовке сборки для релиза проводится регрессионное тестирование: поэтапная проверка основной функциональности приложения на корректность работы.

2.1.4 Приложение имеет правильное название, иконку и логотип, а минимальная версия соответствует заявленной.

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

Нужно по максимуму использовать девайсы от различных компаний: Apple, Huawei, Samsung, Lenovo, HTC, Nokia и пр. 

2.1.6 Если приложение содержит личные данные пользователя, ты обязан проверить, что при удалении приложения данные исчезают из файловой системы.