Halloween Special: Баг, который вернулся

Осень, конец спринта, ночь перед релизом. В офисе SaveLink уже никого нет кроме дежурной команды тестировщиков. Последние автотесты отстрелялись в Jenkins, статус зеленый, задачи закрыты, кофе закончился. Мы собираемся уходить. Но тут кто-то произносит роковую фразу:

— А давайте еще раз посмотрим логи. На всякий случай.

Глава 1. Оно затаилось в проде

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

«После обновления пользователи не могут оформить заказ. Ошибка 500».

Холодок пробегает по спине. Мы открываем тот самый лог. И понимаем, что предупреждение больше не предупреждение. Это начало критического сбоя.

Глава 2. Возвращение пропущенного

Мы пересматриваем тест-кейсы. Проверяем отчеты. Перезапускаем автотесты. Все чисто. Но ошибка не в коде. Она в данных.

Изменился формат ответа внешнего API. Казалось бы это незначительное отличие, один лишний символ. Но именно он превращает безобидный JSON в монстра, который рвет продакшн изнутри.

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

Глава 3. Охота начинается

Мы собираемся в экстренную QA-сессию. Мониторы светятся, мессенджер пульсирует тревожными уведомлениями. Кто-то перезапускает сборку, кто-то перепроверяет спецификацию.Снаружи ночь, дождь и ветер. Внутри адреналин и абсолютная концентрация.

В три часа ночи мы ловим источник проблемы. API-поставщик тихо изменил спецификацию без обновления документации. Ни один контрактный тест не сработал, потому что структура запроса формально осталась валидной.

Исправление занимает 20 минут. Анализ и ретест — еще час. К рассвету прод оживает.

Глава 4. Что мы вынесли из этой истории

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

• Контрактное тестирование для всех интеграций;
• Мониторинг внешних API с алертами при изменении схемы;
• Проверку спецификаций в рамках CI/CD;
• И главное это еженедельный «QA-разбор» в духе Code Review, где обсуждаем потенциальные риски и «почти пропущенные» дефекты.

Финал. Happy End?

Мы вернули стабильность, отчет снова зеленый. Но с тех пор, каждый раз, когда Jenkins запускает автотесты, в тишине офиса кто-то шепчет:

— Только не этот сценарий…

Потому что даже у тестировщиков есть свои страшилки. И если уж бояться, то лучше багов, а не продакшна.

Послесловие от команды SaveLink

Хорошие тестировщики не верят в мистику. Они верят в проверку гипотез, документацию и CI/CD. Но в ночь Хэллоуина даже мы признаем: идеальный релиз — это редкий миф, и наш лучший оберег против ужаса — качественное тестирование.