Театр багов на одной карточке: разыгрываем сбойные сценарии до того, как лезть в код

Большинство команд относится к багам как к досадным помехам. Но баги — это ещё и невероятно плотные источники информации, если их правильно зафиксировать.

Проблема в том, что обычно мы этого не делаем.

Мы заводим размытые задачи. Сразу прыгаем в код. Считаем, что из отчёта о баге и так «всё понятно». А потом тратим часы на воспроизведение проблем, которые можно было сделать кристально ясными за пять минут.

Здесь и появляется «Театр багов на одной карточке».

Вместо того чтобы сразу открывать отладчик, вы сначала разыгрываете баг как маленькую сценку. Вы пишете человекочитаемый сценарий, который описывает:

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

И всё это должно быть достаточно кратко, чтобы уместиться на одной карточке.

Разберём, как применять это на практике.

1. Начните с цели в одном предложении

Прежде чем описывать шаги, запишите одно предложение, которое делает цель сценария совершенно однозначной.

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

Хорошая цель в одном предложении:

• называет конкретное поведение, которое вас интересует
• описывает, что вы хотите проверить, а не как
• достаточно узкая, чтобы на неё можно было ответить «Да» или «Нет»: тест пройден или нет

Плохие примеры целей:

• «Починить баг в оформлении заказа» — слишком расплывчато
• «Способ оплаты ломается при смене адреса» — всё ещё неоднозначно
• «Разобраться с жалобой пользователя #1243» — описывает работу, а не поведение

Хорошие примеры целей:

• «При изменении адреса доставки сохраняется ранее выбранный способ оплаты по умолчанию».
• «Гости не могут получить доступ к страницам истории заказов без аутентификации».

Эта фраза-цель — заголовок вашей «карточки». Всё остальное подчинено этому одному поведению.

2. Разыграйте баг: сценарий как маленькая пьеса

Теперь превратите баг в пьесу с понятными ролями и шагами. На время забудьте о коде. Опишите, что будет видеть и делать человек.

Структура такая:

1. Начальное состояние
2. Шаги (действия пользователя)
3. Ожидаемый результат
4. Фактический результат

Пример сценария

Цель: «При изменении адреса доставки сохраняется ранее выбранный способ оплаты по умолчанию».

Начальное состояние

• Учетная запись пользователя: существует alice@example.com
• Сохранённые адреса доставки: «Дом» и «Офис»
• Сохранённые способы оплаты: Visa (по умолчанию), Mastercard
• Пользователь авторизован и находится на странице Оформления заказа (Checkout) с корзиной, содержащей 1 товар

Шаги (действия пользователя)

1. На странице Оформления заказа, в блоке Адрес доставки, нажать Изменить.
2. Выбрать адрес доставки «Офис».
3. Нажать Сохранить.
4. Не менять ничего в блоке Способ оплаты.
5. Нажать Оформить заказ (Place Order).

Ожидаемый результат

• Заказ оформляется с использованием Visa (по умолчанию).
• На странице подтверждения указано: Способ оплаты: Visa **** 1234.

Фактический результат

• Заказ оформляется с использованием Mastercard.
• На странице подтверждения указано: Способ оплаты: Mastercard **** 5678.

Это сценарий, который можно разыграть перед другим человеком, а не просто заметка для будущего себя, отлаживающего код. Если два человека независимо следуют этому сценарию, они должны увидеть один и тот же сбой.

3. Относитесь к каждому багу как к истории на одной карточке

Ограничение «одна карточка» мощно само по себе: одна карточка, одно поведение, один сценарий бага.

Зачем это ограничение?

• Оно заставляет сфокусироваться: вы проверяете что‑то одно, а не десяток вещей сразу.
• Становится легко делиться: вы можете передать карточку (или скриншот) коллеге — и он всё поймёт.
• Урезает расползание задачи: нашли другое поведение — это новая карточка.

Можно использовать реальные бумажные карточки, стикеры или небольшие цифровые карточки в трекере задач. Важно не средство, а ограничение по размеру.

Типичная структура одной карточки:

• Заголовок: «Способ оплаты меняется при обновлении адреса доставки»
• Цель: одно предложение
• Начальное состояние: 3–7 пунктов
• Шаги: 3–10 нумерованных шагов
• Ожидаемый vs. фактический результат: всего 2–4 пункта
• Путь восстановления: 1–3 пункта (об этом позже)

Если это не умещается комфортно на одну карточку или один экран, значит, у вас:

• несколько разных поведений
• чрезмерное количество развилок
• или недостаточно ясности, чтобы уверенно тестировать

Во всех этих случаях разбивайте на более мелкие, чёткие сценарии.

4. Сделайте воспроизводимость центральной целью

Сценарий считается «готовым» не тогда, когда он просто записан. Он готов, когда:

Любой участник команды может следовать вашим шагам и стабильно получать тот же сбой.

Проверьте сценарий на ком‑то из команды:

• Дайте ему карточку и тестовый стенд.
• Попросите выполнить шаги без дополнительных вопросов к вам.
• Если сбой воспроизвести не удалось, сценарий ещё не готов.

Типичные признаки того, что сценарий пока не воспроизводим:

• Он зависит от скрытых предположений (например, конкретные расширения браузера, feature flag’и, время суток, специфичные данные, которых нет в стенде).
• Пропущены важные шаги подготовки (например, «у пользователя есть 3 прошлых заказа», но нигде не сказано, как они появляются).
• Используется размытый язык («пощёлкать вокруг», «сделать обычное оформление заказа»).

Относитесь к воспроизводимости как к бинарной величине:

• ✅ «Кто угодно из команды может запустить сценарий и поймать баг по запросу».
• ❌ «Иногда случается» или «сейчас не получается, но точно было раньше».

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

5. Используйте «когнитивный дебаг» для расплывчатых сценариев

Когда отчёт о баге размытый («приложение тормозит» или «иногда само выкидывает из аккаунта»), относитесь к уточнению этого отчёта как к когнитивному дебагу:

Вы сначала отлаживаете своё понимание, а уже потом — код.

Вот три полезные тактики:

5.1 Переформулируйте проблему

Спросите себя: «Что именно здесь неожиданно или неправильно?»

Вместо:

• «Оформление заказа сломано».

Сформулируйте так:

• «После того как я обновляю адрес доставки, способ оплаты меняется без явного действия пользователя».

Переформулирование переводит вас от эмоционального описания к наблюдаемому поведению.

5.2 Добавьте ограничения

Сделайте сценарий уже и конкретнее:

• Выберите один браузер, один стенд (environment), один тип пользователя.
• Зафиксируйте данные: конкретный пользователь, конкретный товар, конкретная конфигурация.

«Баг проявляется при входе под alice@example.com в Chrome 120, на staging‑стенде, при наличии ровно одного товара в корзине».

Эти ограничения — инструмент дебага: они сокращают пространство возможных причин.

5.3 Вынесите мысли наружу

Не держите сценарий в голове. Запишите его, набросайте схему или проговорите вслух.

• Нарисуйте последовательность экранов.
• Выпишите предположения: «Телефон в онлайне», «Feature flag X включен».
• Проговорите сценарий коллеге и дайте ему возможность «потыкать в дыры».

Когда вы выносите своё размышление наружу, расплывчатая ментальная модель превращается во что‑то проверяемое — и исправляемое.

6. Фиксируйте крайние случаи как переиспользуемые сценарии

Некоторые баги стоит сохранить как постоянных «персонажей» вашего театра.

Обычно это:

• неприятные крайние случаи
• критические регрессии
• тонкие взаимодействия между фичами

Превратите их в переиспользуемые сценарии, которые можно запускать каждый раз, когда вы трогаете соседний код.

Примеры:

• «Оформление заказа с просроченной картой и обновление карты посреди процесса»
• «Сессия истекает, пока пользователь редактирует черновик»
• «Пользователь теряет подключение к сети во время загрузки файла»

Для каждого сохраняйте формат одной карточки и держите их в доступном месте:

• общий тестовый плейбук
• документ с регрессионными сценариями
• папка «Bug Scripts» (сценарии багов) в трекере задач

Когда выходит новая фича или изменение, пробегитесь по библиотеке:

«Мы трогали checkout + сессии. Перезапустим все баг‑сценарии по оформлению заказа и сессиям».

Так вы превращаете прошлую боль в будущую защиту.

7. Всегда добавляйте путь восстановления

Каждый сценарий на одной карточке должен заканчиваться путём восстановления:

«Как должна вести себя система после того, как баг будет исправлен?»

Это больше, чем просто «ожидаемый vs. фактический результат». Это определение того, что именно считается успешным прохождением сценария для вашего будущего «я».

Продолжим наш пример:

Путь восстановления (после фикса)

• После изменения адреса доставки выбранный способ оплаты остаётся неизменным.
• Если пользователь явно меняет способ оплаты, этот новый выбор сохраняется и используется для заказа.
• Добавить регрессионный тест: автоматизированный или ручной сценарий на основе этой же карточки.

Зачем нужен путь восстановления:

• Сценарий бага тут же превращается в готовый регрессионный тест.
• QA и разработчики разделяют общее понимание того, что значит «починено».
• Проще превратить сценарий в автоматизированный тест‑кейс позже.

Смотрите на это так: сегодняшний «театр багов» — завтрашний тестовый набор.

Собираем всё вместе

Когда «Театр багов на одной карточке» становится привычкой, ваш рабочий процесс меняется:

1. Баг поступает в работу.
2. Вы сдерживаете порыв сразу лезть в код.
3. Формулируете цель в одном предложении.
4. Пишете небольшой, человекочитаемый сценарий: начальное состояние, шаги, ожидаемый vs. фактический результат.
5. Доводите его с помощью когнитивного дебага до состояния, когда любой может воспроизвести баг.
6. Оформляете его как историю на одной карточке — маленькую, сфокусированную и удобную для передачи.
7. Определяете путь восстановления, чтобы сценарий стал будущим регрессионным тестом.

Что вы получаете взамен:

• Меньше времени, потраченного на погоню за размытыми отчётами
• Более быстрые и сфокусированные сессии дебага
• Растущую библиотеку переиспользуемых сценариев багов
• Более гладкий путь от «странного сбоя» до «надёжного тест‑кейса»

Баги никуда не денутся. Но если каждый превращать в маленькую, хорошо разыгранную сценку, каждый сбой становится переиспользуемым активом для всей команды.

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

Возьмите карточку.

И начинайте представление.