Тест-кейс в тестировании это

QA-инженер в своей работе использует разные инструменты для организации тестирования. Среди них стратегия тестирования, тест-план, чек-лист, баг-репорт, отчеты о тестировании и другие. Здесь мы рассмотрим тест-кейс. Каждый тестировщик должен уметь работать с тест-кейсами, а при необходимости – создавать их.

---

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

Тест-кейс (Test case) — пошаговое описание действий, которые нужно произвести для проверки какой-либо функции ПО.

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

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

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

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

---

Пример простого тест-кейса

ID теста:	001
Название:	Проверка входа на сайт с корректной парой логин/пароль.
Предусловия:	Нет.
Шаги выполнения:	Откройте страницу сайта. На сайте вверху справа нажмите кнопку «Войти», дождитесь появления формы. В поле «Логин» введите «Тестеры», а в поле «Пароль» введите «NeverSleep», затем ниже нажмите кнопку «Войти».
Ожидаемый результат:	На экране отображается профиль (личный кабинет) пользователя «Тестеры».
Постусловие:	Нажать кнопку «Выход», чтобы выйти из системы.

---

Какие бывают виды тест-кейсов

Тест-кейсы могут быть следующих видов: 

1. Положительный (позитивный). Проверяет то, что ПО должно делать. Например, войти пользователю в свой профиль при корректной паре логин/пароль.
2. Отрицательный (негативный). Проверяет, делает ли ПО то, что НЕ должно делать. Например, войти в свой профиль с неправильной парой логин/пароль, или даже войти в чужой профиль.
3. Деструктивный. Проверяет прочность ПО на взлом. Например, устоит ли сайт при злонамеренном введении JavaScript в поля формы.

---

Атрибуты

Выделяют следующие основные атрибуты (поля) тест-кейсов:

• ID (уникальный идентификатор) — номер тест-кейса.
• Название (заголовок, краткое описание) — краткое, но понятное описание содержания тест-кейса. Можно содержать указание на тестируемое бизнес-требование к ПО.
• Предусловие (входные данные): То, в какое состояние ПО нужно привести перед началом проверки. Например, закрыть определенные модули. Или зайти в специальный раздел сайта.
• Шаги (этапы) — действия проверки step-by-step.
• Ожидаемый результат — что тестировщик должен получить на экране после завершения шагов (если там не будет багов, конечно)

Для указания результатов тестирования есть также поля:

• Фактический результат — что тестировщик увидел на экране после завершения шагов.
• Статус – краткое, как завершился тест-кейс. Например, «успех», «провал», «блокировка» или другие заранее согласованные варианты.
• Приложения – сюда прикрепляется все, что поможет разработчикам для устранения бага. Например, скриншоты.
• История редактирования – краткий журнал изменений, если тест-кейс до этого был модифицирован (кто, когда, как, с какой целью).
• Постусловие – действия, которые надо сделать после прохождения тест-кейса. Например, чтобы вернуть систему в исходное состояние для следующей проверки.

Это основные, но могут быть и другие атрибуты тест-кейсов – в зависимости от специфики проекта.

---

Как составлять тест-кейс

Чтобы составить тест-кейс, надо заполнить все его необходимые атрибуты. Особое внимание – на шаги выполнения. При этом следует руководствоваться следующими принципами:

• Перед созданием – убедиться, что не дублирует уже имеющийся
• Соответствие требованиям к ПО
• Один тест-кейс – одно требование
• Полный и самодостаточный: не должен зависеть или быть связанным с другими тест-кейсами
• Аккуратное и точное написание – понятен каждому члену команды
• Вся нужная для проверки информация указана
• Воспроизводимость (не-однократность)

---

Часто задаваемые вопросы

---