Блог A1QA

О тестировании и качестве ПО

Обеспечиваем качество мобильных приложений. Шаг 2: Планирование тестовых активностей

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

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

  • Назначайте на проект инженеров с реальным опытом тестирования мобильных приложений.
  • Если таких нет, проведите предварительное обучение сотрудников.
  • Плюсом будет также привлечение эксперта-консультанта, который сможет помочь решить вопросы по специфике тестирования мобильных приложений.
  • Рекомендуем специалистам до начала тестирования ознакомиться с аналогичными приложениями. Это поможет получить основное представление, о том, как должны функционировать приложения данного типа.

Готовим тестовую документацию

После того как команда по тестированию собрана и обучена, приступаем к подготовке тестовой документации.

Создание документации значительно улучшает качество продукта за счет уточнения деталей и списка проверок. После завершения тестирования наличие тестовой документации позволяет оценить, насколько успешно были проведены все этапы тестирования.

Существует несколько типов тестовой документации:

Acceptance Sheet (иногда также называется Checklist) – документ, который содержит подробный перечень всех модулей и функций приложения, а также результаты всех тестов данных функций. Как правило, Acceptance Sheet содержит статистику по наиболее важным показателям каждой сборки (билда), определяющим ее качество.

Test Survey – документ, который содержит подробный перечень всех проверок для отдельных функциональностей, а также ожидаемый результат проверок.

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

Выбор документации зависит от продолжительности и сложности проекта и должен быть предварительно согласован с заказчиком.

Тип документации Что описываем? Когда используем?

Пример

 

Acceptance Sheet

Перечень функциональностей, которые нужно протестировать. На краткосрочных проектах с простой бизнес-логикой.  

Форма входа на сайт.

 Test Survey

Конкретные проверки в рамках отдельных функциональностей. Может содержать ожидаемый результат. На проектах средней продолжительности с понятной бизнес-логикой. Форма входа на сайт:

  • Ввод корректных данных;
  • Ввод некорректного имени;
  • Ввод некорректного пароля;
  • и т.д.

 Test Cases

Порядок выполнения и результат тестов.  

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

Форма входа на сайт:

  • Откройте форму входа;
  • Введите имя пользователя test1;
  • Введите пароль test1;
  • Нажмите кнопку «Войти».

Ожидаемый результат: пользователь попадает на домашнюю страницу.

Вне зависимости от типа документации, она должна содержать все необходимые проверки для всех сценариев использования приложения. Но также не стоит забывать о проверках, диктуемых особенностями мобильных устройств.

В частности рекомендуем проверить следующие аспекты:

  • Установка, запуск, удаление, обновление приложения.
  • Изменение ориентации экрана.
  • Различные виды соединений и переключения между ними.
  • Прерывание работы приложения.
  • Графический интерфейс пользователя и навигация.
  • Уведомления в приложении.
  • Работа с использованием разных физических кнопок.
  • Контроль данных: сохранение, использование, удаление.
  • Работа приложения в режиме энергосбережения.

Поясним, для чего необходимы эти проверки. Например, при тестировании приложения с использованием различных типов Интернет-соединения (2G/3G/4G/Wi-Fi) вы можете обнаружить неверную обработку потери соединения и неполную загрузку форм при медленном соединении.

Другой пример – проверка реакции приложения на различные прерывания. Иногда это приводит к аварийному завершению работы и потере введенных данных.

Как не упустить из памяти все эти проверки? Рекомендуем использовать интеллект-карты, или mindmaps, позволяющие наглядно структурировать все виды проверок.

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

Поэтому если заказчик хочет передать напрямую файл, попросите его сделать это через какой либо файлообменник (например, Dropbox или Google Drive). Но гораздо удобнее использовать сервис дистрибуции приложений, например, HockeyApp, iTunes Connect, Crashlytics, Ubertesters.

Одно из главных преимуществ подобных сервисов – это удобство организации, т.к. заказчику достаточно будет лишь передать ваш аккаунт, после добавления которого в тот или иной сервис вам станет доступен билд.

Другое важное преимущество – это возможность видеть историю билдов и любую из предыдущих сборок. Некоторые из них позволяют автоматически отправлять баг-репорты, когда, например, приложение крэшится. Стоимость использования данных сервисов вполне приемлемая.

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

Итак, мы завершили еще один из самых важных этапов нашего проекта. Давайте немного подытожим, что мы уже сделали:

  • Получили ответы от заказчика на все вопросы.
  • Знаем, на каких устройствах будем проводить тесты.
  • Определили, какую тестовую документацию будем использовать.
  • Выяснили, сколько времени уйдет на тестирование.
  • Оговорили доставку билдов с заказчиком.
  • Распределили роли на проекте.

Все готово к началу тестирования. О нем расскажем в следующей статье.

Поделиться статьей: