Что такое тест-кейс и как его правильно оформить

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

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

Содержание

• Что такое тест-кейс и из чего он состоит
• Как подготовиться к написанию тест-кейса
• Где оформить первый тест-кейс

Что такое тест-кейс и из чего он состоит

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

В разных компаниях требования к оформлению тест-кейсов могут различаться в зависимости от специфики проекта, но типичная структура выглядит так:

• Название — краткая формулировка, которая должна отражать суть и цель тест-кейса. По названию другие тестировщики должны сразу понимать, что именно проверяется. Например: «Проверка ограничения количества символов в поле комментария» или «Фильтрация товаров по цене от минимальной до максимальной».
• Предусловия — здесь вы описываете подготовительные действия, которые нужно выполнить перед тестом. К примеру, вам может понадобиться учётная запись с определёнными правами доступа, специальные данные для ввода или особое состояние системы.
• Шаги — это последовательные короткие действия, которые тестировщик должен выполнить в процессе проверки: «1. Перейти на главную страницу сайта», «2. Выбрать товар из каталога», «3. Нажать кнопку „Добавить в корзину“», «4. Перейти в корзину» и так далее. Шаги должны быть простыми и понятными, чтобы любой мог их повторить.
• Ожидаемый результат — это точное описание того, что должно произойти после выполнения всех шагов тест-кейса. Вот некоторые варианты: «Пользователь авторизуется и попадает в личный кабинет», «Система правильно отображает сообщение о сохранении данных», «Кнопка становится неактивной после двойного нажатия» и так далее.
• Статус — здесь вы отмечаете результат тестирования. Можно указать, что тест успешно пройден, не пройден, заблокирован, пропущен или ещё не выполнен. Статус помогает отслеживать прогресс тестирования.

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

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

Читайте также:

Баг-репорт: что это и как его правильно составить

Как подготовиться к написанию тест-кейса

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

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

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

Спланируйте тестирование. Тесты бывают разными — в зависимости от того, что мы хотим проверить. Есть три основных типа: позитивные, негативные и деструктивные. Они помогают взглянуть на продукт с разных сторон и выявить слабые места до того, как это сделает пользователь. Какой вариант выбрать — зависит от задач, которые вы определили в требованиях.

Например, при тестировании формы авторизации позитивный тест-кейс проверит вход с правильным логином и паролем, негативный — реакцию системы на неверный пароль или несуществующий логин, а деструктивный — что произойдёт при вводе слишком длинной строки символов, попытке SQL-инъекции в поле логина или любом другом нестандартном поведении.

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

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

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

Для срочных и объёмных задач можно использовать нейросеть. Подготовьте промпт с описанием задачи, а затем подкорректируйте полученный черновик. Ниже пример запроса, который вы можете взять за основу:

Читайте также:

Промпты для нейросетей: как правильно писать запросы к ChatGPT и другим нейронным сетям

Где оформить первый тест-кейс

Вы можете писать тест-кейсы в любой программе, которая позволяет работать с таблицами. Например, подойдут «Google Документы» или Excel.

Вот базовый минималистичный шаблон для работы в «Google Документах».

А это расширенный вариант с дополнительными столбцами для Excel.

Можно сделать ещё проще и оформлять тест-кейсы в виде большого списка. В этом случае удобно нумеровать шаги и следом прописывать ожидаемый или полученный результат. Вот пример подобной структуры:

Помимо обычных таблиц и списков, тестировщики часто используют специальные программы — Test Management Systems (TMS), или системы управления тестами. В них можно хранить большое количество сценариев, организовывать тест-кейсы по проектам, создавать тест-планы и автоматически формировать отчёты после выполнения тестов.

Систем управления тестами много, но в целом все они похожи — различаться могут только интерфейс и набор функций. Поэтому для первого знакомства можете выбрать любую на своё усмотрение. Мы воспользуемся российским сервисом Test IT, который позволяет бесплатно вести один личный проект.

После регистрации вы можете перейти в «Библиотеку тестов», нажать кнопку «Создать» и выбрать «Тест-кейс».

Вы перейдёте на страницу с шаблоном для заполнения данных, который структурно почти не отличается от нашей таблицы в «Google Документах».

Если говорить об особенностях, то в Test IT вы можете подробно описать каждое предусловие — указать не только действие, но и ожидаемый результат. Также платформа позволяет документировать постусловия, которые должны выполняться после завершения теста, и добавлять параметры — альтернативные данные для дополнительного тестирования. Ещё вы можете прикреплять ссылки, добавлять файлы и ссылаться на связанные автотесты.