Кейсы, написанные под текущий интерфейс, умирают вместе с ним. Кнопка «Войти» стала зелёной, лейбл поменяли на «Продолжить», модалку перетащили вправо, и вот уже 30 проверок в системе управления тестированием горят красным, хотя логика входа не изменилась ни на байт. Проблема не в том, что продукт меняется. Проблема в том, что кейс описывает декорации вокруг поведения, а не само поведение. Долговечный тест-кейс устроен на иных принципах: он фиксирует, что должно произойти, и почти не трогает, как это выглядит. В статье — шаблон, примеры хороших и плохих кейсов и сравнение TMS, чтобы было из чего выбрать.
ВАМ ПРИШЛО ПРИГЛАШЕНИЕ 💌
Приходите к нам в соцсети поделиться своим мнением и почитать, что пишут другие. А ещё там выходит дополнительный контент, которого нет на сайте — шпаргалки, опросы и разная дурка. В общем, вот тележка, вот ВК — велком!
Что такое тест-кейс
По глоссарию ISTQB тест-кейс — это набор предусловий, входных данных, действий, ожидаемых результатов и постусловий, собранных под конкретную цель проверки. Формулировка сухая, но в ней уже спрятан ответ на главный вопрос: кейс проверяет одну цель. Если целей две, это два кейса.
Новички часто путают четыре артефакта, которые живут рядом.
Чек-лист перечисляет проверки без шагов и данных: «вход по email — ок, вход с неверным паролем — ок».
Тест-сценарий описывает пользовательский путь целиком, без конкретных шагов и данных.
Тест-кейс даёт пошаговый рецепт с конкретными данными и проверяемым результатом.
Баг-репорт фиксирует расхождение между ожиданием и фактом.
| Артефакт | Что описывает | Когда использовать |
| Чек-лист | Список проверок без шагов и данных | Для быстрой проверки идей и smoke-тестов |
| Тест-сценарий | Сценарий целиком, включая контекст | Для планирования покрытия и обсуждения с командой |
| Тест-кейс | Пошаговый рецепт с данными и результатом | Для воспроизводимых проверок и регрессии |
| Баг-репорт | Расхождение между ожиданием и фактом | Когда тест упал и нужно описать проблему |
Разница видна на простых примерах:
- «Проверить авторизацию» — сценарий.
- «Вход с валидным email и паролем» — кейс.
- «Поле email принимает строку без @ — форма показывает ошибку» — тоже кейс, только про валидацию.
- Чек-лист скажет «проверить валидацию email», но не объяснит, что именно вводить и что должно появиться на экране.
Структура тест-кейса
Обязательных полей меньше, чем кажется. ID нужен, чтобы ссылаться на кейс из баг-репорта и автотеста. Название отвечает на вопрос «что проверяем и при каком условии». Приоритет говорит, что запускать первым, когда времени на прогон мало. Предусловия описывают состояние системы до первого шага — «пользователь авторизован», «корзина пуста», но не содержат действий.
Действия идут по одному на строку. Тестовые данные лежат отдельно от шагов, иначе при смене пароля придётся править весь кейс. Ожидаемый результат проверяется однозначно. Постусловия нужны там, где тест оставляет мусор: удалить созданного пользователя, очистить корзину. Статус показывает, жив кейс или устарел.
| Поле | Обязательность | Назначение |
| ID | Да | Уникальный идентификатор для ссылок из баг-репортов и автотестов |
| Название | Да | Что проверяем и при каком условии |
| Приоритет | Да | Порядок запуска при ограниченном времени |
| Предусловия | По ситуации | Состояние системы до первого шага |
| Тестовые данные | По ситуации | Конкретные значения, вынесенные отдельно от шагов |
| Шаги | Да | Действия по одному на строку |
| Ожидаемый результат | Да | Проверяемый итог, без слов «корректно» и «правильно» |
| Постусловия | По ситуации | Что убрать за тестом |
| Статус | Да | Активен, устарел или удалён |
Поле «предусловие» — главный источник путаницы. «Открыть браузер и залогиниться» — это не предусловие, это шаг. Предусловие звучит так: «Пользователь с ролью admin находится на странице управления пользователями». Действий внутри нет. Только состояние.
Шаблон тест-кейса
Пустой шаблон выглядит так. Его можно перенести в Google Таблицы или в свою TMS, если поля называются иначе.
| ID | Название | Приоритет | Предусловия | Тестовые данные | Шаги | Ожидаемый результат | Постусловия | Статус |
Заполненный пример для входа по email и паролю:
| ID | Название | Приоритет | Предусловия | Тестовые данные | Шаги | Ожидаемый результат | Постусловия | Статус |
| TC-AUTH-001 | Вход с валидными email и паролем открывает профиль | Высокий | Пользователь зарегистрирован, аккаунт активен, пользователь не авторизован | email: valid_email; пароль: valid_password | 1. Открыть страницу входа. 2. Ввести email. 3. Ввести пароль. 4. Отправить форму входа. | Открылась страница профиля, в шапке отображается email пользователя | Разлогиниться | Активен |
Обратите внимание на шаг «отправить форму входа». В нём нет ни цвета кнопки, ни её текста, ни координат на экране. Это сделано специально — об этом ниже.
Как написать тест-кейс по шагам
Процесс стартует с требования. TMS подключается позже, когда уже понятно, что именно проверяем. В основе — пять этапов, которые экономят больше времени, чем кажется на первый взгляд. Пропустить любой из них можно, но тогда кейс придётся переделывать — либо на ревью, либо, что хуже, на прогоне, когда время уже поджимает:
- Разобрать требование. Читаем, что должно происходить, и выписываем условия и результаты. Если требование говорит «пользователь может войти и увидеть баланс», здесь уже два разных поведения. Требование может быть устным, в тикете или в описании задачи, важно, чтобы доступ к нему был у всей команды. Если формулировка размытая, обращаемся к аналитику или продакту и уточняем. Писать кейс по догадкам — верный способ переделывать его через неделю.
- Выделить одну проверку. Из разобранного требования берём одно поведение, которое можно проверить и на которое можно однозначно ответить «прошло» или «упало». Если поведений несколько, это несколько кейсов. Смешивать их нельзя, иначе падение одного утащит за собой диагностику другого.
- Подобрать данные. Здесь работают классы эквивалентности и граничные значения. Для поля «возраст» с допустимым диапазоном 18–65 отдельно проверяем 17, 18, 65 и 66. Для строки длиной до 20 символов — 19, 20, 21. Для email один валидный адрес и один без @ закроют два класса. Границы проверяются отдельно, потому что ошибки чаще всего живут именно там: середина диапазона обычно ведёт себя предсказуемо. Всё это даёт способ не гонять бесконечные варианты вручную, без академической теории за плечами. Данные лучше сразу вынести в отдельные переменные, чтобы при смене пароля или email не пришлось править весь кейс.
- Заполнить поля. ID, название, приоритет, предусловия, данные, шаги, ожидаемый результат, постусловия. Название и ожидаемый результат — самые важные, о них ниже. Шаги пишем по одному действию на строку. Если шаг звучит как «нажать синюю кнопку в правом верхнем углу», лучше переформулировать: кейс цепляется за оформление, а оформление меняется.
- Отдать на ревью. Кейс смотрит другой тестировщик или разработчик, который писал эту часть продукта. Свежий глаз ловит шаги, которые автор считает очевидными, а коллега воспроизвести не может. Ревью занимает пять минут, а экономит часы на прогоне.
После пятого шага кейс готов к сохранению. Дальше его запускают, правят, иногда удаляют. Но если первые пять шагов сделаны без пропусков, править придётся реже.
Как назвать тест-кейс
Название — первое, что видит коллега в списке из сотен кейсов. От него зависит, найдёт человек нужную проверку за пару секунд или будет открывать каждую подряд.
Формула простая: что проверяем плюс при каком условии. «Вход» — плохое название, потому что под него можно подшить всё что угодно. «Вход с корректными email и паролем» — хорошее: сразу понятно, какие данные и какой сценарий. «Вход с email без символа @» — тоже хорошее, потому что фиксирует негативный кейс.
Название не должно звучать как заголовок отчёта. «Проверка работоспособности механизма аутентификации» — попытка написать диссертацию в поле длиной в одну строку. Для списка кейсов такое название бесполезно: по нему не понять, что именно проверяется. Чем короче и конкретнее, тем быстрее коллега найдёт нужный кейс в списке из пятисот. Но название — только половина дела. Вторая половина — ожидаемый результат, без которого кейс нечем закрыть.
Как сформулировать ожидаемый результат
Ожидаемый результат — вторая половина кейса. Если название отвечает на вопрос «что проверяем», результат отвечает на вопрос «как поймём, что прошло».
«Всё работает» — не результат. «Открылась страница профиля, в шапке отображается email» — результат. «Корректно» и «правильно» ничего не проверяют, потому что у каждого своё представление о корректности. Результат должен быть таким, чтобы два разных тестировщика, выполнив шаги, пришли к одному выводу: кейс прошёл или упал.
Если результат содержит визуальную деталь, он стареет вместе с интерфейсом. «Кнопка стала синей» переживёт ровно до следующего релиза дизайна. «Форма отправилась, пользователь перенаправлен в профиль» переживёт смену палитры, типографики и расположения элементов.
Примеры хороших и плохих тест-кейсов
Возьмём авторизацию.
Плохой кейс: «Ввести email, ввести пароль, нажать синюю кнопку „Войти“ в правом верхнем углу, проверить, что всё ок». Проблемы: привязка к цвету и положению, размытый результат, несколько действий в одном шаге.
Хороший кейс: «Ввести валидный email, ввести валидный пароль, отправить форму. Ожидание: открылась страница профиля, в шапке email пользователя». Тот же сценарий, но он не сломается, когда кнопку перекрасят и перенесут.
Второй пример — промокод в корзине.
Плохой кейс: «Применить промокод SALE10, проверить скидку». Что значит «проверить скидку»? Где смотреть? На какой сумме?
Хороший кейс: «В корзине товар на 1000 ₽, ввести промокод SALE10 и применить его. Ожидание: итоговая сумма 900 ₽, в корзине отображается скидка по промокоду SALE10 — 100 ₽». Здесь есть данные, действие и проверяемая цифра.
| Как написано | В чём проблема | Как исправить |
| «Нажать синюю кнопку в правом верхнем углу» | Привязка к цвету и положению, ломается при редизайне | «Отправить форму входа» |
| «Проверить, что всё работает» | Результат нельзя проверить однозначно | «Открылась страница профиля, в шапке email» |
| «Ввести корректный пароль» | Нет конкретных данных | «Ввести пароль из переменной valid_password» |
| «Выполнить шаги из TC-005» | Зависимость от другого кейса | Повторить нужные шаги или вынести их в общие |
Типовые ошибки, которые встречаются чаще всего: несколько проверок в одном кейсе, шаги без данных, ожидаемый результат в стиле «всё работает», зависимость от другого кейса. Последняя особенно опасна: если TC-005 упал или его удалили, текущий кейс превращается в тыкву.
Полезный блок со скидкой
По промокоду: KOD (можно просто нажать) — вы получите скидку на все курсы Практикума.
Если хочется писать тест-кейсы и баг-репорты, разбирать техники тест-дизайна и работать с TMS на реальных проектах, посмотрите курс Инженер по тестированию. Если ручные проверки уже надоели и вы хотите превращать их в автотесты, подойдёт Автоматизатор тестирования на Python. А тем, кому ближе работа с требованиями, с которых начинается любой кейс, стоит заглянуть на курс Системный аналитик.
В Практикуме есть и бесплатные вводные курсы по всем направлениям, от тестирования до аналитики.
Долговечные тест-кейсы
Интерфейс меняется чаще логики. Кнопки переезжают, лейблы переписывают, модалки заменяют на страницы. Логика входа остаётся той же: пользователь вводит учётные данные, система проверяет, открывает доступ. Кейс, который цепляется за оформление, стареет вместе с оформлением. Кейс, который описывает действие и результат, без проблем переживёт редизайн.
Один кейс проверяет одно поведение
Атомарность звучит как термин из учебника, но за ним стоит прямая выгода. Когда кейс проверяет одно поведение, его падение сразу говорит, где искать причину. Когда в одном кейсе смешаны вход, баланс и выход, падение не говорит ничего: непонятно, сломался вход, баланс или кнопка «Выйти». Атомарный кейс можно запустить отдельно от остальных, и он не потянет за собой цепочку зависимостей.
Описывайте действие, а не элемент интерфейса
Это главное правило долговечности. «Нажать синюю кнопку „Войти“ в правом верхнем углу» — кейс, который умрёт при первом редизайне. «Отправить форму входа» — кейс, который переживёт смену цвета, текста и положения. Разница в том, что во втором случае тестировщик ищет на странице форму и отправляет её, а не ищет конкретный пиксель.
Правило работает не только для кнопок. «Ввести email в поле с плейсхолдером „Введите email“» стареет, когда плейсхолдер меняют на «Email». «Ввести email в поле email» стареет, когда меняют тип поля или добавляют маску. «Ввести email пользователя» не стареет почти никогда, потому что описывает намерение, а не реализацию.
Общие шаги и параметризация
Повторяющиеся шаги — авторизация, открытие корзины, переход в настройки — не нужно копировать в каждый кейс. TMS позволяют вынести их в общие шаги: меняешь один шаг, обновляются все кейсы, которые на него ссылаются. Это экономит не только время на правку, но и нервы: не приходится искать по всей базе, где ещё остался старый пароль.
Тестовые данные лучше хранить отдельно от шагов. Если пароль лежит в переменной, при его смене правится одна строка, а не двести кейсов. Параметризация превращает кейс из жёсткой инструкции в шаблон, который подставляет разные данные под разные условия.
Когда кейс пора удалить
Не каждый кейс заслуживает вечной жизни. Если функциональность удалили из продукта, кейс уходит вместе с ней. Если проверку полностью закрывает автотест, ручной кейс дублирует работу и создаёт ложное чувство покрытия. Если кейс годами не падал и при этом не покрывает риск, который команда считает важным, он превратился в ритуал.
Удаление — нормальная часть поддержки. База из тысячи кейсов, половина которых не запускалась с прошлого года, выглядит солидно только в отчёте. В работе она мешает: непонятно, что действительно проверяется, а что существует по инерции.
Где хранить тест-кейсы и когда таблиц уже мало
Google Таблицы работают, пока кейсов десятки и тестировщик один. Потом появляются прогоны, история падений, связи с задачами в Jira, общие шаги, и таблица превращается в набор листов, в которых никто не помнит, какая версия актуальна. В этот момент команды переходят в TMS.
Сравнивать TMS по одной цене бессмысленно: у них разные модели оплаты, разная доступность в России и разный набор функций.
Короткая сводка на ноябрь 2026 года. Цены и условия сверены с сайтами вендоров и обзорами:
| TMS | Модель цены | Облако или своя установка | Интеграция с Jira | Общие шаги | Доступность в России |
| Test IT | Подписка; облако от 32 193 ₽ в год за пользователя, сервер от 4 466 ₽ в месяц | Облако или сервер | Да | Да | Российское ПО, реестр № 6125 |
| Zephyr | За каждого пользователя Jira; до 10 пользователей — $10 в месяц, дальше $5,99–8,73 за пользователя, для больших команд ставка снижается | Облако; Data Center — только для тех, кто купил его до 30 марта 2026 | Да, нативно | Да | Через Atlassian Marketplace; оплата в долларах |
| TestRail | За место; Essentials от $22, Professional от $37, Enterprise от $74 при годовой оплате | Облако и self-hosted; на сервере минимум 10 мест | Да | Да | Покупка из России затруднена: оплата в долларах зарубежной картой; часть команд мигрирует на российские TMS |
| Google Таблицы | Бесплатно | Облако | Через сторонние плагины или вручную | Вручную | Доступны |
Test IT — российская TMS, входит в реестр отечественного ПО с 2020 года, регистрационный номер 6125. Хранит ручные и автоматизированные тесты в одной системе, интегрируется с Jira и другими трекерами, умеет генерировать тест-кейсы из описания задачи с помощью ИИ. Подходит командам, которым нужен отечественный софт с облачной или серверной установкой. В 2026 году продукт совместим с Ред ОС 8.02, что снимает ограничения для регулируемых отраслей.
По цене на ноябрь 2026 года: облачный тариф «Стандарт» стоит от 32 193 ₽ за пользователя в год и рассчитан на команды до 100 человек. Серверная версия «Про» обойдётся от 53 600 ₽ за пользователя в год, минимальный порог — три пользователя. Есть и бесплатный тариф «Базовый» для одного проекта и до пяти пользователей, а также пробный период на 14 дней для «Стандарта».
Zephyr — семейство приложений SmartBear внутри Jira. Названия окончательно закрепились после переименования 2025 года: бывший Zephyr Squad теперь называется Zephyr Essential, флагманская версия — Zephyr Standard (раньше Zephyr Scale), плюс появился Zephyr Advanced. Оплата привязана ко всем пользователям Jira на сайте, а не только к тестировщикам. Если в компании 250 пользователей Jira и пять тестировщиков,за Zephyr придётся платить за всех 250. Для больших команд ставка за пользователя ниже, но платить всё равно придётся за всех. Отдельный вопрос — доступность: Atlassian ушла из России и блокирует облачные аккаунты российских команд, поэтому для работы из РФ Zephyr практически не подходит.
Цены на ноябрь 2026 года: для сайта Jira до 10 пользователей Zephyr Essential и Zephyr Standard стоят по $10 в месяц, Zephyr Advanced — $15. Выше 10 пользователей цена считается за каждого пользователя Jira: Essential — $5,99, Standard — $6,81, Advanced — $8,73 в месяц.
TestRail — отдельная TMS с оплатой за место. На ноябрь 2026 года тарифная сетка выглядит так. Essentials стоит $22 за место в месяц при годовой оплате (или $25 при месячной), но доступен только в облаке и только командам до пяти человек. Professional — $37 за место в месяц при годовой оплате (или $41 при месячной). Enterprise — $74 за место в месяц, только при годовой оплате. Бесплатного тарифа нет, есть пробный период на 30 дней. Есть облако и self-hosted, для self-hosted нужно минимум 10 мест и годовой контракт. Интегрируется с Jira, GitHub, GitLab, Azure DevOps и инструментами автоматизации.
Что выбрать
Если команда работает в Jira за пределами России и не хочет выносить тестирование в отдельное окно, Zephyr даёт минимальный разрыв между задачей и тест-кейсом.
Если требование отечественного ПО жёсткое, Test IT закрывает и ручное, и автоматизированное тестирование в одном месте.
Если команда небольшая и готова платить за место, TestRail даёт зрелую работу с прогонами и покрытием.
Если кейсов пока мало, таблица ничем не хуже, но как только появляется второй тестировщик, общие шаги и история прогонов становятся способом не сойти с ума.
Вопросы и ответы
Чем тест-кейс отличается от чек-листа?
Чек-лист перечисляет проверки без шагов и данных. Тест-кейс даёт пошаговый сценарий с конкретными входными значениями и проверяемым результатом. Чек-лист быстрее писать, кейс легче воспроизвести другому человеку.
Сколько шагов должно быть в тест-кейсе?
Столько, сколько нужно для одной проверки. Обычно от трёх до семи. Если шагов двадцать, скорее всего, в кейс случайно попал ещё один сценарий.
Нужны ли тест-кейсы, если есть автотесты?
Нужны, если автотест не покрывает риск или если его результат непонятно как интерпретировать. Автотест проверяет то, что в него заложили. Ручной кейс проверяет то, что заметил человек.
Можно ли генерировать тест-кейсы нейросетью?
Можно, и TMS это уже умеют. Но черновик от ИИ требует ревью: модель не знает, какой риск для продукта важнее, и может придумать шаг, которого нет в интерфейсе. Генерация ускоряет старт, но не отменяет проверку.
Какую TMS выбрать начинающему тестировщику?
Ту, которая стоит у команды. Навык работы с TMS переносится между инструментами: поля называются по-разному, логика остаётся той же. Если команда ещё не выбрала, Test IT даёт бесплатный доступ к облачной версии, а Zephyr и TestRail можно попробовать в триале.
Чек-лист перед сохранением кейса
Перед сохранением кейса стоит пройтись по короткому списку. Если хотя бы один пункт не сходится, кейс лучше поправить сразу, чем ловить проблему на прогоне:
- одна проверка — один кейс;
- название отвечает, что и при каком условии проверяется;
- предусловие описывает состояние, а не действие;
- шаги не цепляются за цвет, текст и положение элементов;
- тестовые данные лежат отдельно или вынесены в параметры;
- ожидаемый результат можно проверить глазами и сказать «да» или «нет» без дополнительных уточнений;
- постусловия убирают за тестом, если он что-то создал.
Если все пункты сходятся, кейс переживёт и редизайн, и смену TMS. Логика останется, а инструмент — дело наживное. Следующий шаг — разобрать, как из упавшего кейса собрать баг-репорт, который разработчик поймёт с первого раза, или перейти к тест-дизайну и посмотреть, какие проверки вообще стоит писать под конкретный продукт.
Советуем дальше почитать
Как тестируют фронтенд — юнит-, интеграционные, E2E- и визуальные тесты и инструменты, которые ловят изменения интерфейса раньше ручного прогона.
End-to-End-тестирование — как проверяют пользовательский путь целиком, почему такие тесты хрупкие и как их стабилизировать.
Делаем простые автотесты на Python — первый автотест на unittest: функция, ожидаемый результат и проверка.
Зачем нужен таск-трекер и баг-трекер — как трекеры вроде Jira распределяют задачи и баги между ролями и когда команде они действительно нужны.
Что почитать начинающему тестировщику — пять книг от «Тестирования dot com» до книги Ли Копленда о тест-дизайне.
Бонус для читателей
Тест-дизайн, TMS и написание кейсов, которые живут дольше одного релиза, приходят с практикой. Курсы не напишут кейсы за вас, но дадут базу: как разбирать требования, какие бывают техники тест-дизайна, как устроены системы управления тестированием. Дальше — практика и опыт.
Для тех, кто хочет прокачаться в QA или смежных областях, у нас есть промокод KOD. Он даст скидку на любой платный курс. Бесплатные курсы тоже есть — по всем специальностям, начать можно в любой момент, карту привязывать не нужно.
