Тестування вимог до мобільних додатків

Шпаргалка-чекліст для рев'ю ТЗ до мобільного додатку:

Загальні питання щодо додатку

• Для яких платформ розроблятиметься програма і які версії ОС будуть підтримуватися? Необхідно завжди пам'ятати про мінімальну підтримувану версію ОС. Інакше можна виявити, що функціональність не працює у користувачів, коли завдання вже закрите.

• На яких пристроях потрібно перевірити програму? Наприклад, програма має працювати як на смартфонах, так і на планшетах. Або має бути підтримка Apple Watch.

• Яку орієнтацію екранів підтримує програма? Портретна та/або ландскейп? Неприємний момент: якщо зміна орієнтації екрану добре працює на смартфонах, це не означає, що все буде на планшетах.

• На яких девайсах найпріоритетніше дивитися? На ваших девайсах програма може ідеально працювати, а ось у замовника на коханому (вставте китайський android-смартфон) все роз'їхалося...

• Має бути ідеальний піксель-перфект чи допускаються деякі похибки? Привіт тестування на відповідність макетам! Ще непогано уточнити, чи має розтягуватися верстка чи під кожен розмір екрану мають бути свої макети?

• Чи існують інші клієнтські програми? Наприклад, є адмінка, яка раптово почне видаляти чи додавати елементи. Або веб-версія, яка існує вже у продакшені. Головне - дізнатися про це якомога раніше.

• Чи є якісь зовнішні пристрої, які можуть вплинути на логіку мобільного додатку? Наприклад, beacon'и, що відправляють сигнали додатку, або принтери, що друкують інформацію з програми.

• Яка цільова аудиторія у додатку? Всі користувачі Play Market/AppStore або 50 осіб в компанії замовника?

Розбір програм по екранах

• Склад екрану та можливі дії на ньому. З яких елементів складається екран? Які дії можна зробити? Які стани можливі? Які є переходи та на які екрани вони ведуть? Що має відображатись при поверненні на цей екран? Відповіді на ці питання необхідно знайти, а краще зафіксувати у документації.

• Взаємодія із сервером на екрані. Які запити на екрані? Розуміння того, які запити на сервер надсилаються на екрані, допоможе виявити такі вимоги, які не зможе реалізувати сервер з тих чи інших причин.

• Активність за таймером. Наприклад, надсилається важлива аналітика раз на дві хвилини або відбувається оновлення даних.

• Кешування даних. Завантаження тих самих даних при кожному вході на екран може дратувати користувачів. Під час кешування необхідно продумати, коли має оновлюватись інформація на екрані? Коли має очищатись кеш?

• Заглушки. Що відображається, якщо даних немає? Порожній екран – неінформативний для користувача. А заглушка, що з'їхала, може бути приводом для невдоволення замовника.

• Поведінка у випадках помилки. Що має відображатися, якщо виникла помилка? Наприклад, відсутність інтернету, серверна чи незадокументована помилка.

• Повільне завантаження даних. Що має відбуватися під час повільного завантаження даних? Лоадер, блокування дій, кастомні анімації - все має бути продумано.

• Події, що впливають на поведінку інших екранів. Як вплив на одному екрані вплине на поведінку на інших? Наскрізні дії – небезпечна штука. Особливо, якщо розробка та тестування йде по екранах або окремих фічах. Тут без регресії обійтися важко. Тому на деяких проектах, перш ніж писати тест-кейси, ми будуємо матрицю впливу нових фіч.

• Оновлення даних на екрані. Коли відбувається оновлення? Є такі варіанти і вони можуть поєднуватися:

  • Щоразу при відкритті екрана (дані живуть лише поки у користувача відкритий екран).

  • Щоразу при запуску програми (дані живуть тільки поки у користувача запущено програму).

  • pull-to-refresh'у/за спеціальною кнопкою оновлення/по таймеру (дані зберігаються в локальному сховищі пристрою і при перезапуску програми відновлюються).

Далі розглянемо функціональність, яка часто використовується у додатках.

Навігація у додатку

• За допомогою бокового меню. Які розділи є кореневими? Які розділи відкриваються поверх кореневих? Чи скидається історія переходів між кореневими розділами?

• За допомогою таббару. Чи залишається таббар на екрані під час поглиблення навігації всередині розділу? Чи повертає на кореневий екран при повторному тапі на розділі?

• Відмінність у переходах між апаратною та програмною кнопкою «Back» в Android.

Локалізація

Види підтримуваної локалізації:

• Тексти всередині програми. Користувач у налаштуваннях програми може виставити потрібну мову.

• Тексти залежать від мови системних налаштувань. Мова визначається залежно від встановленої мови у системних налаштуваннях.

• Тексти надходять із сервера. Тексти надходять із сервера, і мова залежить або від установок пристрою, або від установок програми.

Дозволи

• Запит на доступ до нотифікацій, геолокації, галереї, камери, смс… Кастомний екран чи просто системний алерт?

• Користувач відмовився надати доступ. Як додаток поведеться в цьому випадку? Чи передбачено логіку перезапиту на доступ?

• Користувач вимкнув у системних налаштуваннях доступ (див. вище).

Списки

Часто мобільні програми включають списки. Для них варто звернути увагу на такі моменти:

• Перше завантаження списку. Скільки елементів завантажуються за один раз? Що відбувається під час завантаження? Який максимальний час може завантажуватись список?

• Наявність пейджингу. Чи є підвантаження елементів при скролі чи весь список завантажується за один раз? Якщо є підвантаження, обов'язково треба перевірити, що елементи на кордонах не пропадають і не дублюються.

• Оновлення списку (див. варіанти вище).

• Наявність розділів.

• Наявність фільтрів/сортувань. Фільтр може бути локальним чи серверним. Для списків, які завантажуються повністю або зашиті всередині програми, фільтри найчастіше локальні, і тестування їх не викликає особливих труднощів. Для списків з підвантаженням фільтри можуть спричинити велику кількість перевірок. Аналогічно для сортування.

• Склад кожного елемента у списку. Тут може бути як елементарний текст, і цілі екрани зі своєю внутрішньою логікою.

• Взаємодія із елементами. Додавання нового елемента, видалення, приховування, перетягування.

• Синхронізувати список між усіма пристроями. Як приклад можна навести синхронізацію файлів після зміни на всіх пристроях.

• Збереження позиції скролла. При переходах між розділами або повернення на екран зі списком може бути дуже важливою фічею. Наприклад, якщо це стрічка постів.

Пошук за списком

• Онлайн/оффлайн пошук. З офлайновим пошуком все просто. По суті це локальний фільтр. Для онлайнового пошуку, як і для онлайнових фільтрів, кейсів буде набагато більше.

• Посимвольний пошук або пошук натискання на кнопку пошуку. Зверніть увагу, для посимвольного пошуку повинно бути обмеження кількості запитів, інакше сервер може почати ігнорувати спам від програми.

• Очищення пошукового рядка.

• Наявність підказок.

• Наявність історії запитів.

Форма введення

• Перелік полів з їх описом та особливостями.

• Умови збереження та скидання даних у полях. Коли та які поля мають зберігати свої значення? Коли очищатись?

• Обмеження на кількість та вид символів.

• Клавіатура для введення даних вибраного поля. Вигляд клавіатури: цифровий або символьний. Чи клавіатура повинна зміщувати контент під час відкриття? За яких умов вона має закриватися?

• Логіка переходів поміж полями. За кнопкою «Далі», за «Next» на клавіатурі.

• Валідація некоректно введених даних. Перевірки на сервері чи клієнті.

• Автозапити на сервер за певних умов. Наприклад, якщо користувач запровадив 6-значний код підтвердження.

Облікові записи

• Вимоги до реєстрації та авторизації користувачів. Чи є можливість реєстрації не через мобільний додаток?

• Відновлення облікового запису. Наприклад, якщо користувач забув пароль програми.

• Логаут. Очищення даних (зокрема, скидання прив'язки пуш-нотифікацій) для облікового запису.

• Авторизація за смс-кодом. Повинні враховуватись кейси з телефонним номером, його форматом, кодом можливих країн. Перенаправлення смс у разі проблем із отриманням.

• Авторизація через соцмережі (див. подробиці нижче в розділі «Реєстрація/авторизація через соцмережі»).

• Авторизація на кількох пристроях одночасно. Автологаут або обробка синхронізації даних.

• Обробка помилки невірного, застарілого токена облікового запису.

• Зміна даних облікового запису. Наприклад, зміна пароля.

Реєстрація/авторизація через соцмережі

• Створення облікового запису за першої авторизації через соцмережу.

• Підвантаження даних із соцмережі. Синхронізація при зміні в соцмережі. Наприклад, ім'я-прізвище користувача та аватарка.

• Авторизація через мобільний додаток, соцмережі або браузер/вебв'ю.

• Заборона доступу до додатків до даних із соцмережі.

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

• Опис рольової моделі. Які дії доступні для кожної ролі?

• Взаємодія між представниками різних ролей. Взаємодія між представниками ролі.

• Перехід користувачів від ролі до іншої. Які дії повинні виконатися для цього?

• Передбачуване відсоткове співвідношення представників різних ролей. На яку роль звернути увагу насамперед?

Мапа

• Перше завантаження картки. Яка область має завантажитись? Де і в якому масштабі має бути відцентрована карта?

• Завантаження та малювання елементів. Чи повинні завантажені елементи кешуватися? Коли елементи мають бути оновлені? Цей момент дуже важливо продумати, щоб забезпечити швидке завантаження даних та плавні переміщення по карті.

• Логіка роботи елементів на карті. Піни, попапи над пінами, картки для пінів, побудова маршруту.

• Підтримка масштабування, обертання, нахилу картки.

• Оновлення геопозиції та надсилання координат поточного розташування при згорнутому додатку.

Чати

• Обробка кейсів, якщо надсилання повідомлень було за відсутності інтернет-з'єднання або при поганому інтернеті. Повторне надсилання повідомлень.

• Групові чати. Логіка додавання/видалення співрозмовників у чаті. Максимальна кількість співрозмовників.

• Статуси надсилання/отримання повідомлень. Тут краще відразу звернути увагу до групові чати. Що вважається прочитаним повідомленням у групових чатах?

• Підвантаження історії чату (див. запитання списків).

• Наявність додаткових фіч: видалення повідомлень, відображення «Користувач Х друкує», прев'ю файлів, що надсилаються, пересилання повідомлень.

• Механізм роботи чату. Наприклад, необхідно розуміти принцип роботи чату на сокетах, щоб під час тестування локалізувати баги та визначати, на чиїй стороні проблема.

Надсилання файлів на сервер та скачування на пристрій

• Формат файлів. Які формати файлів система повинна обробляти та на які видавати помилку?

• Відновлення перерваної відправки/завантаження. Автоматичне чи після підтвердження користувача?

• Максимальна кількість файлів, що відправляються/закачуються.

• Нестача пам'яті на пристрої для завантаження файлу. Насправді були випадки, коли пам'яті не вистачає, щоб не просто завантажити файл, а навіть зробити запис до бази даних. Такі проблеми доводилося опрацьовувати.

• Скасування надсилання/завантаження файлу.

• Заміна файлу один на інший.

• Завантажити на зовнішню пам'ять SD Card.

• Завантажити у фоні при згорнутому додатку.

Зовнішні пристрої

• Підключення/вимкнення пристрою. Канал зв'язку, яким воно взаємодіє з додатком (Wi-Fi/Bluetooth).

• Вплив зовнішнього пристрою на логіку програми.

• Конфігурація зовнішнього пристрою. Чи є якісь системи, які адмініструють зовнішній пристрій?

• Максимальна відстань, на якій відбувається взаємодія.

• Сила/потужність сигналу. Чи з'ясуйте, від чого можуть залежати ці параметри? Наприклад, якщо beacon сховати у металеву банку, то шанси на втрату його сигналу різко зростає.

• Підключення кількох зовнішніх пристроїв одночасно. Наприклад, перемикання з одного пристрою на інший може призвести до цікавих кейсів.

• Підключення до зовнішнього пристрою за допомогою згорнутої програми/заблокованого екрана.

Аудіоплеєр/відеоплеєр

• Формати файлів, що підтримуються.

• Кешування контенту, що програється. Обов'язково потрібно зрозуміти, який обсяг даних необхідно кешувати для зручності користувача.

• Програвання на тлі. Чи потрібне підвантаження даних при згорнутому додатку?

• Нотифікація плеєра у системній шторці.

• Інтеграція з Bluetooth-гарнітурою, CarPlay та іншими зовнішніми системами.

Оплата банківською карткою

• Прив'язка до профілю та видалення банківської картки. Чи є тестове зняття мінімальної суми? Наприклад, 1 рубль, який потім повернеться на рахунок.

• Оплата прив'язаною карткою. Наприклад, чи буде повторний запит на підтвердження під час наступних оплат?

• Обробка помилок під час спроби прив'язати/сплатити по карті.

• Синхронізація списку карток за наявності кількох клієнтів у системі. Наприклад, є веб-версія та є iOS-версія.

• Сканування через камеру та розпізнавання номера картки.

Час, календар, таймер

• Календар/час. Чи впливає на логіку програми некоректно виставлена ​​дата та час? Чи можна вибрати період? Яка область припустимих значень?

• таймер. Локальний/серверний? Як відбувається синхронізація серверного таймера? Наприклад, Android додаток може орієнтуватися не на час, встановлений на пристрої, а на час запуску пристрою. Як би користувач не переводив годинник у системних налаштуваннях, таймер не зіб'ється.

Нотифікації

• Вид нотифікацій. Чи є нотифікації на певні події, які зашиті у додаток? Або push-нотифікації, які надсилає сервер?

• Дії, доступні при нотифікації. Що буде, якщо перейти за нотифікацією? Закрити її? Що якщо застаріла нотифікація і вона недоступна?

• Прив'язка нотифікацій до певного обліку. Які дії вказують серверу, що користувач вийшов і зайшов інший?

Джерела:

• Шпаргалка з тестування вимог до мобільних додатків