Что такое тестовый случай (тест-кейс) и как его оформить

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

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

Одним тест-кейсом проверяется одна конкретная вещь и для этой вещи должен быть только один ожидаемый результат.

Разница между тест-кейсом и чек-листом: тест-кейс часто подразумевает только один конкретный тест, когда в чек-листе подразумевается целый перечень различных проверок. Сила чек-листа в том, что он прост. Там нет глубокой детализации, это просто памятка. К тому же он достаточно нагляден с точки зрения отчетности.

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

В тестовом случае фиксируются cтруктура тестовых случаев (Test Case Structure). Каждый тест кейс должен иметь 3 части:

1. Предусловия (PreConditions) — что должно быть выполнено или подготовлено перед началом теста.
2. Последовательность действий (Steps) — что именно нужно сделать.
3. Ожидаемый результат (Expected Result) — что должно произойти, если функция работает правильно.
4. Постусловия (PostConditions) — действия для возврата системы в исходное состояние после теста. Post Conditions не является обязательной частью. Например, удаление тестовых данных в базе данных добавленных во время процедуры тестирования.

Тестовый случай (Test Case) направлен на проверку конкретного условия или сценария в приложении.

Любой тест-кейс обязательно включает в себя:

• Уникальный идентификатор тест-кейса – необходим для удобной организации хранения и навигации по нашим тест-наборам.
• Название – основная тема, или идея тест-кейса. Краткое описание его сущности. Названия нужно писать по принципу Что? Где? Когда?, например, регистрация нового пользователя с валидными данными.
• Предпосылки - описание условий, не имеющих прямого отношения к проверяемому функционалу, но должны быть выполнены. К примеру, оставить комментарий на вашем портале может только зарегистрированный пользователь. Следовательно, для тест-кейса "Создание комментария" будет необходимо выполнение предпосылки "Пользователь зарегистрирован" и "Пользователь авторизирован".
• Шаги – описание последовательности действий, которая должна привести нас к ожидаемому результату
• Ожидаемый результат – результат: что мы ожидаем увидеть после выполнения шагов.

Не обязательно, но желательно добавить в тест-кейс атрибут история редактирования – это очень облегчит вам жизнь. Лаконичный журнал изменений, где отображен: кем, как и когда был изменен тест-кейс.

Тест кейсы делятся по ожидаемому результату на положительные и отрицательные:

• Положительный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызванную функцию.
• Негативный тест кейс оперирует как корректными, так и некорректными данными (по меньшей мере 1 некорректный параметр) и преследует цель проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция, которая не выполняется при срабатывании валидатора.

1. Зависимости от других тест-кейсов;
2. Нечеткой формулировки шагов или ожидаемого результата (Если описание шагов или ожидаемый результат будет не четким, это блокирует прохождение тест-кейса.);
3. Отсутствия необходимой для прохождения тест-кейса информации;
4. Излишней детализации.

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

У тест-кейса должна быть вся информация, необходимая для его прохождения. К примеру, если мы проверяем окно логина на сайте, значит нам понадобится логин и пароль, иначе прохождение этого сценария будет невозможным.

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

1. FAQ 1: Что лучше делать сначала тест кейс и или чек лист? Это зависит от контекста.
2. FAQ 2: Каков порядок тест кейсов сначала отрицательные, положительные или без разницы? Ответ положительные.