Тест-кейс — алгоритм действий для проверки написанной программы. Он подробно описывает короткую последовательность действий, например успешную авторизацию пользователя. В тест-кейсе фиксируют подготовку к проверке, саму диагностику и ожидаемый результат, включая информацию о количестве проверок и нюансах.
Тестировщики создают тест-кейсы для сложных проектов как подтверждение того, что функционал системы соответствует установленным стандартам и требованиям.
Виды тест-кейсов в тестировании
Тест-кейсы могут быть позитивными, негативными и деструктивными.
- Позитивный тест-кейс проверяет отсутствие сообщений об ошибке там, где это не предусмотрено, и исполнение системой позитивного сценария нормального использования ПО.
Например, при регистрации необходимо ввести пароль из шести символов. Ожидаемый результат — система дает пользователю возможность создать такой пароль.
- Негативный тест-кейс определяет поведение системы при получении некорректных входных данных. В этом случае система не проигрывает позитивный сценарий, то есть не делает того, что не предусмотрено.
Например, при регистрации вводится несуществующий электронный адрес: система сообщает об ошибке и не заканчивает процесс регистрации пользователя.
- Деструктивный тест-кейс проверяет систему на прочность. С его помощью тестировщики изучают сценарии работы ПО в экстремальных условиях, например при повышенной нагрузке, при попытках взломать страницу или внедрить сторонние скрипты в формы регистрации.
Так, деструктивный тест-кейс проверяет поведение системы при попытке ввести в поле регистрации скрипта для удаления базы данных.
Элементы тест-кейсов в тестировании
При создании тест-кейса тестировщик прописывает следующие параметры:
- ID — уникальная нумерация тест-кейса в виде сочетания цифр и букв.
- Заголовок — краткое описание идеи и сути тест-кейса.
- Предусловия — действия, необходимые для выполнения тест-кейса, например авторизация или вход в определенный раздел программы.
- Шаги — последовательность действий в ходе проверки.
- Постусловия — описание возврата системы в исходное состояние (если необходимо). Например, инструкции по удалению внесенных данных по окончании тестирования во избежание переполнения базы.
- Ожидаемый результат — описание того, что тестировщик ожидает получить по окончании или в процессе тестирования.
- Фактический результат — описание того, что тестировщик получил по факту (если необходимо).
- Статус — один из принятых в команде вариантов оценки тестирования: success (успех), failed (провал), blocked (блокировка).
Также при создании тест-кейса могут понадобиться:
- Описание требований к среде. Информация об использовании специального оборудования или ПО для проверки, которая не указана в спецификации тестирования.
- Межкейсовые зависимости. Информация о проведении дополнительных тест-кейсов перед выполнением описываемой проверки.
- Специальные процедурные требования. Информация об уникальных для этого тест-кейса настройки.
Как написать хороший тест-кейс?
Хороший тест-кейс может воспроизвести любой тестировщик. Он написан точно и аккуратно и понятен любому члену команды. Такой тест можно использовать много раз. При создании тест-кейса обращайте внимание на следующие моменты:
- Ваш тест-кейс уникален и не дублирует имеющиеся в системе проверки материалы.
- Шаги тест-кейса описаны четко и лаконично. Например, в инструкции указано «Введите логин» вместо «Используйте клавиатуру для введения логина».
- Заголовок кратко отражает суть проверки.
- Тест-кейс на 100% закрывает требования к ПО, которые необходимо проверить.
- В предусловии детально описано необходимое для проверки состояние системы. Даны верные и кликабельные ссылки на условия или соответствующие документы.
- Скриншоты дополняют описание, но не заменяют его.
- Используются стандартные методы тестирования — анализ граничных значений, разделение эквивалентности, техника перехода состояния, угадывание ошибок и т. п.
- Указаны необходимые для выполнения тест-кейса учетные данные.
