5.2 Чек-лист. Тест-кейс. Тестовый набор

Чек-лист

Чек-лист- список проверок, в котором мы указываем, что мы будем тестировать, результат и статус проверок.

Кто может составлять чек-листы:

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

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

Где именно составляются и хранятся чек-листы:

в Office документах, например word, excel
в google документах
в специализированном ПО, например Jira в самой задаче
в приложениях, которые специально созданы для этого – Test IT, Testrail, Testlink и т.д.

Чек-лист включает в себя следующие атрибуты:

Проект – здесь указывается название проекта, для которого мы пишем сценарии проверки;
Цель проверки - здесь идет название модуля который будет проверять в данном документе;
Идентификатор -это уникальный Идентификатор документа;
Требования - ссылка на документ, на основании которого составлен данный документ;
Дата проведения;
Исполнитель;
Среда тестирования – здесь мы указываем окружение, на котором мы будем проводить тестирование – то есть наша платформа, версия браузера (если это веб-продукт) и т.д.
Тип тестов;
Название проверок - здесь идет название нашей проверки, отображающее то, что именно мы будет проверять в данном тесте;
Результат проверки

Данные атрибуты являются обязательными. Чек-лист не включает в себя детальное перечисление шагов, которые необходимо выполнить, для выполнения данных проверок, основная его задача перечислить различные сценарии тестирования данного функционала.

Статья про чек-лист для допобразования

Пример чек-листа:

Тестируем почтовую службу Mail.ru.

Проект: Почтовая служба mail.ru
Цель проверки: Проверка функционала регистрации и авторизации в системе. Отправка сообщений. <По факту это 2 разных модуля и тестироваться они должны отдельно друг от друга, но в целях обучения мы их объединили.>
Идентификатор ID: ID.1
Требования: REQ1
Дата проведения: 01.01.2021
Исполнитель: Иванов.И.И.
Среда тестирования: PC, Google Chrome Версия 88.0.4324.104

Как составлять сценарий для чек-листа

В данном случае цель проверки - Проверка функционала регистрации и авторизации в системе и отправка сообщений.

Форма регистрации mail.ru

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

Скрин выше - форма регистрации на сайте mail.ru. В форме указаны поля, которые необходимо заполнить корректными данными и нажать кнопку <Создать> для того, чтобы можно было зарегистрироваться с системе.

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

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

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

Для того, чтобы записать это в чек-листе, нужно указать, что это Расширенное тестирование (т.к. это негативное тестирование). И пишем Проверка возможности регистрации в системе, используя некорректные данные для входа. Оно не успешно - так как регистрация в такой ситуации невозможна.

То же самое и с авторизацией - проверяем авторизацию с корректными данными (Смоук-тестирование), а потом с некорректными данными (Расширенное тестирование).

Тест-кейс

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

Что такое тест-кейс?

Тест-кейс – пошаговый сценарий, описывающий как проводится тестирование, и включающий более детализированные проверки (шаги).

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

Это необходимо для того, чтоб тестировщик смог воспроизвести данный сценарий. Есть одно правило, оно звучит так: «Тест-кейс необходимо писать так, чтоб его мог повторить любой человек с улицы». Это говорит о том, что Ваш тест-кейс должен бать максимально подробным.

Кто может составлять тест-кейсы:

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

Где именно составляются и хранятся тест-кейсы:

в office документах, например word, excel
в google документах
в специализированном ПО, например Jira, в самой задаче
в приложениях, которые специально созданы для этого – Test IT, Testrail, testlink и т.д.

Обязательные атрибуты тест-кейсов

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

Название проекта – здесь указывается название проекта, для которого мы пишем сценарии проверки
ID – это уникальный Идентификатор, уникальный номер тест-кейса, в нашей системе, на одном проекте не должно быть 2-х одинаковых тест-кейсов, это необходимо для того чтоб мы могли всегда корректно ссылаться на наш документ, при общении с другими коллегами, указанием в других системах и т.д. Данный идентификатор не должен биться с id чек-листа, то есть если здесь у нас id 1, то это не значит что все тест-кейсы которые будут написаны по сценариям данного документа должны иметь id1, у них идет своя нумерация.
Требования – ссылка на документ, на основании которого составлен данный документ
Модуль – название модуля к которому относится данный функционал
Название - здесь идет название нашей проверки, отображающее то, что именно мы будет проверять в данном тесте
Приоритет - показывает, на сколько важно проведение данного теста
P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)
Тестировщик самостоятельно выставляет данный приоритет, основываясь на своем опыте.
Среда тестирования – здесь мы указываем окружение, на котором мы будем проводить тестирование – то есть наша платформа, версия браузера (если это веб-продукт) и т.д.
Шаги-теста – самый главный атрибут нашего документа, в котором мы подробно расписываем все шаги прохождения нашего теста
Ожидаемый результат – в данном атрибуте мы указываем, а какой именно результат мы ожидаем получить, после того как мы выполним данный шаг, очень важно писать результат по каждому шагу, а не один для всех шагов. Это позволит любому члену команды повторить данный тест.

Рассмотрим, как нужно составлять тест-кейс

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

У нас есть чек-лист, в котором есть такой тип проверки.

На основании этого пункта чек-листа формируем тест-кейс, расписывая все по шагам и прописываем ожидаемый результат (не результат, который получили, а именно ожидаемый результат!)

Далее можно сформировать тест-кейс на основании негативного теста того же действия:

Тогда получим такой тест-кейс:

Но в этой ситуации нельзя ограничиваться только одним тест-кейсом! То есть можно протестировать:

где-то не заполнить поле
ввести номер телефона буквами или символами
и тд...

А теперь рассмотрим этот пункт из чек-листа:

А вот тест-кейс к этому пункту чек-листа.

И мы видим, что у нас есть пункт 2 - Авторизовать в системе, используя корректные данные. Так как мы понимаем, что будем писать большое количество тест-кейсов и понимаем, что везде будем повторять 1 и 2 шаги (Заходить на сайт и авторизовываться), можно не писать эти шаги постоянно, а добавить новую колонку Предварительные условия и написать это туда, чтобы таблица приобрела следующий вид:

Так же в Шагах теста, в Шаге 2 необходимо прописывать то, как заполняются поля:

Так же в рамках нашего тест-кейса по отправке сообщений сделаем еще одну проверку, для этого в чек-листе находим пункт, связанный с отправкой сообщений и делаем на него текст-кейс:

Тестовый набор

Что такое тестовый набор?

Тестовый набор (Testsuite) – набор тест-кейсов, объединенный по одному модулю или цели проверки.

Например: у нас есть тест-кейсы в которых мы тестируем форму регистрации в системе, отдельный модуль который называется – Регистрация. Мы объединим их в один документ для того, чтобы, когда нам необходимо, провести его тестирования, мы могли его открыть и посмотреть, а какие именно сценарии необходимо нам использовать и при необходимости (к примеру, если мы забыли как тестировать данный функционал), можно перейти по его идентификатору в данный тест-кейс и посмотреть шаги данного тест-кейса.

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

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

У нас есть чек-лист, который включает в себя только сценарии проверок.

У нас есть тест-кейсы, которые пошагово раскрывают сценарии проверки и помогает тестировщику пройти тест-кейс, если это потребуется.

Все наши тест-кейсы объединяем в один тестовый набор по одному модулю.

Кто может составлять тестовый набор:

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

Где составляются и хранятся тестовые наборы:

в office документах, например word, excel
в Google документах
в специализированном ПО, которые специально созданы для этого – Test IT, Testrail, tTestlink и т.д.

Обязательные атрибуты тестового набора:

Они дублируют с атрибутами тест-кейсов.

ID тест-кейса – это уникальный Идентификатор, уникальный номер тест-кейса, в нашей системе, на одном проекте не должно быть 2-х одинаковых тест-кейсов, это необходимо для того чтоб мы могли всегда корректно ссылаться на наш документ, при общении с другими коллегами, указанием в других системах и т.д.;
Название проекта – здесь указывается название проекта, для которого мы пишем сценарии проверки;
Модуль – название модуля к которому относится данный функционал;
Описание теста, то есть название из нашего тест-кейса - здесь идет название нашей проверки, отображающее то, что именно мы будет проверять в данном тесте;
Ожидаемый результат – в данном атрибуте мы указываем, а какой именно результат мы ожидаем после выполнения нашего теста. Это позволит любому члену команды повторить данный тест;
Приоритет - показывает, на сколько важно проведение данного теста:
P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)
Дата проведения теста
Исполнитель
Среда тестирования – здесь мы указываем окружение, на котором мы будем проводить тестирование – то есть наша платформа, версия браузера (если это веб-продукт) и т.д.;
Статус – статус прохождения нашего теста

Пример составления тестового набора

Так же тестовый набор может включать в себя не только тест-кейсы из одного модуля, но и из нескольких модулей. В случае, если тестовый набор - это набор из регрессивных тестов (то есть тестов, которые необходимо провести во время регрессионного тестирования).

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

А теперь составим тестовый набор по отправке сообщений (тест-кейсы для которого составляли на прошлой лекции).

Таблица, которая использовалась в уроке

Ссылка на таблицу