Как написать тест-кейс: структура, пример и ошибки новичка

Вячеслав Степанов — проджект-менеджер, ментор · 21 октября 2026

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

Если видео не открывается — смотри на YouTube (может понадобиться VPN).

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

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

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

Формат тест-кейса давно устоялся: его описывали ещё в стандарте IEEE 829 по документации тестирования (1983), сегодня он закреплён в международном стандарте ISO/IEC/IEEE 29119-3. На практике команды используют упрощённую версию, о ней ниже.

Когда пишут тест-кейсы

Кейсы пишут по требованиям, пока разработчик пишет код. Причин две.

Первая причина касается достоверности проверки. Если писать кейс по готовому продукту, в ожидаемый результат попадает то, что продукт уже делает. Открыл экран, увидел «5100» — записал «показывается 5100». Ошибка узаконена. Ожидание из требования («сумма с разделителем разрядов и знаком рубля») сразу покажет расхождение.

Вторая причина — деньги. Пока тестировщик пишет кейсы, он натыкается на дыры в требованиях: «а что показывать, если должников нет?». Такой вопрос до написания кода стоит пяти минут разговора, после релиза — исправления в следующем спринте.

Из чего состоит тест-кейс

Формат Given / When / Then («дано / когда / тогда») пришёл из подхода BDD, который описал Дэн Норт в середине 2000-х. По нему же видно качество требований: из хорошего критерия кейс собирается за минуту. Если не собирается — в задаче чего-то не хватает, и лучше выяснить это до начала разработки.

Пример тест-кейса

Возьмём фичу: экран «Долги учеников» в сервисе для репетиторов. Критерий приёмки: если у репетитора есть ученики с неоплаченными занятиями, рядом с названием вкладки показан кружок с их числом.

Название:   На вкладке «Долги учеников» показан кружок с числом должников
Предусловие: репетитор вошёл в систему; у двух учеников есть
             неоплаченные занятия
Шаги:
  1. Открыть раздел «Оплаты»
     → раздел открылся, видны вкладки
  2. Посмотреть на вкладку «Долги учеников»
     → рядом с названием стоит кружок с числом 2

Кейс проверяет одну вещь. Для проверки «кружок пропадает, когда должников нет» пишут другой кейс со своим предусловием. Качество кейса проверяют так: человек, который фичу никогда не видел, должен пройти по шагам и получить тот же результат. Если где-то придётся догадываться, кейс переписывают.

Как собрать список проверок

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

1. По критериям приёмки. Идёшь по критериям сверху вниз, и каждый получает хотя бы одну проверку. Так видна полнота и находятся требования, которые на экране не заметишь (например, работа на узком экране телефона).
2. По экрану. Выписываешь, из чего состоит экран: вкладки, колонки, кнопки, поля, состояния (загрузка, пустой список, ошибка). Здесь часто всплывает поведение, которого в критериях нет. С такой находкой идут с вопросом к продакт-оунеру и не проверяют «как получилось».
3. «А что если». Проходишь путь пользователя и в каждой точке спрашиваешь: а если данных нет? а если их сотня? а если нажать дважды? а если у ученика нет ни одного канала связи? Каждый ответ — отдельная проверка.

Маленькая фича не значит мало проверок: путь в шесть шагов легко даёт два десятка вопросов. Объём проверок определяет количество развилок на пути.

Какие значения проверять

Перебрать все значения невозможно: задержка оплаты может быть 1, 2, 57 или 300 дней. Поэтому используют приёмы тест-дизайна. Два самых известных описал Гленфорд Майерс ещё в книге «The Art of Software Testing» (1979), и их до сих пор спрашивают на собеседованиях тестировщиков.

• Классы эквивалентности. Значения делят на группы, внутри которых продукт ведёт себя одинаково. Из каждой группы достаточно одного значения: если на 5 днях плашка серая, на 6 она тоже будет серой.
• Граничные значения. Ошибки живут на переходах между группами. В коде стоит одно сравнение, и самая частая опечатка в нём: перепутать «больше» с «больше или равно». Поэтому у каждой границы проверяют пару соседних значений.

Границы есть почти везде, где значения выстраиваются в ряд:

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

Где хранят тест-кейсы

В небольших командах кейсы иногда ведут в таблице. Но удобнее специальные системы управления тестированием: они хранят кейсы, собирают прогоны и показывают, что прошло, а что упало. Популярные варианты — Zephyr, который встраивается прямо в Jira, и TestRail.

Кейсы раскладывают по папкам — обычно по экранам или фичам, чтобы через полгода найти нужный. У кейса есть статус: черновик, пока набор не согласован; согласован, когда кейс начинает попадать в прогоны; устарел, когда фича изменилась (история прогонов при этом сохраняется). На прогоне каждому кейсу ставят итог: прошёл, упал или заблокирован. На каждый упавший кейс заводят баг-репорт. Как его оформить, я разобрал в статье про баг-репорт.

Зачем это проджект-менеджеру

• Понимать вопросы тестировщика. Вопросы QA по требованиям находят самые дешёвые баги проекта: те, что видны ещё до кода.
• Проверять покрытие. У каждого критерия приёмки должен быть хотя бы один кейс. Это быстрый способ убедиться, что ничего не забыли.
• Закладывать время на тестирование. Написание кейсов, подготовка данных и прогон — отдельная работа, и в плане спринта на неё нужно время.
• Читать отчёт о прогоне. По цифрам отчёта (сколько кейсов прошло, сколько упало, что заблокировано) проджект решает, готов ли релиз.

Типичные ошибки

• Размытый шаг. «Открыть долги»: каждый откроет по-своему. Пиши шаг как команду: что нажать и что ввести.
• Ожидаемый результат вписан после прогона. Тогда он описывает то, что продукт сделал, и проверка теряет смысл. Решается так: ожидание формулируют заранее, из требований.
• Имена вместо свойств в предусловии. «У Даниила есть долг»: непонятно, сколько занятий и есть ли другие должники. Помогает описание свойств данных: сколько учеников, сколько неоплаченных занятий.
• Один кейс на всю фичу. Двадцать шагов упадут на третьем, и непонятно, что сломано. Выход: одна проверка, один кейс.
• Проверены только «хорошие» сценарии. Пустой список, повторное нажатие и граничные значения остались без внимания. Чтобы этого не было, делай третий проход «а что если» и проверяй границы.

Частые вопросы