Планирование тестирования
В прошлых уроках вы узнали о тест-кейсах и скриптах, которые тестировщики пишут для выполнения тестов. Тест-кейсы и скрипты — составляющие плана тестирования, о котором поговорим в этом уроке.
План тестирования
Для того чтобы тестирование прошло максимально эффективно, его нужно хорошо спланировать. И для этого недостаточно просто составить тест-кейсы и скрипты. Если тестировщики будут проходить тесты в хаотичном порядке, они рискуют упустить важные детали, например:
- не проверить важную функциональность продукта;
- пропустить ошибки;
- не зафиксировать и не воспроизвести найденную ошибку.
Поэтому любое тестирование начинается с разработки плана тестирования. План тестирования или тест-план (test plan) — это документ, который описывает весь объём работ по тестированию, включая объект тестирования, цели, участников и результаты.
Тест-план отвечает на вопросы:
- Что тестируем? Тестировать можно как весь продукт, так и отдельные его функциональности. Тест-план позволяет задать рамки тестирования.
- Зачем тестируем? В тест-плане фиксируются цели и ожидаемые результаты выполнения тестов.
- Когда тестируем? В тест-плане фиксируются даты тестирования, что помогает команде контролировать сроки этого этапа.
- Как тестируем? Тест-кейсы и тестовые скрипты определяют шаги, которые необходимо выполнить в процессе тестирования.
В конечном итоге план тестирования позволяет документировать и систематизировать процесс тестирования, то есть помогает не упустить важные детали.
Когда составлять план тестирования
В зависимости от выбранной модели разработки тест-план может быть составлен на разных этапах жизненного цикла продукта:
- до этапа разработки;
- после разработки;
- параллельно с разработкой.
Если план тестирования составлен до разработки, то разработчики могут ориентироваться на тест-кейсы из плана тестирования при написании кода и учесть указанные кейсы. Если план тестирования составлен после разработки, то он используется для тестирования продукта — это помогает понять, прошёл ли продукт проверку и можно ли его выпускать.
Одна из проблем, с которой сталкиваются команды при составлении плана тестирования, — это скорость рассинхронизации изначального плана с реализованным продуктом. Иногда план устаревает, как только команда его дописала. Это особенно очевидно в Agile-командах, где проект меняется и трансформируется еженедельно. Поэтому в Agile-командах план обновляется параллельно с разработкой.
Кто составляет план тестирования
За составление плана тестирования отвечают тестировщики. По аналогии с ревью кода у разработчиков, тестировщики проводят ревью планов друг друга. Это позволяет не пропустить важные тест-кейсы.
К обсуждению плана привлекаются и другие члены команды. Системный аналитик также участвует в планировании тестирования:
- выступает источником информации о продукте и требованиях;
- пишет тест-кейсы;
- участвует в принятии решения по результатам выполнения тест-плана, то есть принимает решение о том, готов ли продукт к передаче пользователям;
- следит за актуальностью плана и соответствием требованиям.
Шаблон плана тестирования
Состав плана тестирования может отличатся в зависимости от принятого в компании шаблона и целей тестирования. Существует стандарт IEEE 829, который определяет набор тестовой документации и правила её оформления. Этот стандарт состоит из 19 обязательных пунктов, однако большинство компаний адаптируют этот шаблон и используют только часть этих пунктов.
Основные блоки плана тестирования, которые встречаются чаще всего:
- Общая информация.
- Итоговые результаты.
- Тесты, которые включают в себя: 1. тест-кейсы; 2. скрипты; 3. фактический и ожидаемый результаты тест-кейса.
Шаблон плана тестирования выглядит так:
Разберём каждый пункт шаблона и правила его заполнения подробнее.
Общая информация
Это так называемая шапка тест-плана, в которой фиксируется:
- идентификатор программы;
- версия программы;
- ответственный тестировщик;
- даты тестирования.
Идентификатор программы (Program ID) — уникальное название для тестируемой программы или приложения.
Идентификатором может выступать название приложения или аббревиатура компании, которая выпустила приложение. Идентификатор программы указывается в коде приложения, но для плана тестирования можно указывать название приложения, по которому можно однозначно понять, какую программу мы тестируем. Например, для Яндекс Карт в качестве идентификатора программы может быть Yandex Map, для Яндекс Такси — Yandex Taxi.
Номер версии программы (Version number)
Тестируемое приложение может дорабатываться. Для каждой новой версии тест-план должен обновляться. Номер версии фиксируется в тест-плане.
Как правило, номер версии обозначают десятичной дробью, через точку. Например, первая версия приложения получает номер 1.0. Если в приложение вносятся небольшие изменения и исправляются ошибки, следующая версия получит номер 1.1. Если в продукт добавляется новая функциональность, меняется первое число перед точкой — 2.0. Чем сильнее увеличивается дробь, тем более значимо изменение. Разработчики порой перескакивают несколько версий, например, от версии 2.0 сразу к 2.5, чтобы обозначить добавление нескольких значимых функций в программу, но их недостаточно, чтобы изменить главный номер версии.
Для мобильного приложения номер версии можно найти в AppStore или Google Store. Например, для Яндекс Такси номер версии «4.124.0»:
Для веб-приложения номер версии можно найти в описании программы:
Тестировщик (Tester)
В шапке плана тестирования указывается имя и фамилия сотрудника, ответственного за составление плана и проведение тестирования.
Дата составления и дата проведения (Date designed, Date conducted)
Даты могут отличаться друг от друга. Например, план тестирования можно составить до разработки продукта, а проводить тесты уже после разработки.
Номер страницы (Page of)
План тестирования чаще всего занимает 20–30 страниц, где каждая страница — это отдельный тест. Поэтому каждую страницу необходимо пронумеровать.
Результаты тестирования
Следующий блок предназначен для фиксации итоговых результатов прохождения тестирования. Они записываются после завершения тестирования в формате:
- Успешно пройден (Passed) Если в ходе выполнения плана тестирования в продукте не обнаружены ошибки или ошибки некритичны для выпуска, то тестировщик ставит пометку в этом поле.
- Неуспешно пройден (Open items) Если в тестируемом продукте найдены критичные ошибки, тест-плану присваивается статус не пройден/неуспешно пройден. В этом случает тестировщик ставит пометку в этом поле и пишет комментарии.
В Комментариях указываются номера тест-кейсов, в которых найдены ошибки и кратко описываются расхождения в фактическом и ожидаемом поведении программы.
На рисунке показан пример заполненных полей:
Тесты
Далее в тест-плане составляется набор тестов. Каждый тест составляется на отдельной странице и должен содержать:
- Идентификатор теста
- Тестируемое требование
- Цель
- Тест-кейсы
- Тест-скрипты
- Ожидаемые результаты
- Фактические результаты
Идентификатор теста (Test ID) — уникальный номер теста, чтобы его отличать от других. Может содержать цифры, текст или и то и другое. По идентификатору теста должно быть понятно, какое приложение тестируется. Также он помогает отличить один тест от другого.
Например, для тестирования приложения Яндекс Такси можно использовать идентификатор теста YNDXTAXI-1, YNDXTAXI-2 и т. д.
Тестируемое требование (Requirement addressed)
Каждый тест проводится с целью проверки конкретного требования, описывающего свойства ПО или его функциональность.
Цель (Objective)
Цель теста должна быть конкретной и отвечать на вопрос «Что проверяем?» или «Что? Где? Когда?». У теста должна быть одна цель, которая, как правило, соответствует ожидаемым результатам теста.
Разберём формат записи требований и целей на примере:
Требование:
«При выборе способа оплаты у пользователя должна быть возможность привязать карту»
Возможность привязать карту можно проверить разными способами. Например, можно привязать как валидную карту, так и невалидную карту. Каждый такой случай необходимо проверить разными тестами, при этом у каждого теста должна быть своя цель.
Поэтому для этого требования можно сформулировать несколько целей:
- На экране привязки карты, когда пользователь указал валидную карту, должна привязаться карта и отобразиться в списке способов оплаты
- На экране привязки карты, когда пользователь указал невалидные данные карты, должно отобразиться сообщение «Ошибка при проверке. Не удалось проверить карту» с возможностью добавить новую карту или закрыть сообщение
- На экране привязки карты, когда пользователь указал не все данные карты, должна быть заблокирована возможность привязать карту
- На экране привязки карты, когда пользователь указал заблокированную карту, должно отобразиться сообщение «Карта заблокирована» с возможностью добавить новую карту или закрыть сообщение
Тест-кейсы
Вы уже знаете, что тест-кейс — это описание шагов, которые необходимо пройти для проверки функциональности продукта. Тест-кейс должен описывать: где тестируем, что делаем, какие значения вводим. Исходя из этого тест-кейс состоит из:
- Идентификатора интерфейса
- Последовательности шагов
- Вводимых значений
Идентификатора интерфейса (Interface ID)
Это поле помогает ответить на вопрос: «Где необходимо выполнить шаг тест-кейса?». Идентификатор интерфейса можно задать:
- названием экрана, например «Экран авторизации»;
- URL страницы
https://market.yandex.ru/my/ordersили конечной точной URL/orders.
Последовательность шагов (Data Field)
Конкретные действия, которые необходимо выполнить в интерфейсе. Шаги тестирования записываются в формате таблицы. Каждый шаг — отдельная строка таблицы.
Правила описания шагов:
- Шаги описываются через глаголы действия и отвечают на вопрос: «Что нужно сделать?» Например, «Ввести номер карты» или «Нажать на кнопку Войти». 2. Каждому шагу должен соответствовать нужный идентификатор интерфейса Как правило, все шаги выполняются на одном экране. Но если тест-кейс проверяет переход между экранами, то идентификатор может меняться. 3. Шаги должны содержать только необходимую информацию Не стоит расписывать их чересчур подробно. Из описания шага должно быть понятно, какое действие необходимо выполнить. 4. Если в интерфейсе несколько элементов, необходимо указывать их название. Необходимо конкретно описать, какое именно поле необходимо заполнить или какую кнопку нажать. 5. Тест-кейс не должен содержать лишних шагов Шаги должны быть направлены только на проверку функциональности, описанной в целях теста. 6. Шаги расставлены в корректной последовательности Последовательность шагов должна быть такой, чтобы их можно было воспроизвести в интерфейсе. 7. Последний шаг приводит к проверке ожидаемого и фактического результата.
Введённое значение (Value Entered)
Для шагов, которые требует заполнения полей, в тест-кейсах указываются конкретные введённые значения. Это может быть текст, символ, цифры, их комбинация.
Например, если в шаге тестирования необходимо заполнить поле «почта», то в столбце введённое значение необходимо написать конкретный адрес почты.
Некоторые тесты проверяют работу функциональности при введении корректных и некорректных данных. В этом случае необходимо составлять разные тест-кейсы.
Разберём пример описания шагов тест-кейса для приложения Яндекс Такси. Данный тест-кейс проверяет привязку банковской карты. Чтобы привязать карту, необходимо выполнить следующие шаги:
- Указать номер карты.
- Указать срок действия карты.
- Ввести cvc-код.
- Нажать на кнопку привязать карту.
Скрипты
На основе составленных тест-кейсов тестировщики составляют тестовые скрипты. Эта часть тест-плана заполняется только для автоматического тестирования.
Ожидаемые и фактические результаты
Ожидаемые результаты (Expected results) — то, что хотим получить в результате тестирования. Ожидаемый результат чаще всего совпадает с целью теста.
Фактические результаты (Actual results) — то, что получили по факту после тестирования. Ожидаемый результат и фактический результат могут не совпадать. В этом случае необходимо подробно описать расхождения.
Пример, когда ожидаемые результаты совпадают с фактическими:
Пример, когда ожидаемый результат не совпадает с фактическим:
Важно следить, чтобы в тест-кейсе был только один ожидаемый результат.
Например, если нужно проверить поле «Номер карты»: сохраняется ли значение, которое в него вводит пользователь. В этом случае необходимо составить несколько тест-кейсов, с разными ожидаемыми результатами:
- При вводе неверного значения номера карты система не даёт привязать карту и выдаёт сообщение об ошибке
- При вводе неполного значения номера карты система не даёт привязать карту и выдаёт сообщение об ошибке
- При вводе верного значения номера карты система даёт привязать карту и выдаёт сообщение об успехе
Формулировка результатов должна быть однозначной
Однозначный результат — тот, который одинаково может представить любой человек из команды. Такой результат отвечает на вопросы: Что именно? Где? Когда?
Например, нужно проверить, что при указании адреса, который не поддерживается в Яндекс Такси, должно отобразиться сообщение об ошибке.
Формулировка результата «Вывелась ошибка» не будет однозначной.
Правильно описать результат следующим образом: «На карте выбора адреса подачи машины вывелось сообщение об ошибке: «Ваш адрес не поддерживается сервисом» и кнопка “Изменить адрес”».
Подведём итоги
План тестирования, или тест-план (test plan) — это документ, который описывает весь объём работ по тестированию, включая объект тестирования, цели, участников и результаты.
План тестирования состоит из следующих обязательных блоков:
- Общая информация:
- идентификатор программы;
- версия программы;
- ответственный тестировщик;
- даты тестирования;
- Итоговые результаты
- Тесты:
- Идентификатор теста
- Тестируемое требование
- Цель
- Тест-кейсы
- Тест-скрипты
- Ожидаемые результаты
- Фактические результаты
Как правило, тест-план составляют тестировщики, но системный аналитик может привлекаться в качестве источника информации о требованиях, для составления тест-кейсов и для принятия решения по результатам выполнения тест-плана.
