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

Правку в оформление заказа отдали в проверку в четверг вечером. Расписывать её подробными тест-кейсами смысла нет: проверка займёт полчаса, описание — полтора, а через две недели форма снова изменится. Вы пишете список того, что надо обойти: «корзина», «промокод», «оплата».

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

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

требование скидка 10%, один раз на покупателя строки чек-листа данные под строку код SAVE10 → к оплате 1800 ₽ тот же код второй раз → отказ код с опечаткой → поле краснеет покупатель без заказов тот же покупатель SAVE1O — опечатка на следующий день, тот же список:код SAVE10 → к оплате 1800 ₽код уже использованстрока красная, продукт не менялся

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

Строка чек-листа — это проверка, а не тема

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

Так не надоТак надо
корзинапустая корзина: кнопка «Оплатить» неактивна
промокодистёкший код: сумма не изменилась, под полем видна причина
регистрациязанятая почта: «Такой аккаунт уже есть», данные в форме целы

Годная строка закрывается ответом «да» или «нет»; на «корзину» отвечают «ну, посмотрел».

  • Одна строка — одна проверка. «Промокоды и бонусы» дают отметку, из которой не понять, что сломалось.
  • Правило, а не путь к кнопке. Правило переживает переделку интерфейса, расписанные шаги — нет.
  • Данные — там, где меняют исход. «600 ₽ и 500 бонусов» против «3400 ₽ и 500 бонусов»: в первой строке включается ограничение в половину суммы.
  • Негативные строки обязательны. Пусто, чужое, дважды, просрочено, длинное: удачный путь разработчик проходит сам.

Как чек-лист вырастает из требования

Список из головы повторяет то, что вы и так помните. Случай, который никто не обсуждал, туда не попадёт — поэтому список растят из требования: задачи, критериев приёмки, макета, ответа аналитика. Возьмём короткое: скидка 10% на заказ от 1000 ₽, один код на покупателя, коды до 31 августа включительно, с бонусами не складывается.

Вопросов к нему четыре. Что должно работать? Заказ на 2000 ₽ с кодом даёт 1800 ₽. Где границы? У каждого числа и даты есть край, ошибки живут там: 1000 и 999 ₽, 31 августа и 1 сентября (техники тест-дизайна). Что запрещено? Каждое ограничение — минимум одна строка. Что происходит вокруг? Заказ отменили — код вернулся или сгорел?

  • [ ] заказ 2000 ₽ с кодом → к оплате 1800 ₽, скидка видна в заказе
  • [ ] заказ ровно 1000 ₽ → скидка есть; 999 ₽ → скидки нет и написана причина
  • [ ] код 31 августа → работает; 1 сентября → отказ с понятным текстом
  • [ ] тот же код вторым заказом того же покупателя → отказ
  • [ ] код вместе с бонусами → либо бонусы недоступны, либо код не применяется
  • [ ] отмена оплаченного заказа → код вернулся покупателю (уточнить у продукта)

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

Длина меряется временем: прогон должен помещаться в один подход, тридцать-шестьдесят минут — это пять-пятнадцать строк на правку, двадцать-сорок на функцию, шестьдесят-восемьдесят на регресс раздела. Что не проходится за раз, не будет пройдено никогда. Поэтому убирают строки, зелёные два года подряд (кандидаты в автотесты), дубли («скидка применяется» и «сумма уменьшилась на 10%») и заклинания вроде «проверить общее качество интерфейса».

Данные: набор персонажей, а не один «пользователь»

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

  • без единого заказа — пустые экраны самое урожайное место: «У вас пока нет заказов» вместо пустой таблицы, статистика без деления на ноль;
  • с заказами во всех статусах — оплачен, ожидает оплаты, в доставке, отменён, возвращён;
  • с нулевым балансом бонусов — переключатель списания недоступен и подписан причиной;
  • с неудобными данными — длинная фамилия, апостроф (O'Brien), не-латиница, адрес на двести символов.

Плюс заблокированный и удалённый (вход закрыт, старые ссылки не открывают чужие данные), по учётной записи на роль и неудобные объекты: товар с одной штукой на складе, пустой файл, файл на сто мегабайт. Про каждого персонажа держат строку-описание: через месяц никто не вспомнит, почему у покупателя test-07 нельзя менять адрес.

Руками через интерфейс заводить нормально, пока персонажей пять. Запросом строка появляется мгновенно, но мимо правил продукта: INSERT создаёт заказ, которого не бывает, — оплаченный, но без платежа, и полдня уйдёт на «баг», которого нет. Правило: создавать данные теми же путями, что и продукт, через его API, а запросом подкручивать созданное — сдвинуть дату, обнулить баланс, снять флаг (SQL для тестировщика, API-тестирование).

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

Красная строка без бага: данные протухли или стенд не тот

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

  • Состояние создают в начале проверки: нужен заказ «Ожидает оплаты» — оформите его сейчас, а не ищите вчерашний.
  • Уникальность генерируют: почта qa+2026-09-13-01@example.com приходит в тот же ящик (всё после + отбрасывается при доставке) и занятой не будет никогда.
  • Данные держат пачкой: не один промокод, а двадцать; не один заказ в статусе, а пять.
  • В строке пишут признак, а не номер: «заказ в статусе „Ожидает оплаты“ отменяется» переживёт пересборку стенда, «заказ № 1024» умрёт вместе с ним.

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

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

Где это применяется

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

Где спотыкаются начинающие:

  • Пишут темы вместо проверок. Каждый исполнитель проходит свой список, сравнить два прогона невозможно.
  • Живут на одном персонаже. После первой же проверки он заблокирован, код потрачен, бонусы списаны.
  • Завязывают строки на номера заказов и покупателей — список умирает через месяц вместе с ними.
  • Заводят баг, не проверив данные и стенд — и тратят чужое время на «не воспроизводится».

Коротко

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

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