Как написать тест-кейс

В тестировании, чтобы проверить, корректно ли работает программное обеспечение (ПО), делают определенные действия и сверяют полученный результат с ожидаемым. Другими словами — моделируют ситуацию работы ПО. Чтобы описать шаги, создают тест-кейсы.

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

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

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

Подробнее о том, как писать тест-кейсы и другую тестовую документацию, вы узнаете на курсе «Инженер по тестированию». Научитесь отслеживать ошибки и писать отчеты о тестировании. Посетите мастер-класс по тест-кейсам и попрактикуетесь в их создании. Эти навыки пригодятся в работе тестировщика.

Подробнее об этом расскажет наш спикер на видео

Отличия

Тест-кейс часто путают с двумя другими сущностями — чек-листом и баг-репортом. Он отличается.

От чек-листа

В чек-листе перечисляют аспекты ПО, которые нужно проверить. Когда составляют тест-кейс, описывают состояние программного обеспечения и то, как его изменяют. То есть чек-листом определяют, что тестировать. А тест-кейсом — как тестировать. Чек-лист подойдет в качестве исходного документа, чтобы составить тест-кейс.

Пример чек-листа

От баг-репорта

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

Пример баг-репорта

Виды тест-кейсов

Классификация зависит от типа входных данных, действий и ожидаемого поведения ПО.

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

Пример

У вас есть требование к программной системе расписания занятий: «В систему нужно добавлять новые уроки».

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

Негативные попытаются сломать нормальную работу системы. Например, добавляют урок, когда нет места в расписании, или не указывают его название.

Деструктивные покажут, сохранится ли расписание при сбоях. Например, если внезапно завершат программу или введут огромное количество данных за короткое время.

Примеры позитивного, негативного и деструктивного тест-кейсов

Жизненный цикл

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

Но обычно выделяют четыре состояния:

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

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

Обязательные атрибуты

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

Но обычно выделяют следующие атрибуты:

• Уникальный идентификатор — некое уникальное значение. По нему на тест-кейс ссылаются из других документов или тест-кейсов. Бывает буквенным, числовым, буквенно-числовым. Чаще всего применяют простую сквозную нумерацию.
• Краткое описание — лаконичное описание сути тест-кейса. Может содержать ссылку на требование к ПО.
• Входные данные — сведения о первоначальном состоянии системы, которое важно для тест-кейса. А еще значения для ввода или передачи ПО.
• Шаги — полная последовательность действий. Ее выполняют, чтобы провести описываемую тест-кейсом проверку.
• Ожидаемый результат — описание планируемого поведения или результата ПО. Может базироваться на требовании к программному обеспечению, общей логике работы.
• Фактический результат — описание итогового поведения или результата ПО. Если они совпадают, это указывают. Когда не совпадают, подробно описывают расхождения. Пометка «не совпадает», «отличается» — это грубая ошибка.
• Статус — текущее состояние тест-кейса.

Правила составления тест-кейса

Разработка и написание тест-кейсов — дело нелегкое. Нужно учесть много правил и понять, из чего тест-кейс состоит. Разбираемся в правилах.

Создавайте простые тест-кейсы
То есть лаконичные и понятные не только вам. Используйте повелительное наклонение, например: «перейдите на домашнюю страницу», «введите данные», «нажмите здесь». Шаги должны быть четкие, без лишних деталей. Так проще понять шаги теста и ускорить работу.

Примеры понятных и непонятных описаний в тест-кейсах

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

Этому учат на курсе «Инженер по тестированию». Вы узнаете, на чём основана работа тестировщика, как учитывать поведение пользователей и оценивать качество работы. Во время учебы будете много практиковаться, а в конце получите диплом установленного образца.

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

Не предполагайте.
Не додумывайте функциональность и возможности ПО. Строго придерживайтесь спецификации.

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

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

Внедряйте методы тестирования. Эти техники помогают спланировать несколько тест-кейсов и находить ошибки:

• анализ граничных значений — проверяйте верхние и нижние границы для допустимого диапазона значений;
• эквивалентное разделение — разбивайте диапазон всевозможных тест-кейсов на равные части/группы с одинаковым поведением;
• техника перехода состояний — создавайте тест-кейсы, которые покроют поведение ПО при переходе из одного состояния в другое.

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

Создавайте повторяемые и самостоятельные текст-кейсы. Они должны всегда генерировать одинаковые результаты: независимо от того, кто их тестирует.

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

Учитесь создавать тест-кейсы и системы управления ими на курсе «Инженер по тестированию» в Skypro. Кроме этого узнаете, как писать чек-листы и тест-планы, составлять отчеты в системах отслеживания ошибок. Проведете функциональное, UX/UI- и регрессионное тестирование — и это только в одном модуле. На курсе рассмотрим еще и тестирование мобильных приложений и API, инструменты тестировщика. Получите больше 330 часов теории и практики, пройдете семь мастер-классов, создадите четыре проекта для портфолио. Доступ к материалам останется навсегда.

Шаблон и пример тест-кейса

Простая таблица, как написать тест-кейс.

В онлайн-университете Skypro есть программа «Инженер по тестированию» — на ней ученики осваивают профессию с нуля за двенадцать месяцев, делают четыре проекта для портфолио. Преподаватели — руководители отделов тестирования и старшие разработчики в ВТБ, Skyeng и других крупных компаниях. 95% выпускников выходят на работу в течение четырех месяцев: в этом помогает центр карьеры.

Главное о тест-кейсах

• 🟩 Тест-кейс — это четкое описание входных данных, условий выполнения, процедуры тестирования и ожидаемых результатов.
• 🟩 Исходным документом для тест-кейсов может быть чек-лист. Проваленный тест-кейс служит источником данных для баг-репорта, поэтому важно с самого начала понимать, как написать тест-кейс.
• 🟩 Обязательные атрибуты тест-кейса: уникальный идентификатор, краткое описание, входные данные. А еще шаги, ожидаемый результат, фактический результат, статус.
• 🟩 От правильности написания тест-кейсов зависит качество тестирования.
• 🟩 Создавайте простые тест-кейсы с учетом интересов конечного пользователя.
• 🟩 Как составлять тест-кейсы: избегайте повторов и не предполагайте, пишите тестовые примеры. Внедряйте методы тестирования, самоочистку, консультируйтесь с экспертами.