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. В форме указаны поля, которые необходимо заполнить корректными данными и нажать кнопку <Создать> для того, чтобы можно было зарегистрироваться с системе.
У каждого поля есть есть правила по заполнению, и все эти правила будут указаны в требованиях.
Первый сценарий, который можно в этой ситуации написать - Проверка регистрации пользователем корректных данных. Это Дымовое тестирование потому что мы проходим основную бизнес-логику. Не получится работать на сайте, если пользователь на нем не зарегистрирован. То есть нельзя отправить сообщение, если нет регистрации на сайте.
Следующий сценарий: если в первом случае для регистрации использовались корректные данные, то в этом сценарии будет логично использовать для регистрации некорректные данные. То есть некоторые поля оставляем пустыми или заполненные некорректными данными и нажать кнопку <Создать> для того, чтобы проверить поведение системы в данной ситуации.
Для того, чтобы записать это в чек-листе, нужно указать, что это Расширенное тестирование (т.к. это негативное тестирование). И пишем Проверка возможности регистрации в системе, используя некорректные данные для входа. Оно не успешно - так как регистрация в такой ситуации невозможна.
То же самое и с авторизацией - проверяем авторизацию с корректными данными (Смоук-тестирование), а потом с некорректными данными (Расширенное тестирование).
Тест-кейс
Вы могли очень часто слышать название данного документа, видеть его в вакансиях и видео-уроках. На собеседованиях очень любят спрашивать что это такое и какие атрибуты он в себя включает, а так же работодатели часто просят их составить в качестве тестового задания. И так.
Что такое тест-кейс?
Тест-кейс – пошаговый сценарий, описывающий как проводится тестирование, и включающий более детализированные проверки (шаги).
То есть если в чек-листах мы указывали название самих проверок, не детализировали их, то в тест-кейсах необходимо расписать каждый шаг, то есть переход по ссылкам, заполнение полей, нажатие кнопок и т.д.
Это необходимо для того, чтоб тестировщик смог воспроизвести данный сценарий. Есть одно правило, оно звучит так: «Тест-кейс необходимо писать так, чтоб его мог повторить любой человек с улицы». Это говорит о том, что Ваш тест-кейс должен бать максимально подробным.
Кто может составлять тест-кейсы:
- Во-первых, сам тестировщик, когда он получает в работу задачу, он изучает требования и на основе своего опыта и знания бизнес логики продукта начинает составлять тест-кейсы, как он будет его тестировать.
- Во-вторых, тест-кейсы могут составлять бизнес-аналитики и руководитель проекта, то есть, когда они создают задачу по разработке, они могут прописать в ней список сценариев и шагов как их пройти, которые они хотят проверить. Это очень удобно для всей команды, так как ускоряет процесс тестирования и подсказывает тестировщику в каком направлении ему необходимо двигаться.
Где именно составляются и хранятся тест-кейсы:
- в 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) - Дата проведения теста
- Исполнитель
- Среда тестирования – здесь мы указываем окружение, на котором мы будем проводить тестирование – то есть наша платформа, версия браузера (если это веб-продукт) и т.д.;
- Статус – статус прохождения нашего теста
Пример составления тестового набора
Так же тестовый набор может включать в себя не только тест-кейсы из одного модуля, но и из нескольких модулей. В случае, если тестовый набор - это набор из регрессивных тестов (то есть тестов, которые необходимо провести во время регрессионного тестирования).
Регрессионное тестирование – повторная проверка ранее разработанного функционала, после появления нового билда, то есть новой версии нашего программного продукта, для того, чтоб убедиться, что новый функционал билда никак ему не навредил.
А теперь составим тестовый набор по отправке сообщений (тест-кейсы для которого составляли на прошлой лекции).
