Тестовый сценарий (Test scenario)

Сценарий выполнения (test scenario): См. спецификация процедуры тестирования. (ISTQB)

Спецификация процедуры тестирования (test procedure specification): Документ, описывающий последовательность действий при выполнении теста. Также известен как ручной сценарий тестирования. (IEEE 829) См. также спецификация теста

Спецификация теста (test specification): Документ, состоящий из спецификации проектирования теста, спецификации тестовых сценариев и/или спецификации процедуры тестирования (ISTQB)

Тестовый сценарий (Test scenario) – последовательность действий над продуктом, которые связаны единым ограниченным бизнес-процессом использования, и сообразных им проверок корректности поведения продукта в ходе этих действий. Иными словами, это последовательность шагов, которые пользователь может предпринять, чтобы использовать ваше программное обеспечение во время тестирования. Сценарии тестирования должны учитывать все возможные способы выполнения задачи (функции) и охватывать как положительные, так и отрицательные тестовые примеры, потому что конечные пользователи могут не обязательно предпринимать шаги, которые вы от них ожидаете. Используя тестовые сценарии, мы оцениваем работу приложения с точки зрения конечного пользователя. Фактически при успешном прохождении всего тестового сценария мы можем сделать заключение о том, что продукт может выполнять ту или иную возложенную на него функцию.

Как писать сценарии:

● Тщательно ознакомьтесь с требованиями (Спецификация бизнес-требований (BRS), Спецификация требований к программному обеспечению (SRS), Спецификация функциональных требований (FRS)) тестируемой системы (SUT), use cases, книгами, руководствами и т. д.;

● Для каждого требования выясните, как пользователь может использовать программное обеспечение всеми возможными способами;

● Составьте список сценариев тестирования для каждой функции тестируемого приложения (AUT);

● Создайте матрицу прослеживаемости и свяжите все сценарии с требованиями. Это позволит вам определить, сопоставлены ли все требования с тестовыми сценариями или нет;

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

Не стоит путать Test scenario с Test Suite (набор тестов, тест-свит).

Набор тестов (test suite): Комплект тестовых наборов для исследуемого компонента или системы, в котором обычно постусловие одного теста используется в качестве предусловия для последующего. (ISTQB)

Test Suite - это некоторый набор формализованных Test case, объединенных между собой по общему логическому признаку, которые позволяют проверить один из частей или вариантов сценария. Test Scenario представляет собой некий пользовательский сценарий по тестированию некой функциональности. Что-то, что пользователь может захотеть сделать с вашей системой, и вы хотите это проверить. Сценарий может иметь один или несколько Test Suite.

Источники:

● How To Create Test Scenarios With Examples

● Каких ответов я жду на собеседовании по тестированию

Доп. материал:

● Test Scenarios Registration Form

● Test Scenarios of GMail

● Шаблон сценария

Тест-кейс (Test case)

Тестовый сценарий (test case): Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. (IEEE 610)

Тестовый сценарий высокого уровня (high level test case): Тестовый сценарий без конкретных (уровня реализации) значений входных данных и ожидаемых результатов. Использует логические операторы, а экземпляры реальных значений еще не определены и/или доступны. (ISTQB)

Тестовый сценарий низкого уровня (low level test case): Тестовый сценарий с конкретными (уровня реализации) значениями входных данных и ожидаемых результатов. Логические операторы из тестовых сценариев высокого уровня заменяются реальными значениями, которые соответствуют целям этих логических операторов. (ISTQB)

Test case (тест-кейс, тестовый пример/случай) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или ее части. Более строго — формализованное описание одной показательной проверки на соответствие требованиям прямым или косвенным.

Содержание тест-кейса:

● Идентификатор набора тестов (Test Suite ID): Идентификатор набора тестов, в которых входит этот кейс;

● Идентификатор тестового кейса (Test Case ID): Идентификатор самого кейса;

● Заголовок кейса (Test Case Summary): Краткое и емкое название проводимой проверки;

● Связанное требование (Related Requirement): Идентификатор требования, к которому относится / отслеживается данный тестовый пример;

● Предварительные условия (Prerequisites): Любые предпосылки или предварительные условия, которые должны быть выполнены перед выполнением теста;

● Шаги выполнения (Test Script / Procedure): Шаги выполнения теста;

● Тестовые данные (Test Data): Тестовые данные или ссылки на тестовые данные, которые должны использоваться при проведении теста;

● Ожидаемый результат (Expected Result): результат, который мы ожидаем получить после выполнения шагов теста;

● Статус пройден или не пройден (Status): Другие статусы могут быть «Не выполнено», если тестирование не проводится, и «Заблокировано», если тестирование заблокировано;

● Заметки (Remarks): Любые комментарии к тесту или выполнению теста;

● Создано (Created By): Имя автора тестового примера;

● Дата создания (Date of Creation): Дата создания тестового примера (опционально модификации);

● Выполнено (Executed By): Имя человека, выполнившего тест;

● Дата выполнения (Date of Execution): Дата выполнения теста;

● Тестовое окружение (Test Environment): оборудование / программное обеспечение / сеть, в которых выполнялся тест, т.е. все необходимые сведения об окружении, чтобы можно было воспроизвести полученный результат.

В иностранной литературе часто делят кейсы на две категории:

● Высокоуровневый тест-кейс (high level test case или logical test case) — тест-кейс без конкретных входных данных и ожидаемых результатов. Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне smoke. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов.

● Низкоуровневый тест-кейс (low level test case) — тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, т.к. прописать все данные подробно — намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса.

Нужно ли вообще писать кейсы? Ответ тот же, что и для любого документа - если написание кейсов решает определенную задачу и это обоснованно, то писать. Если вы один, не путаетесь в небольшом проекте, пользуетесь чек листами/mind map/.., можете и без TMS/test runs reports наглядно предоставлять актуальные сведения о протестированности/качестве заинтересованным лицам, то не писать.

Может ли быть несколько ожидаемых результатов? Может, если это необходимо, но сразу после каждого шага.

Можно ли объединять позитивные и негативные тест-кейсы? Позитивные можно, негативные нельзя, поскольку сложно будет понять, что именно влияет на результат.

Источники:

● Test Case

Доп. материал:

● Тест-кейсы: полная лекция из ШНАТ

● Составление тест-кейсов

● 12 характеристик высокоэффективных тестов

● Blog: Evaluating Test Cases, Checks, and Tools

● How to write Test Cases for a Login Page

● Примеры: раз, два

Чек-лист (Check List)

Контрольный список/лист проверок - это список проверок, которые помогают тестировщику протестировать приложение или отдельные функции. Основная цель чеклиста состоит в том, чтобы вы не забыли проверить всё, что планировали. Классический чеклист состоит из:

● 1-й столбец: заголовки тест-кейсов, структурированные по разделам/функционалу, или любые определенные составителем пункты;

● 2-й столбец для отметки: пусто (еще не проверялось)/успех/ошибка;

● 3-й столбец опционально под заметки.

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

Чек-лист не обязательно является некоторой заменой тест-кейсов, это более глобальная сущность, в виде которой можно записывать множество планов и предстоящих действий: критерии начала и окончания тестирования, проверки перед началом каждой фазы, действия по их завершении, подспорье при исследовательском тестировании, накидать проверок с mind map функционала продукта, шеринг опыта с коллегами и т.п.