Тест-план для мобильных приложений

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

Скачать одну из самых популярных книг по тестированию "Как тестируют в Google"

1. Введение

1.1 Обзор

План тестирования – это документ, описывающий объем, стратегию, цели, график тестирования и необходимые ресурсы для его выполнения. Он служит руководством по тестированию на протяжении всего процесса разработки.

1.2 Область применения

Объем работ определяется в начале процесса тестирования. Команда проекта должна четко понимать, какие возможности и функции подлежат тестированию, а какие выходят за рамки. Для определения объема тестирования необходимо учитывать спецификацию проекта, бюджет и требования заказчика.

1.3 Референсы

Этот раздел содержит документы, которые поддерживают план тестирования и на которые можно ссылаться в процессе тестирования. Обычно в этот список входят:

  • План проекта
  • Системные требования
  • Спецификация дизайна проекта

1.4 Сокращения и аббревиатуры

Все аббревиатуры, используемые в Плане тестирования, требуют пояснений. Например:

  • DDD (Database design document) – документ проектирования базы данных
  • СМК (Quality Management System) – система менеджмента качества
  • SLC (Software life cycle) – жизненный цикл программного обеспечения

2. План и стратегия тестирования

2.1 Модульное тестирование

2.1.1 Цель

Основная цель модульного тестирования (также юнит-тестирование) — проверить, работает ли каждый модуль так, как задумано. Отдельным модулем может считаться функция, процедура или метод. Юнит-тестирование может проводиться вручную, но более распространенной практикой является автоматизированное тестирование.

2.1.2 Входные критерии

  • Этап планирования завершен
  • Имеются тестируемые устройства
  • Определены все функциональные требования
  • Среда тестирования создана

2.1.3 Выходные критерии

  • Все запланированные тест-кейсы пройдены
  • Все найденные дефекты рассмотрены
  • Проверена работоспособность ключевых модулей

2.1.4 Протоколирование тестов и отчетность

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

2.2 Системное тестирование

2.2.1 Цель

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

2.2.2 Процедура тестирования

  • Подготовка тест-кейсов
  • Проведение тестирования
  • Сообщение о дефекте

2.2.3 Типы системного тестирования

2.2.3.1 Тестирование производительности

Тестирование производительности проводится для выявления проблем, связанных с:

  • Потребление памяти
  • Использование мощности
  • Сетевое подключение
  • Работа в фоновом режиме
  • Переключение между приложениями
  • Утечка памяти

2.2.3.2 Тестирование прерываний

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

2.2.3.3 Тестирование удобства использования

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

2.2.3.4 Тестирование установки и запуска

Тестирование установки направлено на выявление проблем в процессе инсталляции, деинсталляции и обновления. После установки приложения инженер по контролю качества также проверяет процесс запуска приложения.

2.2.3.5 Функциональное тестирование

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

2.2.3.5 Тестирование безопасности

Тестирование безопасности проводится для поиска уязвимостей приложения и предотвращения утечки данных.

2.2.3.6 Регрессионное тестирование

Регрессионное тестирование – это повторное выполнение тестов, которые были сделаны до внесения изменений в код. Его цель – проверить, повлияла ли новая функциональность на существующую.

2.3 Условия прохождения/провала тестирования

Определены и описаны все условия, при которых тесты проходят или не проходят.

2.4 Отчет о тестировании

Отчет о тестировании помогает подвести итоги работы в формальном виде. Он должен содержать:

  • Название и обзор приложения
  • Окружение тестирования аппаратного и программного обеспечения
  • Количество выполненных/пройденных/не пройденных тест-кейсов

Для каждого обнаруженного дефекта приводится следующая информация:

  • Описание дефекта
  • Статус дефекта (открыт, исправлен и т. д.)
  • Местоположение дефекта
  • Шаги для воспроизведения

3. График тестирования

Графики, создаваемые менеджерами проекта, помогают контролировать процесс тестирования.

4. Риски и допущения

4.1 Риски

В процессе тестирования мобильных приложений могут возникнуть следующие риски:

  • Доступность устройств
  • Новые функции и модификации, которые не были запланированы заранее
  • Изменения в требованиях
  • Задержки в графике

4.2 Допущения

  • Каждый релиз сопровождается примечанием с информацией о реализованных функциях и их влиянии на систему
  • Все блокирующие баги получают статус высокого приоритета
  • Все найденные баги исправляются до выхода следующего релиза программы
  • Все документы обновляются и своевременно доставляются команде тестирования
  • Все необходимое оборудование и инструменты предоставлены и готовы к испытаниям
  • График тестирования пересматривается в случае возникновения каких-либо препятствий для тестирования

5. Входные и выходные критерии

5.1 Входные критерии

  • Этап разработки завершен
  • Определены и утверждены требования
  • Разработан план тестирования
  • Пройден этап тест-дизайна
  • Тестовая среда создана
  • Имеются все необходимые ресурсы

5.2 Выходные критерии

  • Тест-кейсы пройдены
  • Процент пройденных тестов удовлетворительный, например, 95%
  • Провалившиеся тест-кейсы не связаны с критически важной функциональностью
  • Результаты тестов приняты
  • Критические дефекты устранены

6. Метрики тестирования

Метрики тестирования — это количественные показатели, которые помогают оценить усилия по тестированию. Наиболее распространенными метриками являются:

  • Покрытие требований
  • Покрытие тест-кейсами
  • Количество выполненных тестов
  • Количество найденных дефектов (с учетом их приоритетности и серьезности)
  • Затраченные усилия на тест-дизайн
  • Общая трудоемкость тестирования

7. Регистрация тестов и составление отчетов

Каждую обнаруженную проблему необходимо должным образом задокументировать с помощью специальных инструментов и приложений.

8. Роли и обязанности

Роли и обязанности проекта должны быть четко определены и распределены между сотрудниками проекта. Обычно роли распределяются следующим образом:

8.1 Менеджер проекта

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

8.2 Тест-лид

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

8.3 Инженер по тестированию

Инженер по тестированию отвечает за подготовку и выполнение тест-кейсов, а также за составление отчетов о дефектах.

9. Поставляемые материалы

Список всех материалов обычно содержит:

  • Тест-план
  • Тест-кейсы
  • Стратегия тестирования
  • Результаты тестирования
  • Итоговый отчет

Перевод статьи «Test Plan for Mobile App Testing».

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *