В данной статье мы подробно разберем порядок и основные аспекты, касающиеся составления тест-плана для тестирования мобильных приложений.
Скачать одну из самых популярных книг по тестированию "Как тестируют в 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».