Почему «починим завтра» иногда уже поздно
В большинстве систем часть ошибок действительно можно исправить после запуска. Небольшой визуальный дефект, некорректный отступ или второстепенная функция могут спокойно дождаться следующего релиза.
Но есть сценарии с коротким окном, в котором ошибка особенно чувствительна для бизнеса. Интернет-магазин запускает продажи новой коллекции. Сервис открывает запись на ограниченное число мест. Компания переводит клиентов на новый личный кабинет. Организатор публикует программу большого мероприятия и открывает регистрацию.
Во всех этих случаях важна не сама календарная дата, а то, что в определённый момент большое число пользователей должно выполнить конкретное действие. Если этот путь не работает именно тогда, исправление через день может уже не вернуть упущенную возможность.
У сайта мероприятия ситуация особенно наглядна. Посетитель должен успеть найти событие, проверить актуальное время и площадку, перейти к регистрации или покупке билета и завершить действие. Если регистрация заработала после окончания события, технически дефект устранён. Для пользователя и бизнеса — поздно.
При этом фиксированная дата не делает критичной каждую ошибку в системе. Приоритет определяется не количеством дефектов и даже не их технической сложностью, а тем, мешает ли конкретная проблема выполнить значимое для бизнеса действие.
Начинать проверку нужно не со списка функций
Перед запуском легко попасть в ловушку: пройтись по перечню функций и убедиться, что каждая из них работает.
Поиск работает. Форма открывается. Авторизация проходит. API отвечает. Платёжный сервис доступен.
В отчёте всё выглядит бодро. А пользователь всё равно не может закончить нужное действие.
Причина в том, что бизнес-задача редко совпадает с одной функцией. Она складывается в последовательность шагов. Поэтому сначала стоит ответить не на вопрос «какие функции у нас есть?», а на другой: что пользователь должен сделать в критический момент и какой результат получить?
Для событийного сайта такой сценарий может выглядеть так:
найти событие → получить актуальную информацию → перейти к регистрации или покупке билета → выполнить действие → получить подтверждение.
У другой веб-системы цепочка будет другой. Например, для личного кабинета — авторизоваться, получить данные, сформировать документ и скачать его. Для B2B-сервиса — найти нужную заявку, изменить статус и передать данные дальше.
Общее правило одно: критический сценарий заканчивается не нажатием кнопки, а бизнес-результатом, ради которого пользователь пришёл в систему.
Технически серьёзная ошибка не всегда самая опасная
Приоритизация дефектов перед запуском становится проще, если разделить два вопроса:
- Насколько серьёзна ошибка с технической точки зрения?
- Что она делает с критическим пользовательским сценарием?
Например, заметная визуальная проблема на второстепенной странице может выглядеть неприятно, но не мешать пользователю выполнить основную задачу. А почти незаметная ошибка в передаче идентификатора события во внешний сервис может привести к тому, что человек нажимает «Зарегистрироваться» и попадает не туда.
Сам дефект может занимать одну строку в баг-трекере, но критический сценарий на этом заканчивается. Поэтому перед датой запуска полезно смотреть не только на техническую критичность дефекта, но и на его место в пользовательском пути.
Если ошибка блокирует действие, без которого система не решает свою основную задачу в этот период, её бизнес-приоритет может быть выше, чем у технически более сложной проблемы.
Все компоненты работают. Почему тогда пользователь не дошёл до конца?
Один пользовательский сценарий может проходить сразу через несколько компонентов системы. И сбой часто возникает не внутри одного из них, а на стыке.
Страница может открываться. Форма — отправляться. Внешний сервис — отвечать. Но между этими точками остаются стыки, на которых и возникают неприятные сюрпризы.
Проверять стоит как минимум:
- переходы между страницами и компонентами;
- передачу данных между системами;
- работу внешних сервисов;
- сценарии ошибок и таймаутов;
- возврат пользователя после внешнего действия;
- подтверждение конечного результата.
Для команды сайт и сервис регистрации могут быть двумя независимыми системами. Для пользователя это один путь. Он не обязан разбираться, где заканчивается ваша система и начинается чужая.
Если после перехода потерялся контекст, открылась неверная форма или внешний сервис вернул пользователя на пустую страницу, сценарий не завершён — независимо от того, сколько отдельных компонентов успешно прошли функциональное тестирование.
В проектах DIGITAL SECTOR с большими событийными программами такие маршруты закладывались ещё на уровне структуры: пользователь мог прийти к событию через разные разделы, поиск и другие точки входа. Практический смысл здесь не в количестве способов навигации, а в том, чтобы человеку не приходилось угадывать единственный «правильный» путь.
Функционально работает. А что произойдёт, когда пользователей станет больше?
Функциональная проверка отвечает на вопрос: можно ли выполнить действие? Нагрузочная — на другой: останется ли это действие доступным, когда его одновременно начнут выполнять многие пользователи?
Можно убедиться, что поиск находит нужное событие, фильтры работают, карточка открывается и регистрация проходит. Но после крупного анонса всё меняется: множество пользователей одновременно ищут события, открывают карточки и переходят к регистрации.
При этом главная страница может продолжать открываться быстро и создавать приятное ощущение, что система справляется. А поиск, запрос к базе или регистрация уже начинают отвечать медленнее.
Поэтому нагрузочную проверку имеет смысл строить вокруг реального критического сценария, а не вокруг одной страницы.
Для сайта мероприятия это может быть путь:
открыть программу → найти событие → открыть карточку → перейти к регистрации → завершить действие.
Проверять нужно весь маршрут: где растёт время ответа, на каком этапе появляются ошибки, как ведёт себя внешняя зависимость и получает ли пользователь результат.
В другом проекте — уже не из событийной отрасли — DIGITAL SECTOR с помощью нагрузочного тестирования искал причины сбоев интернет-магазина при росте трафика, вносил изменения и повторно проверял систему. Подход подробно разобран в материале «Нагрузочное тестирование сайта: как DIGITAL SECTOR повысил устойчивость интернет-магазина в 10 раз». Результаты этого проекта нельзя механически переносить на другие системы, но сам принцип универсален: тестировать нужно те операции и последовательности действий, которые будут критичны в реальной работе.
Если ожидается очень короткий пик — например, одновременно открывается регистрация на ограниченное число мест, — для отдельной операции может потребоваться управление потоком пользователей. Один из вариантов — виртуальная очередь: система ограничивает число одновременных обращений к наиболее тяжёлому участку, не делая при этом недоступным весь сайт.
Это уже архитектурное решение, и нужно оно далеко не каждому проекту. Но обсуждать подобные ограничения лучше до запуска, а не после первого реального пика.
Доступная система с неправильными данными всё равно не решает задачу
Есть ещё одна категория ошибок, которую легко пропустить, если оценивать готовность только техническими метриками. Система доступна. Страницы открываются. Формы работают. Но пользователь получает устаревшие или противоречивые данные.
Для событийного проекта это особенно чувствительно: до самого запуска могут меняться время, площадка, статус события, условия участия, программа или ссылка на регистрацию.
Контентная ошибка — не то же самое, что технический сбой. Но для пользовательского сценария результат может оказаться одинаковым.
Человек пришёл по актуальной ссылке, быстро открыл страницу, увидел старое время и приехал после окончания события. С технической точки зрения система отработала без ошибки. Пользователь свою задачу не решил.
Поэтому для критичных данных нужно заранее определить:
- где находится их основной источник;
- где эти данные используются;
- как изменения попадают во все связанные разделы;
- кто может их редактировать и публиковать;
- как быстро обновление становится видно пользователю.
Если событие одновременно выводится в программе, поиске, подборках, на карте и в карточке, ручное исправление каждого места создаёт лишние точки ошибки.
В проектах DIGITAL SECTOR с большой событийной программой роли участников разделяли: одни готовили и редактировали информацию, другие проверяли её, третьи подтверждали публикацию. Так непроверенная правка не попадала на сайт напрямую.
Если используется кэширование, в сценарий проверки стоит добавить ещё один вопрос: действительно ли после публикации пользователь уже получает новую версию. Иначе в административной панели всё исправлено, а снаружи продолжает жить вчерашняя программа.
Как определить, что проверять в первую очередь
Перед критической датой бессмысленно пытаться сделать одинаково важным всё. Полезнее взять основные бизнес-задачи системы и для каждой задать пять вопросов.
1. Какое действие должен выполнить пользователь?
Не «открыть страницу регистрации», а зарегистрироваться и получить подтверждение; не «открыть корзину», а оформить заказ; не «зайти в личный кабинет», а получить или изменить нужные данные.
2. Есть ли у действия ограниченное окно?
Если сценарий можно спокойно завершить завтра, риск один. Если завтра регистрация уже закроется, стартуют продажи или закончится мероприятие — совсем другой.
У длинного проекта таких окон может быть несколько. Для крупного мероприятия сайт необязательно запускать сразу со всей будущей функциональностью: сначала может понадобиться анонсирующая версия, затем программа и регистрация, позже — карта, расписание и функции для посетителей на площадке.
В одном из событийных проектов DIGITAL SECTOR сайт запускался поэтапно: возможности добавлялись по мере того, как они становились нужны пользователю. Поэтому при подготовке к запуску полезно определять не одну абстрактную дату готовности сайта, а какие пользовательские сценарии должны без сбоев работать к каждой ключевой дате.
3. Где сценарий проходит через несколько компонентов?
Именно на стыках стоит ожидать проблемы, которые не видны при проверке функций по отдельности. Это могут быть переходы между клиентской и серверной частями, внешняя авторизация, платёжная система, регистрационный сервис, поиск, база данных или обмен между внутренними системами.
4. Что увидит пользователь при ошибке?
Критический сценарий стоит проверять не только по счастливому пути.
Что произойдёт при таймауте? Сохранятся ли введённые данные? Можно ли повторить операцию? Понятно ли сообщение об ошибке? Не создаст ли повторное нажатие дубль?
Ошибка сама по себе неприятна. Ошибка, после которой человек не понимает, что произошло и что делать дальше, обычно неприятнее.
5. Изменится ли сценарий под реальной нагрузкой?
Если операция особенно востребована именно в момент запуска, её нужно проверить в условиях, близких к ожидаемым. Здесь уже недостаточно ответа «у тестировщика всё прошло».
Приёмка тоже должна идти по сценариям
Приёмка часто превращается в сверку: выполнены ли требования, работают ли функции, закрыты ли замечания. Для системы, где несколько функций складываются в одно критическое действие, этого недостаточно.
Приёмочный сценарий должен начинаться с задачи пользователя и заканчиваться ожидаемым результатом.
Например:
Поиск — работает. Карточка — работает. Кнопка регистрации — работает.
И другой вариант:
Пользователь нашёл нужное событие, увидел актуальные условия, перешёл к регистрации, корректно заполнил данные, получил успешный ответ внешнего сервиса и подтверждение.
В первом случае мы проверили три компонента. Во втором — поняли, решает ли система задачу.
Этот же подход помогает договориться о критериях готовности ещё до разработки. Команда заранее знает, какие действия будут проверяться целиком и что именно считается успешным результатом.
Что проверить до даты, которую нельзя сдвинуть
Цель финальной проверки — не доказать, что в системе вообще нет дефектов. Для сложной веб-системы это и не самая полезная постановка задачи.
Нужно убедиться, что ошибки не блокируют сценарии, ради которых система должна работать именно в этот момент.
Перед запуском стоит:
1. Определить критические действия пользователя. Начать с бизнес-задач, а не с перечня функций.
2. Собрать полные пользовательские сценарии. От первого шага до результата.
3. Пройти их целиком. Включая переходы между компонентами и внешними сервисами.
4. Проверить ошибки и нестандартные состояния. Таймауты, неверные данные, повторные действия, временную недоступность зависимостей.
5. Проверить основные пользовательские условия. В том числе мобильные устройства, если с них проходит существенная часть сценария.
6. Проверить критические сценарии под ожидаемой нагрузкой. Не только доступность главной страницы или отдельных API.
7. Проверить актуальность данных. Особенно тех, от которых зависит решение пользователя и возможность завершить действие.
После этого формальная готовность системы означает уже не только зелёные статусы в отчёте, но и то, что пользователь способен выполнить нужное действие в критический момент.
