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

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

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

Для прикладу розглянемо вхід/вихід та створення контакту (розділ, користувач або будь-який інший елемент).

Стандартний вхід/вихід передбачає наступні опції:

• реєстрація: з логіном і паролем, без пароля, через соціальні мережі тощо;
• авторизація: за допомогою логіну та паролю, через соціальні мережі тощо;
• відновлення пароля;
• вихід із системи: самостійний, по закінченню сесії тощо.

Позитивні сценарії:

• реєстрація в додатку доступна всіма описаними в тестовому завданні способами;
• зареєструватися можна, заповнивши лише обов’язкові поля;
• зареєструватися можна, заповнивши всі передбачені поля;
• користувач може авторизуватися в додатку після реєстрації. При цьому введені дані (e-mail, пароль, особиста інформація тощо) коректно зберігаються в профілі;
• після реєстрації на одному пристрої можна зареєструватися на іншому - дані успішно зберігаються на сервері і стають доступними;
• вихід з системи працює коректно;
• відновлення пароля працює належним чином.

Негативні сценарії (найочевидніші):

• повторна реєстрація з тим самим e-mail або логіном неможлива;
• реєстрація без заповнення обов’язкових полів недоступна;
• реєстрація з незаповненими полями неможлива;
• реєстрація з даними у форматі, що не відповідає вимогам, недоступна;
• авторизація з порожніми полями неможлива;
• авторизація з неправильним/видаленим/заблокованим логіном недоступна;
• авторизація з неправильним паролем неможлива.

Створення контакту

Логічно припустити, що якщо користувач створює контакт, то він повинен мати можливість переглядати, редагувати та видаляти його. Це базовий набір функцій, які може оцінити елемент.

Позитивні сценарії:

• доступні створення, оновлення, перегляд і видалення контактів;
• можливе створення контакту з мінімальним та максимальним набором даних;
• при створенні точно обробляються всі типи даних, описані в тестовому завданні;
• контакт доступний для перегляду після створення;
• update враховує обов’язкові поля/дані/елементи - без них зберегти контакт неможливо;
• контакт недоступний після видалення.

Негативні сценарії:

• створення двох однакових контактів недоступне (це також можна розглядати як позитивний сценарій);
• створення контакту з відсутніми обов’язковими елементами/даними неможливе.

Тестування графічного інтерфейсу також можна віднести до функціонального тестування:

• тестування екранів на відповідність макетам;
• перевірка роботи “рідних” жестів: свайп, мультитач тощо - додаток повинен реагувати на них певним чином;
• перевірка стану елементів: кнопки змінюють колір при натисканні, списки розгортаються та згортаються тощо;
• Сервіси тестування локалізації можуть бути задіяні, якщо додаток містить більше ніж одну мовну локалізацію. При цьому важливо звертати увагу на верстку - багато назв іноземними мовами відображаються довше, ніж англійською або російською.