В пятницу вы час разбирались с новой оплатой бонусами и написали в задаче «проверено, работает». Через три недели покупатель жалуется: бонусы списались, а сумма к оплате не изменилась. Какой был заказ, сколько бонусов лежало на счёте — ответа нет ни у кого, и тот же случай ещё надо суметь повторить.
Записанная проверка называется тест-кейсом: что готово до начала, какие действия с какими данными, какой результат считается правильным. Памяти хватает на неделю, а выполняет проверку не только автор. Половина вопросов появляется, пока её записываешь: в требовании не сказано, как быть, когда бонусов больше суммы заказа, — правка в требовании стоит разговора, в готовой оплате — выпуска.
Сверху — шаг, понятный только автору: в нём нет ни данных, ни того, с чем сравнивать результат. Разворачивается он всегда одинаково: что должно быть готово, какие действия с какими числами, и один проверяемый итог вместо «работает».
Из чего собран кейс и что ломается без каждой части
Поля выглядят бюрократией, пока одно из них не окажется пустым.
Идентификатор BONUS-14 — иначе на кейс не сослаться в баге и отчёте: «третий сверху» ломается при первой перестановке. Название ищут в списке из двухсот строк: «Оплата заказа: 500 бонусов частично покрывают сумму» находится, «Проверка оплаты 2» — нет. Предусловия — состояние мира до первого шага: без них кейс тонет в подготовке или не проходится, потому что бонусы брать неоткуда. Ожидаемый результат — то, с чем сравнивают: без него «пройдено» ставят за то, что ничего не упало. Тестовые данные: один возьмёт заказ на 3400 ₽, другой на 600 ₽, где включается ограничение «не больше половины». Приоритет нужен, когда до выпуска четыре часа, а кейсов на два дня: без него режут сверху и теряют списание денег. Ссылка на требование отвечает на «так и задумано» пунктом, а не памятью о чате.
Ядро обязательно всегда — название, предусловия, шаги, ожидаемый результат.
Шаг, который повторит другой человек
Шаг пишут для человека, которого нет рядом: он не спросит, что вы имели в виду, и функцию видит впервые. Четыре правила убирают место для догадки. Одно действие на шаг: по отметке «упал шаг 2» на строке «открыть корзину, применить бонусы и оплатить» не понять, что сломалось. Элементы называют подписью с экрана: не «включить списание», а «включить переключатель „Списать бонусы“» — в коде, в требовании и на кнопке имена совпадают редко. Данные ставят в шаг: «корректное количество бонусов» — угадывание, «оставить в поле „Сколько списать“ значение 500» — данные. И шаг — действие, а не вывод: «проверить, что всё работает» не говорит ни что нажать, ни с чем сравнивать, и исполнитель скорее поставит «пройдено», чем придумает проверку. Рядом ловушка — шаг про невидимое: «дождаться, пока начислятся бонусы» переписывают на видимый признак, обновить «Мои бонусы» и посмотреть баланс. Заодно выясняется, что ждать иногда приходится минуту, — вопрос к требованию.
Откуда берётся ожидаемый результат
Записать то, что сделал продукт, — самый простой способ и самая частая ошибка: такой кейс описывает поведение продукта через само это поведение, узаконивает ошибку в расчёте и краснеет, когда её чинят. Берут результат из требования — задачи, критериев приёмки, макета, ответа аналитика. На все вопросы кейса оно отвечает редко: случай не описан вовсе, описан дважды и по-разному или описан непроверяемыми словами. Придумывать ответ самому нельзя, он не лучше списанного с экрана: вопрос идёт аналитику, а какими бывают дыры — в статьях про требования и их свойства.
Главное свойство результата — проверяемость: «к оплате 2900 ₽, статус „Оплачен“, на счёте 0» сравнивают с фактом без обсуждения, под «скидка применилась» подходит любой исход. Смотрят не только на экран: что бонусы списались один раз, а не дважды, видно запросом к базе, ушедшую сумму — во вкладке «Сеть»; виден результат только там — так в кейсе и пишут.
Оплата бонусами: плохой кейс и он же переписанный
Формально с ним всё в порядке: название «Проверка оплаты 2», предусловия не заполнены, шаги «зайти в магазин; оформить заказ; оплатить бонусами; проверить, что всё работает», результат «оплата проходит корректно». Исполнитель сам добудет бонусы и сам выберет заказ — то есть сам решит, какой случай проверяет. А упасть кейс не может: «оплата проходит корректно» подходит и к списанию 500 бонусов, и к списанию нуля при нетронутой сумме. Ломается он не на оформлении, а на конкретности. Он же с конкретностью:
BONUS-14Оплата заказа: 500 бонусов частично покрывают сумму. Приоритет высокий — деньги покупателя; требование BON-7 «бонусами оплачивается не больше половины суммы, 1 бонус = 1 ₽»- Предусловия: покупатель
anna@example.comвошёл в магазин; на счёте 500 бонусов; в корзине один товар за 3400 ₽; доставка выбрана и бесплатна - Шаги: нажать в корзине «Перейти к оплате»; включить «Списать бонусы»; в поле «Сколько списать» оставить 500; нажать «Оплатить картой»; ввести карту
4111 1111 1111 1111, срок12/30, код123и подтвердить - Ожидаемый результат: после шага 3 в строке «К оплате» — 2900 ₽ и подпись «Списано 500 бонусов»; после шага 5 открывается «Заказ оплачен» с номером; в «Мои заказы» статус «Оплачен», сумма 2900 ₽; на «Моих бонусах» баланс 0
Предусловия задали случай, где ограничение заведомо не срабатывает: 500 меньше 1700, лимит проверит соседний кейс. Данные в шагах делают два прогона прогонами одного и того же кейса. А результат стал числом — и обнулённый баланс ловит случай, когда сумма на экране пересчиталась, а бонусы не списались.
Одна проверка — один кейс, и почему их всё равно несколько
Дописать «заодно» письмо, возврат и ограничение в половину суммы — соблазн дорогой: «кейс не пройден» перестаёт говорить, что сломалось, а сам кейс останавливается на первом расхождении. Рядом с правилом одна проверка — один кейс живёт независимость: кейс не опирается на соседний, иначе порядок прогона становится частью проверки (чем это лечится). Поэтому на функцию кейсов несколько: позитивный — как всё идёт правильно, и негативные — что идёт не так; багов в них больше, удачный путь разработчик проходит сам. Вокруг BONUS-14 их минимум пять: 500 бонусов на заказ 600 ₽ — списать не больше 300; пустой счёт — переключатель недоступен и подписан причиной; 501 при балансе 500 — сообщение, а не оплата «в минус»; отмена после оплаты — вернулись те же 500; два нажатия «Подтвердить» — списание одно. Наугад их не придумывают: значения подбирают техниками тест-дизайна, цепочку живого покупателя — сценарием.
Всё это дорого — пятнадцать минут на запись при двух минутах прогона, — поэтому на знакомой функции вместо кейса берут чек-лист: что проверить, без шагов и подробных ожиданий (где граница). Подробный кейс остаётся там, где ошибка дорога или важно точное повторение; лежит он в системе управления тестами, а упав — становится почти готовым баг-репортом.
Коротко
- Ядро кейса — название, предусловия, шаги, ожидаемый результат; идентификатор, данные, приоритет и требование добавляют, когда кейсов много.
- Шаг пишут для человека, которого нет рядом: одно действие, элементы названы как на экране, данные прямо в шаге; «проверить, что всё работает» шагом не является.
- Ожидаемый результат берут из требования, а не из поведения продукта, и он обязан быть проверяемым: «к оплате 2900 ₽» сравнить можно, «оплата прошла корректно» — нельзя.
- Одна проверка — один кейс, и кейс не опирается на соседние; на функцию нужен позитивный и несколько негативных: лимит, пустой баланс, отмена, повторное нажатие.
- Чек-лист дешевле и годится на знакомой функции; подробный кейс — там, где дорого ошибиться или где проверку автоматизируют.
Что почитать дальше
- Качество тест-кейса: балансы, показательность и типичные ошибки — почему правильно оформленный кейс всё ещё может ничего не находить.
- Чек-листы и тестовые данные — когда подробный кейс не нужен и откуда брать значения для проверок.
- Тестирование по требованиям — источник ожидаемого результата: критерии приёмки и вопросы к аналитику.
- Техники тест-дизайна: классы эквивалентности и граничные значения — как понять, какие кейсы писать, а какие не имеют смысла.