Качество тест-кейса: балансы, показательность и типичные ошибки

← назад к разделу

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

Подробный кейс — не значит хороший

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

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

Кейс, который не проходится сам по себе

В понедельник прогон был зелёный, во вторник упало пять кейсов, а продукт не менялся — менялся порядок: двое разобрали набор пополам и пошли параллельно. Скрытая зависимость опаснее явной: предусловие «есть оплаченный заказ» выглядит честным, вот только заказ появляется на стенде потому, что кейс TC-12 стоит выше и его кто-то проходит. Видов три: общее состояние, общая учётная запись test17 (кейс «удалить профиль» ломает следующие двадцать) и одноразовый ресурс — промокод, 500 бонусов, три места на рейсе. Лечится тем, что предусловие описывает состояние мира и кто-то его реально готовит, а у кейса свои данные; нужную по существу цепочку оформляют явным последовательным набором.

Повторяемость — та же беда с другой стороны: кейс должен проходиться много раз подряд с одинаковым результатом. Ломают её уникальные данные (лечится генерацией: anna+2026-03-14-01@example.com), изменённое и не восстановленное состояние (лечится постусловием — поле под него есть в любой системе тест-менеджмента и пустует чаще остальных) и потраченный ресурс. Проверка обоих свойств — минута: пройдите кейс первым на свежем стенде, потом сразу второй раз подряд.

Хрупкий кейс и живучий: одна проверка в двух видах

Кейс падает либо потому, что в продукте ошибка, либо потому, что привязан к тому, что имеет право меняться. Второе — чистый убыток: время потрачено, находки нет. Запишем одну проверку — покупатель оформляет возврат доставленного заказа — дважды.

Хрупкий. «Возврат №4». Предусловия: войти под test17@example.com, пароль qwerty123; в базе заказ 10482 от 14 марта. Шаги: открыть https://stage-7.shop.internal/orders/10482; нажать вторую сверху серую кнопку справа; выбрать третий пункт списка; нажать «Отправить». Ожидается: зелёная плашка «Заявка №8 принята».

Живучий. RET-3 «Возврат доставленного заказа: заявка создаётся и видна покупателю», требование RTN-2 «возврат оформляется в течение 14 дней с даты доставки». Предусловия: покупатель из набора returns-ok с одним доставленным заказом, дата доставки — вчера. Шаги: открыть страницу заказа в «Моих заказах»; нажать «Оформить возврат»; выбрать причину «Не подошёл размер»; отправить заявку. Ожидается: открывается страница заявки с номером, в «Моих возвратах» она видна со статусом «На проверке» и ссылается на тот же заказ, статус заказа — «Оформлен возврат».

Второй кейс не длиннее — в нём шесть правок, и каждая убирает причину упасть без бага:

• Адрес стенда уехал из шагов: стенд переименуют — кейс молча проверит не ту сборку.
• Элемент назван подписью, а не положением: «вторая сверху серая кнопка» исчезает после перестановки, а «третий пункт списка» начнёт проверять другую причину возврата.
• Конкретная запись заменена свойствами данных: заказ 10482 живёт до пересборки стенда, test17 общий на всю команду.
• Пароль исчез из текста: учётные данные меняются чаще всего.
• Дата стала относительной: «от 14 марта» через месяц выпадет из окна в 14 дней, и набор покраснеет по календарю.
• Ожидаемый результат не требует буквального совпадения: цвет и текст плашки меняются без бага, а номер 8 зависит от числа заявок на стенде.

Расплывчатым кейс не стал. Правило такое: жёстко задают данные, определяющие ветку требования — 500 бонусов на заказ 3400 ₽ проверяют частичное списание, а не ограничение «не больше половины»; остальное описывают свойством («имя файла с пробелами и кириллицей»), а стенд, сборка и учётная запись принадлежат прогону.

Набор стареет сам: дубли и чистка

Продукт меняется каждую неделю, кейсы остаются полугодовой давности. Сначала появляются кейсы, которые «всегда падают по известной причине» и которым ставят «пройдено» по памяти, потом растёт доля заблокированных — и зелёный прогон перестаёт что-либо означать, хотя на «380 из 420 пройдено» опираются при решении о выпуске. Важная мелочь: если предусловия подготовить не удалось (нет пользователя, лёг стенд), кейс не провален, а заблокирован — продукт ещё не проверяли. Отмеченные как «не пройден», такие прогоны рисуют в отчёте эпидемию багов на пустом месте.

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

Дубли берутся от разных авторов и названий, от дословного копирования кейса из smoke в регресс и от механического применения техник тест-дизайна: −1, −5 и −100 при границе «не меньше нуля» лежат в одном классе эквивалентности, хватает одного. Ищут их группировкой кейсов по требованию — дубли оказываются рядом, и заодно видны пункты, на которые кейсов нет вообще. Из пары оставляют показательную, ожидания сливают. Удаляют кейс, когда проверяемого больше нет, когда проверка уехала на нижний уровень и когда он проверяет чужой код — браузер, операционную систему. Удаление идёт в архив, с причиной и датой, и не в одиночку.

Ревью кейсов в паре

Свой кейс автор не видит: он помнит состояние стенда и достраивает недостающее в уме. Пятнадцать минут чтения вдвоём ловят то, что иначе всплывёт через месяц посреди прогона. Вопросы идут в таком порядке, и формулировки в нём последние:

1. Откуда взят ожидаемый результат — из требования или с экрана? Списанный с экрана кейс зелёный ровно до дня, когда ошибку починят; выдуманное поведение лечится вопросом аналитику.
2. Можно ли выполнить кейс, ничего не спрашивая у автора. Читающий проговаривает шаги вслух, автор молчит; каждое «а тут как?» — находка.
3. Что будет, если пройти кейс не сейчас и не здесь — первым в пустом прогоне, второй раз подряд, через месяц на другом стенде.
4. Найдётся ли кейс поиском и не дубль ли он.

И только потом формулировки: безличные глаголы, настоящее время в ожидаемом результате. Сюда же правило, видное одним взглядом: ожидаемый результат всегда описывает корректную работу. Даже в жёстком негативном кейсе ожидание не «приложение падает с потерей данных», а «появляется сообщение „Невозможно сохранить файл: недостаточно места“».

Коротко

• Качество кейса — не подробность, а показательность: что должно сломаться в продукте, чтобы он покраснел?
• Кейс не опирается на соседей и проходится дважды подряд. Проверка: пройти первым на свежем стенде, потом сразу ещё раз.
• Хрупкость — привязка к тому, что имеет право меняться: положение кнопки, запись в базе, календарная дата, номер заявки.
• Жёстко задают данные, определяющие ветку требования; остальное — свойством. Стенд, сборка и пароли принадлежат прогону.
• «Заблокирован» и «не пройден» — разное: во втором случае найден дефект, в первом продукт ещё не проверяли.
• Кейс удаляют, когда проверяемого нет, проверка уехала на нижний уровень или он проверяет чужой код: в архив, с причиной, не в одиночку.

Что почитать дальше

• Как писать тест-кейс — состав кейса и откуда берётся ожидаемый результат.
• Чек-листы и тестовые данные — когда подробный кейс не нужен и откуда брать данные вместо конкретной записи.
• Тест-менеджмент: TestRail, Qase, Zephyr — где живёт набор и чем архив отличается от удаления.
• Пользовательские сценарии и наборы кейсов — когда зависимость кейсов друг от друга законна.