Релиз был идеальным. Пока продакшн не рухнул
Ночью сайт лёг. Заказы сыпались в никуда. Паника росла. Никто не понимал, что происходит, — пока не подключились тестировщики. Рассказываю реальную историю расследования, где баги были почти невидимы, но последствия могли стоить сотен тысяч.
Всё началось с падения
Это была самая обычная ночь: релиз прошёл, метрики стабильны, команда выдохнула. Но через пару часов после обновления на продакшене начали сыпаться ошибки 500. Клиенты жаловались, заказы не оформлялись, служба поддержки закипела.
«Пользователи не могут оформить заказы!» «Корзина не работает!»«Авторизация выбрасывает пользователей на стартовую страницу!»
Поначалу подозревали банальное: сервера, сеть, атака. Но в логах пусто. Проблема не лежала на поверхности.
Экспертиза подъехала, подключаем тестировщиков
Когда простые версии не сработали, в дело вошли тестировщики. Первоочередная задача: восстановить цепочку событий.
Что изменилось после релиза? Какие функции трогались? Есть ли зависимость от действий пользователей?
Методично, шаг за шагом, мы начали искать "невидимые" изменения.
След багов, который плохо видно без опыта
Выяснилось, что в одной из новых фич изменили работу авторизации. На тестовом стенде это прошло незаметно — база была "чистой". На продакшене же оказалось, что часть старых пользователей имели нетипичные состояния данных.
И именно это "несовпадение" вызывало фатальные сбои. Именно это убивало корзины заказов.
Без глубокого тестирования на реальных данных баг не всплыл бы.
Разбор после спасения
Восстановили правильную работу сайта через hotfix. Потом провели глубокий ретест всех сценариев с реальными прод-данными.
Параллельно сделали выводы:
- Критические модули нужно тестировать не только на тестовой базе, но и на копии прод-данных.
- Изменения в архитектуре требуют отдельного сценарного тестирования.
- Автотесты по ключевым потокам должны запускаться сразу на тестовой копии продакшена.
Зачем же, получается, вообще нужно тестирование?
Потому что это способ управлять реальностью, где код постоянно взаимодействует с живыми пользователями и миллионами нестандартных кейсов.
Баги невозможно устранить все и навсегда — но можно вовремя поймать.
Тестирование нужно, чтобы:
- выявлять слабые места раньше клиентов,
- снижать риски критических провалов,
- строить доверие к продукту на реальных данных, а не на красивых отчётах.
Когда оно — не формальность, а привычка мыслить как пользователь, проекты становятся устойчивыми.
А без тестирования баги превращаются в реальные убытки, продукт ломается в руках пользователей и репутация компании тает на глазах.