“Мы думали, что все закончилось. Но однажды ночью отчет о релизе открылся сам…”
Осень, конец спринта, ночь перед релизом. В офисе SaveLink уже никого нет кроме дежурной команды тестировщиков. Последние автотесты отстрелялись в Jenkins, статус зеленый, задачи закрыты, кофе закончился. Мы собираемся уходить. Но тут кто-то произносит роковую фразу:
Глава 1. Оно затаилось в проде
На первый взгляд все идеально. Приложение стабильно, метрики чистые. Но в одном из логов кто-то замечает незначительное предупреждение — мелочь, «ошибка форматирования». Никто не придает значения. Через пару дней после релиза приходит письмо от заказчика:
Холодок пробегает по спине. Мы открываем тот самый лог. И понимаем, что предупреждение больше не предупреждение. Это начало критического сбоя.
Глава 2. Возвращение пропущенного
Мы пересматриваем тест-кейсы. Проверяем отчеты. Перезапускаем автотесты. Все чисто. Но ошибка не в коде. Она в данных.
Изменился формат ответа внешнего API. Казалось бы это незначительное отличие, один лишний символ. Но именно он превращает безобидный JSON в монстра, который рвет продакшн изнутри.
Глава 3. Охота начинается
Мы собираемся в экстренную QA-сессию. Мониторы светятся, мессенджер пульсирует тревожными уведомлениями. Кто-то перезапускает сборку, кто-то перепроверяет спецификацию.Снаружи ночь, дождь и ветер. Внутри адреналин и абсолютная концентрация.
В три часа ночи мы ловим источник проблемы. API-поставщик тихо изменил спецификацию без обновления документации. Ни один контрактный тест не сработал, потому что структура запроса формально осталась валидной.
Исправление занимает 20 минут. Анализ и ретест — еще час. К рассвету прод оживает.
Глава 4. Что мы вынесли из этой истории
Мы не любим хорроры, но на одну такую вымышленную историю всегда приходятся десятки реальных кейсов. Они являются напоминанием о важности проведения профилактики. После этого случая стоило внедрить:
Финал. Happy End?
Мы вернули стабильность, отчет снова зеленый. Но с тех пор, каждый раз, когда Jenkins запускает автотесты, в тишине офиса кто-то шепчет:
Потому что даже у тестировщиков есть свои страшилки. И если уж бояться, то лучше багов, а не продакшна.
Послесловие от команды SaveLink
Хорошие тестировщики не верят в мистику. Они верят в проверку гипотез, документацию и CI/CD. Но в ночь Хэллоуина даже мы признаем: идеальный релиз — это редкий миф, и наш лучший оберег против ужаса — качественное тестирование.
— А давайте еще раз посмотрим логи. На всякий случай.
Глава 1. Оно затаилось в проде
На первый взгляд все идеально. Приложение стабильно, метрики чистые. Но в одном из логов кто-то замечает незначительное предупреждение — мелочь, «ошибка форматирования». Никто не придает значения. Через пару дней после релиза приходит письмо от заказчика:
«После обновления пользователи не могут оформить заказ. Ошибка 500».
Холодок пробегает по спине. Мы открываем тот самый лог. И понимаем, что предупреждение больше не предупреждение. Это начало критического сбоя.
Глава 2. Возвращение пропущенного
Мы пересматриваем тест-кейсы. Проверяем отчеты. Перезапускаем автотесты. Все чисто. Но ошибка не в коде. Она в данных.
Изменился формат ответа внешнего API. Казалось бы это незначительное отличие, один лишний символ. Но именно он превращает безобидный JSON в монстра, который рвет продакшн изнутри.
В фильмах ужасов чудовище возвращается, когда его считают побежденным. В тестировании — когда мы считаем, что покрыли тестами все.
Глава 3. Охота начинается
Мы собираемся в экстренную QA-сессию. Мониторы светятся, мессенджер пульсирует тревожными уведомлениями. Кто-то перезапускает сборку, кто-то перепроверяет спецификацию.Снаружи ночь, дождь и ветер. Внутри адреналин и абсолютная концентрация.
В три часа ночи мы ловим источник проблемы. API-поставщик тихо изменил спецификацию без обновления документации. Ни один контрактный тест не сработал, потому что структура запроса формально осталась валидной.
Исправление занимает 20 минут. Анализ и ретест — еще час. К рассвету прод оживает.
Глава 4. Что мы вынесли из этой истории
Мы не любим хорроры, но на одну такую вымышленную историю всегда приходятся десятки реальных кейсов. Они являются напоминанием о важности проведения профилактики. После этого случая стоило внедрить:
- Контрактное тестирование для всех интеграций;
- Мониторинг внешних API с алертами при изменении схемы;
- Проверку спецификаций в рамках CI/CD;
- И главное это еженедельный «QA-разбор» в духе Code Review, где обсуждаем потенциальные риски и «почти пропущенные» дефекты.
Финал. Happy End?
Мы вернули стабильность, отчет снова зеленый. Но с тех пор, каждый раз, когда Jenkins запускает автотесты, в тишине офиса кто-то шепчет:
— Только не этот сценарий…
Потому что даже у тестировщиков есть свои страшилки. И если уж бояться, то лучше багов, а не продакшна.
Послесловие от команды SaveLink
Хорошие тестировщики не верят в мистику. Они верят в проверку гипотез, документацию и CI/CD. Но в ночь Хэллоуина даже мы признаем: идеальный релиз — это редкий миф, и наш лучший оберег против ужаса — качественное тестирование.