Smoke‑тесты после релиза, которые основатели могут провести за 10 минут

Что такое smoke-тест (и почему он важен после деплоя)

Smoke‑тест — это быстрый прогон сразу после релиза, который отвечает на один вопрос: работает ли продукт по ключевым сценариям? Речь не о поиске каждой ошибки. Это короткий тест «пройден/не пройден», который первым ловит сбои, с которыми сталкиваются реальные пользователи.

Думайте о нём как о минимальном наборе действий, которые совершил бы клиент: вход в систему, выполнение основной операции (создание или обновление чего-то), получение важного письма и, если вы берёте плату — успешная оплата. Если что‑то из этого ломается, вы хотите узнать об этом за минуты, а не после того, как накопятся обращения в поддержку.

Smoke‑тесты не заменяют полноценную QA. Они не отменяют автоматические тесты, глубокое проверочное тестирование крайних случаев, аудит доступности или проверку безопасности. И они не должны занимать час. Если ваш чеклист по релизу требует таблицы и собрания — его пропустят. Главное — скорость и повторяемость.

Многие ошибки проявляются только в продакшене, потому что он ведёт себя иначе, чем ваш ноутбук. Причины обычно прозаичны, но жестоки: неправильные переменные окружения (ключи API, настройки почты, вебхуки платежей), просроченные секреты, отличия в правах доступа, миграции, которые прошли, но не совпадают с ожиданиями кода, или поведение кэша/CDN, меняющее маршруты, куки или заголовки.

Это особенно полезно для основателей, которые быстро релизят с небольшими командами, и для всех, кто опирается на код, сгенерированный ИИ, и быстрые прототипы. Когда вы движетесь быстро, простой и последовательный smoke‑тест может стать разницей между спокойным запуском и пожарной тревогой.

Перед началом: 2 минуты подготовки

10‑минутный smoke‑тест лучше проводить без импровизаций. Потратьте две минуты на подготовку небольшой «тестовой коробки», чтобы результаты были понятными и воспроизводимыми.

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

Дальше подтвердите, где вы тестируете. Запишите окружение (production, staging или preview) и точный URL. Многие «баги» — просто тестирование не там или путаница между версиями.

Наконец, убедитесь, что вы можете проверить две вещи, которых не всегда видно в UI: почту и платежи. Откройте тестовый почтовый ящик для пользователя (проверьте папку спам/промо). Если ваш сервис принимает оплаты, подтвердите режим (test vs live) и доступ к месту, где вы проверяете успешную оплату.

Держите простую заметку и записывайте результаты по ходу. Не полагайтесь на память.

Держите готовыми:

• Учетные данные тестового пользователя и админа
• Название окружения и URL, где вы тестируете
• Доступ к тестовому почтовому ящику (и возможность поиска писем)
• Где вы проверяете результат оплаты (если применимо)

Если что‑то пойдёт не так, эти записи (и скриншот при необходимости) сэкономят часы переписки.

10‑минутный прогон: простой пошаговый сценарий

Запустите таймер на 10 минут и проходите один и тот же маршрут каждый раз. Цель — не доказать, что всё идеально. Цель — поймать ошибки, которые сразу мешают пользователям после деплоя.

Используйте приватное окно браузера, чтобы не получить ложный «пропуск» из‑за закэшированных сессий.

Фиксированный порядок (не импровизируйте)

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

1. Откройте приложение так, как это сделал бы новый пользователь (лендинг → приложение).
2. Войдите (или зарегистрируйтесь) и подтвердите, что попали на ожидаемый первый экран.
3. Выполните основное действие продукта (создать, обновить и просмотреть объект).
4. Вызовите одно уведомление, на которое полагаются пользователи (email или внутриигровое уведомление).
5. Если вы берёте оплату, прогоните небольшой платёж в тестовом режиме end‑to‑end.

Что делать, если что‑то ломается

Воспринимайте первую серьёзную ошибку как стоп‑знак. Не продолжайте кликать «чтобы собрать больше информации» — вы смешаете симптомы и зря потратите время.

Напишите короткую запись о баге, которая позволит легко воспроизвести: что вы нажали, что ожидали, что произошло и любые сообщения об ошибке. Скриншот полезен, но важнее точные шаги.

После исправления сначала ретестируйте сломанный участок теми же шагами. Если он проходит — продолжайте по порядку. Случайные повторные проверки создают путаницу и скрывают корневые причины.

Go/no‑go за одну минуту

До деплоя решите, какие вещи обязательно должны пройти. Держите список коротким: вход работает, основной create/edit/view поток работает, ключевые письма приходят, платежи проходят (если применимо). Если любой обязательный пункт падает — это no‑go, даже если остальные проверки в порядке.

Проверки входа и аутентификации

Большинство smoke‑тестов стоит начинать с авторизации: одно маленькое изменение может выколоть всех из системы. Используйте приватное окно (или другой браузер), чтобы не использовать случайно закэшированную сессию.

5 проверок, которые ловят большинство сбоев в авторизации

Пройдите их быстро, в заданном порядке, и остановитесь, как только что‑то пойдёт не так:

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

Держите план простым. Вы проверяете, что приложение умеет создавать сессию, хранить её и защищать приватные страницы.

Обычная реальная ошибка: после деплоя куки устанавливаются для неправильного домена или помечаются как "secure" так, что это ломает работу в вашем окружении. Симптом: «вход вроде работает», но после обновления выкидывает.

Если приложение поддерживает вход через Google/GitHub — прогоните и его один раз, но не заменяйте им проверку email/пароль. Социальная авторизация может пройти, несмотря на сломанное собственное управление сессиями.

Когда любой шаг падает — зафиксируйте точный экран и сообщение.

Основные CRUD‑потоки менее чем за 3 минуты

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

Выберите один «основной объект» продукта (проект, задачу, клиента, счёт, объявление). Используйте тестовый аккаунт и прогоняйте один и тот же цикл каждый раз.

3‑минутный CRUD‑цикл

Двигайтесь быстро и просто:

• Создайте новую запись с коротким уникальным именем, например "Smoke 2026-01-16 10:05." Подтвердите сохранение и что вы попали туда, где ожидали.
• Найдите её в списке (или на дашборде). Если поиск или фильтры важны — один раз их используйте.
• Отредактируйте одно очевидное поле (переименуйте). Проверьте два места, где это значение должно отображаться (детальная страница + список).
• Удалите запись. Подтвердите, что после обновления страницы она действительно исчезла, а не просто скрыта.
• Разово попробуйте «плохой ввод»: оставьте обязательное поле пустым, вставьте очень длинный текст или спецсимволы. Ожидайте понятные, человеческие сообщения об ошибке.

Если что‑то ломается — запишите, что вы делали и что увидели. «Нажал Сохранить -> крутилка бесконечно» гораздо полезнее, чем «CRUD сломался».

Как выглядит «хорошая» ошибка

Хорошее приложение блокирует некорректный ввод коротким сообщением типа «Имя обязательно». Плохое приложение показывает пустую страницу, сырой текст ошибки или тихо отбрасывает изменения.

Если вы переименовали запись, детальная страница обновилась, а в списке после обновления по‑прежнему старое имя — это часто указание на кэширование, неудачное фоновое обновление или частичный деплой.

Проверки почты и уведомлений

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

Вызовите одно реальное транзакционное письмо из продукта (не из админского инструмента). Хорошие варианты: сброс пароля, приглашение или квитанция.

Сфокусируйтесь:

• Подтвердите, что письмо приходит в течение пары минут.
• Убедитесь, что отправитель/from выглядит правильно (не заглушка).
• Проскрольте шаблон на наличие явных проблем (например, видимый {{name}}).
• Нажмите основную кнопку и проверьте, что она ведёт на нужную страницу и действие работает.

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

Если вы используете письма‑приглашения, пройдите полный путь: отправьте приглашение, откройте его в другом браузере (или приватном окне), примите приглашение и убедитесь, что попали в правильную рабочую область/аккаунт.

Пример: вы тестируете сброс пароля — письмо приходит, но кнопка открывает страницу с "token invalid". Это часто указывает на несоответствие URL приложения, домена куки или секретных ключей между окружениями.

Проверки платежей и биллинга

Платежи после деплоя ломаются предсказуемо: оформление заказа перестаёт работать, success‑callback не доходит до вашего приложения, или пользователь оплатил, но всё ещё выглядит как неоплаченный. Быстрая проверка платежа — один из самых ценных прогонов.

Успешная тестовая оплата

Выберите самый дешёвый план (или товар за $1) и пройдите покупку от страницы цен до чек‑плика и квитанции.

• Начните оформление и подтвердите сумму, валюту и название плана.
• Завершите оплату и убедитесь, что попали на понятную страницу успеха.
• Обновите приложение и проверьте, что состояние пользователя изменилось (активный план, доступ открыт, добавлены кредиты и т. д.).
• Откройте страницу аккаунта или биллинга и проверьте, что статус соответствует покупке.

Если вы используете вебхук, именно здесь проявляются проблемы. Частая ошибка: оплата прошла, но доступ не обновился из‑за смены webhook‑секрета, endpoint'а или переменной окружения.

Пути неуспеха, отмены и рефандов

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

• Отмените или провалите оплату и подтвердите, что приложение объясняет, что произошло и что делать дальше.
• Убедитесь, что пользователь не помечен как оплаченный (нет доступа, не добавлены кредиты).
• Если ваш продукт поддерживает возвраты или отмену подписки, проверьте этот путь один раз и подтвердите обновление статуса после обновления страницы.

Наконец, проверьте, что интерфейс и письма не показывают полные номера карт, CVV, API‑ключи или сырые дампы ошибок. Хорошее правило: если вы не стали бы вставлять это в чат поддержки, не показывайте это клиенту.

Быстрый чеклист (скопируйте и используйте снова)

Скопируйте это в релиз‑ноты, чтобы прогонять одни и те же проверки каждый раз. Держите последовательность. Цель — ловить привычные "вчера работало" ошибки сразу после деплоя.

Release: __________ Date/time: __________ Environment: __________

What changed in this release (1-2 lines):

If anything fails, write the smallest detail that helps debug: the exact step, the user email used, and the error text.

Go/No-Go: ________ Owner: ________ If No-Go, rollback? ________ Follow-up ticket(s): ________

Распространённые ошибки, из‑за которых smoke‑тесты пропускают реальные баги

Главная ловушка — тестировать приложение, каким вы хотели бы его видеть, а не тем, что получают пользователи. Smoke‑тест должен слегка раздражать: свежая сессия браузера, реальный домен, реальные данные и те же права, что у обычного пользователя.

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

Другой промах — тестирование не того окружения. Если вы кликаете в preview, а клиенты пользуются production, вы можете пропустить именно те вещи, которые ломаются после деплоя: неправильные переменные окружения, несоответствующие миграции или неправильно настроенный callback URL.

Почта особенно коварна. Она часто работает локально с dev‑ящиком, а в продакшене падает из‑за отсутствующего ключа провайдера, неподтверждённого домена отправителя или попадания писем в спам. Относитесь к каждому деплою так, будто почта может быть сломана, пока вы не увидите реальное письмо.

Аутентификация — ещё одно частое место поломок. Даже если вы проверили "вход работает", можно выпустить релиз со сломанным выходом, сбросом пароля или истечением сессии.

Несколько привычек, которые помогут ловить реальные ошибки:

• Тестируйте как совершенно новый пользователь, так и обычный существующий (не только как админ).
• Тестируйте в реальном задеплоенном окружении, не только локально или в preview.
• Подтверждайте, что реально приходит письмо (и что ссылка в нём работает).
• Включайте выход и сброс пароля в каждый прогон.
• Если что‑то ломается, измените только одну вещь, прогоните снова и запишите, что изменилось.

Не игнорируйте "всё сегодня просто медленно". Пользователи сталкиваются с таймаутами, двойными кликами и обновлением страницы в процессе загрузки. Если страница нестабильна во время вашего 10‑минутного прогона, это часто первый реальный production‑баг.

Пример: как поймать пост‑деплой проблему за минуты

Майя управляет небольшим SaaS. В пятницу она деплоит изменение, которое «только касается UI». Перед анонсом она прогоняет smoke‑тест в приватном окне.

Всё выглядит нормально, пока она не попробует сброс пароля. Форма принимает email и показывает сообщение об успешной отправке, но письмо не приходит.

Вместо догадок она быстро сужает круг. Создаёт новый тестовый аккаунт, чтобы вызвать welcome‑письмо — оно приходит. Потом пробует смену email (если приложение шлёт подтверждение) — тоже приходит. Значит, не "вся почта сломана", а только путь сброса пароля.

Это указывает на типичную пост‑деплой проблему: один шаблон, один endpoint или одна задача в фоне падает, пока остальная система выглядит здоровой. В случае Майи оказалось, что ID шаблона сброса пароля сменили, а переменная окружения в production всё ещё указывала на старый ID.

Дальше простое решение:

• Если пользователи не могут входить — сначала откат, потом правка.
• Если сломан только сброс пароля и фикc безопасен — выкатить хотфикс.
• В любом случае опубликовать короткое статус‑сообщение, чтобы поддержка не удивлялась.

Она выбрала хотфикс: обновила ID шаблона, снова задепоила и проверила сброс. Письмо пришло за минуту.

И в конце она дополнила чеклист: «вызвать сброс пароля и подтвердить получение письма» плюс «проверить конкретный шаблон/воркер, а не только общую отправку почты».

Что делать дальше, когда тест падает (и как FixMyMess может помочь)

Когда smoke‑тест падает, воспринимайте это как стоп‑знак, а не как препятствие. Если та же ошибка повторяется дважды, блокирует регистрацию или платежи, или выглядит как проблема безопасности (утекшие данные, странный админ‑доступ, скомпрометированные ключи) — останавливайте релиз и откатывайтесь, если можете.

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

Соберите минимальный пакет информации перед обращением к разработчику. Это экономит часы и ускоряет исправление:

• Точные шаги, которые вы сделали (1, 2, 3), начиная с чистой вкладки браузера
• Что ожидали vs что произошло (включите текст ошибки)
• Скриншот или короткая запись экрана
• Временная метка и часовой пояс
• Детали окружения (production vs staging, браузер, email аккаунта)

Затем превратите чеклист в привычку. Прогоняйте его сразу после деплоя и снова после любого хотфикса. Если вы ведёте трекер задач — метьте тикеты одинаково (login, CRUD, email, payments), чтобы проявлялись закономерности.

Если ваш код был сгенерирован инструментами типа Lovable, Bolt, v0, Cursor или Replit, пост‑деплой проблемы часто сигнализируют о глубинных проблемах: сломанная авторизация, раскрытые секреты, запутанная архитектура или небезопасные запросы к БД. В таких случаях залатать одну ошибку иногда недостаточно.

Если вы унаследовали кодовую базу, созданную ИИ, которая постоянно ломается после деплоя, FixMyMess (fixmymess.ai) может провести бесплатный аудит кода и затем устранить корневые причины — от починки авторизации и логики до усиления безопасности и подготовки к деплою.